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

Re: CSP formal objection.

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Thu, 30 Jan 2014 01:03:07 +0100
To: Glenn Adams <glenn@skynav.com>
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>
Message-ID: <0n2je9hcjdd57qk45k38jkbe14l39ifmlo@hive.bjoern.hoehrmann.de>
* 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. 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.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Thursday, 30 January 2014 00:03:33 UTC

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