Mike, I am curious why Chrome chose to do that. Some site goes to a lot of work to implement CSP to defend itself against XSS. Then some inept ISV ships an extension that overrides CSP and makes the site vulnerable, users get hacked, and very large amounts of damage can follow e.g. drain a bank account. Why would we prioritize an extension’s desires over a web site’s CSP policies? From: Mike West [mailto:mkwst@google.com] Sent: Wednesday, February 24, 2016 1:17 AM To: Daniel Veditz <dveditz@mozilla.com> Cc: Mitar <mmitar@gmail.com>; Brad Hill <hillbrad@gmail.com>; Craig Francis <craig.francis@gmail.com>; Ahmed Saleh <ahmedzs@live.ca>; public-webappsec@w3.org Subject: Re: new meta tags to protect code visibility or immuatbility On Wed, Feb 24, 2016 at 9:45 AM, Daniel Veditz <dveditz@mozilla.com<mailto:dveditz@mozilla.com>> wrote: You are indeed trolling. Making bookmarklets and some add-ons work when CSP is applied is _hard_. They are not broken because CSP-implementing browser vendors are valuing the page author over the user. We don't know how to balance a feature that wants random content injection and a feature that is trying to prevent content injection. Firefox does allow users to disable CSP entirely if they think it is interfering with their experience (users win, as the PoC says they should); I wouldn't be surprised if Chrome didn't also support that as an advanced option. Chrome does not support that as an option. Chrome does, however, do quite a bit of work to allow extensions to bypass CSP. It's not at all perfect, but it's probably ~80% of the way there. I'd love to see Firefox follow suit. :) -mike
Received on Thursday, 25 February 2016 00:29:20 UTC