[kid-icarus]

Can you specify which policies are a nightmare to develop on? As a security-minded UI eng, I warmly welcome any new security policies that enable me to harden my applications and prevent exfiltration of sensitive data.

Edit: typo.

[danShumway]

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.

[fiddlerwoaroof]

Yeah, CSP breaking bookmarklets and extensions is arguably not to spec[1]. Firefox finally partially fixed their non-conforming implementation recently[2], but I think Chromium still has an open bug here.

[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

[londons_explore]

Google could make tooling for extension authors which identifies permissions which have not been used and suggests removing them.

Then the process of developing an extension could be:. (1) request all permissions. (2) write code for extension. (3) run extension in test session and exercise all functionality. (4) let tool suggest the correct set of required permissions, which can be very granular.

This means the developers don't need to know the precise details of each of hundreds of permissions.

[varenc]

Because even through a user can grant a Chrome extension access to particular site, when that site has certain CSP policies enabled there's no way for the Chrome extension to interact with that page's JS. CSP is enforced on the extension's JS, even though the user wants to permit it.

Chrome could make things much easier for developers, and arguable safer, by offering some straightforward way for an extension to interact with a page that doesn't involve messing with CSP headers.

[bdefore]

Because you're maintaining a legacy application that in development can only operate in http but if you override network resources in an https environment to point them to local the browser will (understandbly) throw a fit.