Expose some or all SecureContext-restricted APIs in content scripts on insecure schemes (http)

[Rob--W]

Several web platform APIs are annotated to require a Secure Context (https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts), with the primary goal to defend against MITM attackers.

These restrictions are also applied to content scripts running in insecure contexts (http:-URLs). This ranges from useful stateless APIs to stateful APIs that persist data:

• crypto.subtle.digest can be used to create (SHA) hashes.
• caches (Cache API) offers persistence of data.
• And many more Features restricted to secure contexts on MDN.

There are occasionally requests to expose some functions to content scripts, and here is even one that requests a blanket exposure of all SecureContext-restricted APIs: https://bugzilla.mozilla.org/show_bug.cgi?id=1860329. Should we expose some SecureContext-restricted APIs to all content scripts, and if yes, how?

[Rob--W]

Everyone is opposed to a blanket SecureContexts exception. Individual cases could be considered separately. Safari/Chrome have hesitations with inconsistencies in exposed web platform APIs between content scripts and web pages.

[rdcronin]

As @Rob--W mentioned, I have some concerns here.

In general, many of the APIs limited to SecureContext are restricted due to security or privacy concerns. We very strongly do not want to open any of these up to content scripts. Even though the extension is trusted, the content script runs in the same process and on the same document as untrusted script. This has two implications for security:

• It is easier for the web page to "trick" the content script into doing something, since direct communication between the two worlds is possible through event posting.
• More importantly, it means we cannot restrict anything at a process level as the browser. It is much better from a security perspective to be able to lock an entire process from a powerful capability (this is especially true for browsers with site isolation).

Because of this, we'd be very hesitant to expose any SecureContext-restricted API that had security or privacy implications to content scripts on http pages.

I agree that there are APIs for which this isn't the case (crypto.subtle.digest is a good example -- it just allows hashing data). I don't have security or privacy concerns around exposing these, but do have concerns around the complexity of the implementation, documentation, and general understanding. In general, we try very hard to say that content scripts have the same capabilities as the web page. There are a few exceptions to this already, but they are largely isolated into extension-specific carveouts. I think having different JavaScript contexts in the same document have different web capabilities will lead to significantly more confusion than we already have.

Since there are plenty of workarounds for this already (the typical flow being proxying the request through an extension-origin context), I'd be opposed to introducing this for a relatively small handful of APIs. I'm open to being persuaded, though, if there's a larger swath of these APIs we'd a) be okay exposing from a security and privacy POV and b) have a significant usability impact for the content script.