- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 14 Oct 2012 20:53:47 -0700
- To: Dan Veditz <dveditz@mozilla.com>
- Cc: Fred Andrews <fredandw@live.com>, Thomas Roessler <tlr@w3.org>, "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Boris Zbarsky (bzbarsky@MIT.EDU)" <bzbarsky@mit.edu>
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