Consider allowing content scripts to always access [SecureContext] interfaces
Categories
(WebExtensions :: General, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: gregp, Unassigned)
References
Details
(Whiteboard: [wecg])
As more features become gated behind SecureContext, extensions will start breaking on non-https websites. To improve this situation, we could allow content scripts to always access SecureContext interfaces, even if the page itself is not secure.
Since Secureness is per-realm, it should be pretty easy to accomplish this by always marking the content script sandbox realm as secure. This change should probably be limited to MV2 content scripts, since a goal of MV3 is to limit the capabilities of content scripts to those of the page.
The inspiration for this is bug 1859236. When the SecureContext requirement for getCoalescedEvents lands in the release channel, extensions like Gesturefy will stop working on a lot of websites (iirc ~20% of pageloads in Firefox are still not using HTTPS), this is unfortunate.
|
||
Updated•2 years ago
|
|
|
||
Comment 1•2 years ago
|
||
We're not clear if we want to have a single policy for all things that are currently behind the SecureContext flag, we need to investigate and discuss this more before making that decision.
|
Reporter | |
Comment 2•2 years ago
|
||
We could add a new webidl extended attribute that's similar to SecureContext and called something like SecureContextOrWebExtension. This would allow a good amount of flexibility.
|
||
Comment 3•2 years ago
|
||
While it hasn't been discussed yet, I have created an issue in the WECG at https://github.com/w3c/webextensions/issues/478
|
|
||
Updated•2 years ago
|
|
|
||
Comment 4•2 years ago
|
||
There is consensus on not exposing all APIs tagged SecureContexts to content scripts. See the meeting notes linked from the WECG issue linked above (pending review at https://github.com/w3c/webextensions/pull/486).
Description
•