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

On Sun, Oct 14, 2012 at 8:43 PM, Dan Veditz <dveditz@mozilla.com> wrote:
> 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

WebKit doesn't take a position on that topic.  In Chrome, extensions
can modify CSP policies, but only via general mechanisms, such as the
general mechanism to modify any HTTP header.

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

Correct.  The most natural way of implementing AdBlock as a Chrome
extension will not trigger CSP violation reports for the same reason
that we don't trigger CSP violation reports when ad servers fail to
respond to network requests.

Adam


> 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:54:47 UTC