Re: CSP formal objection.

Since we all agree about the PoC, but could argue for another few months
about what exactly it means, would everyone be able to live with the
following text:

"When considering interactions between a resource's policy and
user-initiated changes to that resource, for example through extension
mechanisms or bookmarklets, user agent implementors SHOULD take in to
account the HTML5 Priority of Constituencies (link) when determining
whether to enforce or report on a policy violation that would be generated
by such changes."

-Brad


On Wed, Jan 29, 2014 at 5:28 PM, Garrett Robinson <grobinson@mozilla.com>wrote:

> 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]
>
> [0]
> http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews
>
> 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/
> >     >
> >
> >
>
>