Re: Resolution of post-Last Call comments on CSP 1.0 by Fred Andrews and Boris Zbarsky

On 10/13/12 3:46 PM, Fred Andrews wrote:
> I believe that the CSP spec. should be designed to NOT require
> reporting.  It would seem unprecedented that security violations are
> deemed a matter not under the control of the user and to me this is a
> disturbing direction for a w3c standard to take

The CSP spec is designed to not require reporting; reporting is a
feature that sites may or may not use but CSP works fine either way.

Reporting can help protect users who do not have a CSP-supporting
browser by alerting sites to the presence of a possible attack
(unexpected or injected content) which was blocked for those users
protected by CSP.

What kind of "under the control of the user" would you like to see? I
assure you users don't want to be asked repeatedly whether or not to
send the violation reports. There's nothing in the spec that would
prevent a browser from offering the option to disable reports (or CSP
itself, for that matter, such as Firefox's "security.csp.enable" pref).

I am unable to discern your desired state. Are you asking for the spec
to REQUIRE UAs to support the ability to disable reporting? Are you
asking for the complete removal of the reporting feature? Something else?

> The implementation notes in section 7 note that the policy is end-to-end
> and should not be modified by a proxy.  However a proxy under the
> control of the user is a UA and should be able to modify the security
> policy without detection by the server where such modifications are a
> private matter.

Sure. If a proxy under the users' control is a UA then it can ignore the
rules for proxies. And even if it says "proxy" on the box, if the user
wants to run a "non-compliant" proxy there's nothing the W3 or anyone
else can do about it. That part of the spec gives guidance to 3rd party
proxies. It explicitly exempts proxies "in the same administrative
domain as the resource." Would you like us to add "or the user agent"?
ISP's might take that as carte blanch to do whatever they want. Better
as it is, I think -- it's a "should not" requirement, not MUST NOT, anyway.

> In its current form, CSP would appear to be usable by a content provider
> to covertly monitor user modifications to the CSP policy that restrict
> the loading of third party resources.

In the current implementations, perhaps, but existing addons that
restrict the loading of 3rd party resources don't do so using CSP (the
new "usercsp" excepted, of course) and won't be detected this way.

Gecko's support for multiple CSP headers still follows our original
"intersection" algorithm. This needs to be changed since the spec says
(3.1.1) the UA must enforce each policy (that is, intact, one after the
other). Interpreted this way additional local restrictions could be
implemented as if they were another HTTP header policy. The violations
of each policy will be reported only to the report-uri in each policy,
and the extension-supplied policy would presumably have no report policy.

Since Adam drafted that part of the spec I suspect Webkit already
behaves this way. I don't know if webkit allows extensions to modify CSP
however, and I'm sure their existing content blocking extensions (e.g.
AdBlock) are not going to be sending off CSP violation reports when they
block content.

Even without CSP sites can and sometimes do try to detect if the user is
blocking parts of their content, e.g.
https://twitter.com/dangillmor/status/257179336661164032

Writing it into the CSP spec explicitly that we not send violation
reports for user-initiated policies isn't going to change that. I'd be
totally fine with writing that into the spec, by the way. I already feel
free to implement the current spec in that manner.

> and would appear to conflict with DNT:1.

That claim is hard to take seriously. Half the original Mozilla
implementation of CSP was written by one of the guys who proposed DNT
(Sid Stamm).

> property of CSP could well be abused to further restrict terms or use of
> web content and to discriminate against users blocking resources via CSP.

Sites can and do discriminate against users blocking resources (see
tweet above), but they should not be able to do so any more easily if
the mechanism is user-added CSP vs. any of the pre-existing blocking
mechanisms. The fact that the "usercsp" Firefox add-on is detectable is
due to bugs, namely the fact that Firefox is not yet compliant with the
1.0 CSP spec.

-Dan Veditz

Received on Monday, 15 October 2012 03:44:03 UTC