W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

RE: new meta tags to protect code visibility or immuatbility

From: Eduardo' Vela\ <evn@google.com>
Date: Thu, 25 Feb 2016 08:23:47 +0100
Message-ID: <CAFswPa_7swGU3WPdc1eY2Ai7GcakVosOyZqY6qtxZgmO3srGLA@mail.gmail.com>
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" <public-webappsec@w3.org>, Ahmed Saleh <ahmedzs@live.ca>, Craig Francis <craig.francis@gmail.com>
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> 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]
> 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 07:24:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC