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

Re: CSP formal objection.

From: Glenn Adams <glenn@skynav.com>
Date: Wed, 29 Jan 2014 17:14:40 -0700
Message-ID: <CACQ=j+cNAHVHwriy9k8X1J5fiK6dh6dB4z0DFXgcn2R9TwdyXQ@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Mike West <mkwst@google.com>, Neil Matatall <neilm@twitter.com>, "Hill, Brad" <bhill@paypal.com>, Brian Smith <brian@briansmith.org>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jan 29, 2014 at 5:03 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Glenn Adams wrote:
> >You appear to believe in a static, monolithic model of user intent. A
> >simple model, such as always ignore or always enforce CSP policy with
> >respect to an extension/addon installed by some (not necessarily the same)
> >user, is inadequate to address practical concerns. UA vendors appear to
> >recognize this, and need the flexibility to find an appropriate balance
> >based on a combination of dynamic interests.
>
> The requirement is in the CSP 1.0 CR and the CSP 1.1 WD because they are
> specifications for user agents, and user agents should not let web sites
> interfere with user agent operations that users have configured, other-
> wise they would not be user agents and would implement CSP incorrectly.
>
> The requirement does not mention anything about "static" or "monolithic"
> or whatever else you might read into it. There is no basis, that I can
> see, for making CSP implementations that enforce CSP policies in manners
> that grossly interfere with user agent operations unconditionally com-
> pliant with the user agent requirements of the CSP specifications. That,
> however, is the effect of removing it without proper replacement.
>
> It is quite possible that the first generations of implementations have
> some limitations with respect to the requirement, and some might need to
> adapt, for instance, their extension mechanisms to take CSP policies in-
> to account; the current phrasing of the requirement takes that into
> account adequately, while also making the intent clear enough.
>
> It would be rather harmful if the specification could be interpreted as
> if CSP policies could be used to attack the user like by allowing sites
> to disable assistive technologies the user might rely on.


I find it rather unproductive to talk about "CSP policies ... used to
attack the user". It is better to have a longer term discussion about how
to adequately model a user's intentions and how browsers can accommodate
those intentions while simultaneously permitting CSP policies to be
respected.


> The require-
> ment fortunately makes it clear that if sites could do this, and there
> is no alternate way to implement the same functionality available, then
> the fault is with the CSP implementation. I do not see how there is any
> need for more "flexibility" in scenarios like that.
>

Flexibility could translate to a variety of user preferences or
interactions that can be used to fine tune how CSP policy applies. There
are a wide variety of technical options open to browser vendors without
resorting to an "always enforce" or "always ignore" application of CSP
policy to extensions/addons. In any case, the consensus appears to be that
browser vendors should drive this process. In the longer term, if a
majority of browsers choose the same implementation, then perhaps it can be
documented by the specification.
Received on Thursday, 30 January 2014 00:15:28 UTC

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