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

Hi Dan,

Thank you for the detailed response - this does help me understand the
issues better.

> From: dveditz@mozilla.com
...
> 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).

This is very interesting because issue 11 rejected opt-in reporting,
and since you seem to interpret CSP as allowing the browser
to disable reports then perhaps we are in agreement?

I did raise this issue before and this position did seem to be rejected.  See:
http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0039.html

Sections 3.1.1 and 3.1.2 specify that the UA MUST enforce or monitor
when requested, and section 3.3 defines enforcing and monitoring,
but the link between the processing of these and reporting to the server
is vague.

3.1.1 Content-Security-Policy Header Field

"Upon receiving an HTTP response containing at least one
Content-Security-Policy header field, the user agent MUST enforce each
of the policies contained in each such header field."

3.1.2 Content-Security-Policy-Report-Only Header Field

"If their site violates this policy, instead of breaking the site, the
user agent will send violation reports to a URI specified in the
policy."

"Upon receiving an HTTP response containing at least one
Content-Security-Policy-Report-Only header field, the user agent MUST
monitor each of the policies contained in each such header field."


So is CSP deliberately vague regarding the requirement to report?

Is reporting optional?

There is a significant difference between reporting being required
versus optional.  If reporting is required then the server can depend
on it and content may be produced that will break if a non-conforming
UA does not report.  If reporting is optional then servers could not
depend on it and would not be able to reliably exploit reporting to
probe the UA state - a UA could disable reporting and should not be
affected.

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

I would like to see the CSP spec. allow the UA to make reporting opt-in or
to report to the user rather than the server.

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

Thank you for the clarification.  This does seem ok.
 
> > 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.

Thank you for the explanation.  This would appear to work well for
allowing users to narrow the resources allowed without this being
reported.

> 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

Very interesting thanks.  I do recognize the leaks in the current standards
and are working on solutions in the PUA CG.  Note that to prevent CSP
reporting being used to leak UA state if would likely need to opt-in.
 
> 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.

If it can be done without the server noticing then I do not care if this
case is noted in the spec.
 
> > 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.

Thank you again for the clarification, this is very helpful.

cheers
Fred