|
|
|
|
|
by danShumway
1849 days ago
|
|
The hard part isn't breaking the security, the hard part is not breaking the security. Web extensions are often only provided with nuclear options like overriding CORS or requesting full-page access. There's not really any new policy you can take advantage of here, it's just developers complaining that they have to resort to wider-impact, potentially dangerous hacks in order to perform basic actions. In my mind, it's similar to when people hand-wring about extensions requesting access on all URLs. The security model for extensions is not fine-tuned enough to enable better behavior. It railroads extensions into over-requesting access to everything. I consider this to be a serious problem, but... I don't know, it doesn't talked about that much. To be fair, the web makes granular permissions difficult, and also to be fair Manifest V3 does try to make things more granular, in at least some ways. It's easier to make an extension now that only operates on some pages. But building limited extensions that don't have a lot of power is still somewhat difficult. But regardless, I don't believe any of this is actionable advice you can use for your own pages. Which is good, because as a website author, you should not have the ability to override the user's decision about how extensions interact with your page; I would consider that to be an anti-web, anti-user sentiment in most cases. Websites don't get to decide what code can be run in an extension. |
|
[1]: Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].
https://www.w3.org/TR/CSP3/#extensions
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1478037