RE: new meta tags to protect code visibility or immuatbility

Fair enough, my tinfoil hat is showing. I think extensions are psychotically dangerous and don’t understand why anyone in their right mind would use one. “This extension gets complete read/write access to all your web browsing, including all your social networking accounts, your web mail, and your online banking and shopping. But it shows dancing pigs! Ha ha! Gotta have it!” Sorry, that does not work for me ☺

From: Eduardo' Vela" <Nava> [mailto:evn@google.com]
Sent: Wednesday, February 24, 2016 11:24 PM
To: Crispin Cowan <crispin@microsoft.com>
Cc: Daniel Veditz <dveditz@mozilla.com>; Mitar <mmitar@gmail.com>; Mike West <mkwst@google.com>; Brad Hill <hillbrad@gmail.com>; public-webappsec@w3.org; Ahmed Saleh <ahmedzs@live.ca>; Craig Francis <craig.francis@gmail.com>
Subject: RE: new meta tags to protect code visibility or immuatbility


Haha, wow :-). Very heated debate.

I'm not Mike, so I'm not answering the question, but I'll drop some examples of extensions that CSP breaks.

Content-Security-Policy: style-src 'none'

Would break any site trying to re-style the page (like Readability).

Content-Security-Policy: script-src 'none'

Would break any site trying to inject scripts to the current page (like JS debugging tools).

Content-Security-Policy: child-src 'none'

Would break any site trying to show an overlay to the page (like Related Sites).

In fact, Chrome, even with all its efforts to avoid it, is still annoyingly breaking some extensions that inject CSS or JS dynamically.

I guess if Chrome redesigned the Extensions API they could find a way not to interfere with CSP, but I don't think that's really technically feasible now..
On Feb 25, 2016 7:56 AM, "Crispin Cowan" <crispin@microsoft.com<mailto:crispin@microsoft.com>> wrote:
I don't buy that at all. All of those extension effects seem to be achievable without the extension violating site CSP. To the contrary, it seems to advance extension developer convenience by throwing user security under the bus.

*Mike*: what is the real reason?

-----Original Message-----
From: Mitar [mailto:mmitar@gmail.com<mailto:mmitar@gmail.com>]
Sent: Wednesday, February 24, 2016 9:27 PM
To: Crispin Cowan <crispin@microsoft.com<mailto:crispin@microsoft.com>>
Cc: Mike West <mkwst@google.com<mailto:mkwst@google.com>>; Daniel Veditz <dveditz@mozilla.com<mailto:dveditz@mozilla.com>>; Brad Hill <hillbrad@gmail.com<mailto:hillbrad@gmail.com>>; Craig Francis <craig.francis@gmail.com<mailto:craig.francis@gmail.com>>; Ahmed Saleh <ahmedzs@live.ca<mailto:ahmedzs@live.ca>>; public-webappsec@w3.org<mailto:public-webappsec@w3.org>
Subject: Re: new meta tags to protect code visibility or immuatbility

Hi!

Crispin, because (citing Brad):

https://www.w3.org/TR/html-design-principles/#priority-of-constituencies


"In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once."

The right of users to be in control of their browsing experience and their own computer outweighs the desire of authors to control what users can see and how they can interact with it.  This protects important rights, for example, the ability of a blind user to use a screen reader, or the right to automatically translate content, or just do silly stuff like https://chrome.google.com/webstore/detail/xkcd-substitutions/jkgogmboalmaijfgfhfepckdgjeopfhk?hl=en

to experience the web the way they want to.


Mitar

On Wed, Feb 24, 2016 at 4:28 PM, Crispin Cowan <crispin@microsoft.com<mailto:crispin@microsoft.com>> wrote:
> 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<mailto:mkwst@google.com>]
> Sent: Wednesday, February 24, 2016 1:17 AM
> To: Daniel Veditz <dveditz@mozilla.com<mailto:dveditz@mozilla.com>>
> Cc: Mitar <mmitar@gmail.com<mailto:mmitar@gmail.com>>; Brad Hill <hillbrad@gmail.com<mailto:hillbrad@gmail.com>>; Craig
> Francis <craig.francis@gmail.com<mailto:craig.francis@gmail.com>>; Ahmed Saleh <ahmedzs@live.ca<mailto:ahmedzs@live.ca>>;
> public-webappsec@w3.org<mailto: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



--
http://mitar.tnode.com/

https://twitter.com/mitar_m