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

Re: Removal of the note about extensions

From: Glenn Adams <glenn@skynav.com>
Date: Mon, 24 Feb 2014 09:53:46 -0700
Message-ID: <CACQ=j+dE3+033x7mOYAMDThtrfC+9Bvj-93nZQB_ikH_-LVWtQ@mail.gmail.com>
To: Mike West <mkwst@chromium.org>
Cc: Mitar <mmitar@gmail.com>, Mike Pomax Kamermans <pomax@nihongoresources.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Feb 24, 2014 at 6:31 AM, Mike West <mkwst@chromium.org> wrote:

> From a process perspective: we closed Cox's formal objection in the last
> call, based on removing the sentence in question. As I noted in [1], I
> don't think there's any normative difference between the spec with or
> without that sentence: I don't plan on changing Blink's behavior, and I'd
> speculate that Mozilla doesn't intend to use this sentence's absence as a
> reason to stop working to allow add-ons to function in the presence of a
> page's CSP.
>
> That said, I personally agree with the sentiments expressed here and on
> the GitHub commit [2]: removing the sentence is probably the wrong way to
> resolve the objection, because it doesn't make the WG's general consensus
> clear.
>
> I believe the following fairly summarizes the discussion thus far (Glenn,
> and others, please correct me):
>
> * Cox objects to language that provides a blanket policy exception to
> extensions, for two reasons:
>     1. Compromised extensions may not be representing the will of the user.
>     2. Liability for catastrophic loss which could have been prevented if
> extensions' actions could be suppressed.
>

I would remove "catastrophic", since any loss could potentially produce
liability.


>
> * The WG, on the other hand, seems supportive of allowing extensions to
> bypass a page's CSP. For example, see the poll results from [3]: reps from
> Google, Mozilla, and others were generally disinterested in changing the
> spec's normative behavior. Cox's vote was the only positive response to #6
> that I saw.
>

Just to be clear, there wasn't a vote in the WG. Rather, the chair asked
for objections to the change and there were none. There were also other
supporters of the change, e.g., in [1][2].

[1] http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0173.html
[2] http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0174.html


>
> With this in mind, I'm inclined to add a non-normative note to the spec
> along the lines of "Note that user agents are encouraged to allow
> third-party add-ons and JavaScript bookmarklets to bypass policy
> enforcement, either implicitly or based on the user's preference."
>

I'm afraid this would cause Cox to re-raise our original FO.


>
> On Mon, Feb 24, 2014 at 7:50 AM, Mitar <mmitar@gmail.com> wrote:
>
>> And such argumentation is really silly. First you are saying that
>> because there is a consensus and of course nobody will block, there is
>> no need to put this into the standard. And then also because there is
>> no consensus, there is nothing to put into the standard.
>>
>
> I don't think that's been my argument. In short, I removed the sentence
> because:
>
> 1. Extensions are vendor specific.
> 2. Vendor specific bits are, by their nature, non-interoperable.
> 3. Normative bits of the spec shouldn't regular vendor-specific bits of
> the user agent.
>
> I would be perfectly happy to add a non-normative note to the spec,
> explaining that it would be wonderful if vendor-specific things like
> extensions would continue to function despite a page's CSP. I
>
> > I can assure you that not all UAs will adopt the position of ignoring
>> CSP in the case of
>> > extensions/add-ons. In fact, I'm aware of a downstream specification
>> that mandates
>> > that UAs (that comply with that specification) must enforce CSP
>> policies, modulo explicit
>> > override by end user, in the case of extensions/add-ons.
>>
>
> Can you point to that spec, Glenn? I'm curious.
>

It is presently WIP in the consumer electronics domain, and not yet
available for public viewing. However, at an appropriate time it will be
made available, as this specification is expected to be consider for
adoption in a formal rule by the FCC.


>
> -mike
>
> [1]:
> http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0006.html
> [2]:
> https://github.com/w3c/webappsec/commit/cbfaa8edfadebf21a9c7428242c12e45934d8c55
> [3]:
> http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0086.html
>
Received on Monday, 24 February 2014 16:54:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC