Re: CSP formal objection.

Cox can accept that wording.


On Mon, Feb 3, 2014 at 1:38 PM, Brad Hill <hillbrad@gmail.com> wrote:

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