W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2014

Re: CSP formal objection.

From: Garrett Robinson <grobinson@mozilla.com>
Date: Wed, 29 Jan 2014 17:28:33 -0800
Message-ID: <52E9AAC1.1070609@mozilla.com>
To: public-webappsec@w3.org
On 01/29/2014 01:58 PM, Mike West wrote:
> With my editor hat on: there's no reasonable way to validate this
> sentence for cross-browser compatibility. It is vague enough to allow
> multiple interpretations (what does "interfere" mean, really?), and
> different vendors allow add-ons different capabilities which the spec is
> necessarily silent on. For instance, nothing in the spec notes that
> Chrome's content settings should be able to block resources otherwise
> allowed by CSP.

Indeed. Rather than removing the sentence (which IMHO is just punting
the issue), we should resolve it conclusively.

> With my browser vendor hat on: I don't plan to change Chrome's behavior
> to make extensions more subject to a page's CSP, regardless of this
> sentences' presence in the spec. That runs counter to extensions'
> purpose, and the priority of constituencies.

+1 (with my CSP implementer hat on).

The only reason that we (and Blink) have not implemented this provision
is that it is very *difficult* to do so. This is an unfortunate
consequence of browser architecture and should not be taken (as it has
been, several times, in this and related threads) to constitute
agreement with the proposal to remove this language. If implementing the
original text were easy, it would already be done.

Besides the important goal of attempting to preserve the priority of
constituencies, there are some practical reasons to maintain the
recommendation to avoid interfering with user-supplied script. One is
that when CSP is enforced against extensions and bookmarklets, it
generates (often a disproportionately large amount of) violation reports
that are not relevant to content authors. This reduces the utility of
the Report-Only header, both for the purpose of migrating to a CSP, and,
once one has been applied, using it to detect attempted attacks. I have
head numerous anecdotal complaints about this issue, including the
Fastmail example here: https://bugzilla.mozilla.org/show_bug.cgi?id=615708

With this in mind, I believe that the original text should essentially
remain in the spec. As Dev pointed out in an earlier reply, this is in
line with the well-defined meaning of "SHOULD NOT".

Further, while I am not as familiar with the W3C process as others on
this list, I wonder if the original formal objection is legitimate. I do
not consider the technical arguments made against this text to be
convincing, for reasons that have been explicated in earlier replies on
this and related threads. It also seems clear that we have "formally
addressed" the issue - the ensuing email conversation, issues and
conversation on the tracker, and conversations on calls certainly
constitute a "public, substantive response to the reviewer who raised
the issue". [0]


Are we done here? And if not, how can we determine when we are?

> --
> Mike West <mkwst@google.com <mailto:mkwst@google.com>>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
> On Wed, Jan 29, 2014 at 12:05 PM, Neil Matatall <neilm@twitter.com
> <mailto:neilm@twitter.com>> wrote:
>     In some recent conversations this was generally accepted because as
>     Dev said, "the UA should have the *option* of enforcing CSP over
>     user-supplied scripts and addons"
>     This change adequately reflects that position to me. The other points
>     were just to emphasize that we should do this.
>     On Wed, Jan 29, 2014 at 11:52 AM, Bjoern Hoehrmann
>     <derhoermi@gmx.net <mailto:derhoermi@gmx.net>> wrote:
>     > * Hill, Brad wrote:
>     >>There is also the unfortunate reality that the original text cannot
>     >>advance beyond Candidate Rec anyway, because no user agent has
>     >>successfully implemented it. So it is living on borrowed time wrt the
>     >>W3C process anyway.
>     >
>     > You are welcome to demonstrate that no user agent has implemented
>     it, I
>     > have seen no evidence of that; and you are welcome to argue that
>     lack of
>     > implementations should be sufficient reason to remove the text,
>     but that
>     > has nothing to do with the W3C Process. It is entirely normal for W3C
>     > Technical Reports to be advanced beyond Candidate Recommendation
>     status
>     > even if some "SHOULD NOT" requirement has not been widely implemented.
>     > --
>     > Björn Höhrmann · mailto:bjoern@hoehrmann.de
>     <mailto:bjoern@hoehrmann.de> · http://bjoern.hoehrmann.de
>     > Am Badedeich 7 · Telefon: +49(0)160/4415681
>     <tel:%2B49%280%29160%2F4415681> · http://www.bjoernsworld.de
>     > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·
>     http://www.websitedev.de/
>     >
Received on Thursday, 30 January 2014 01:29:05 UTC

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