RE: new meta tags to protect code visibility or immuatbility

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] 
Sent: Wednesday, February 24, 2016 9:27 PM
To: Crispin Cowan <crispin@microsoft.com>
Cc: Mike West <mkwst@google.com>; Daniel Veditz <dveditz@mozilla.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

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> 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]
> 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> 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

Received on Thursday, 25 February 2016 06:53:45 UTC