- From: Fred Andrews <fredandw@live.com>
- Date: Sat, 13 Oct 2012 22:46:16 +0000
- To: Thomas Roessler <tlr@w3.org>, "Hill, Brad" <bhill@paypal-inc.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>, "Boris Zbarsky (bzbarsky@MIT.EDU)" <bzbarsky@mit.edu>
- Message-ID: <BLU002-W13244D5B2B3552633D1A916AA730@phx.gbl>
Sorry, I am preparing a response and seeking input from others and it may take a few more days. I would like to at least clarify for the record some objections to CSP in its current form. 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 and on this point alone I believe that CSP should be rejected in its current form. The reasons for rejecting issue 11 may well false or self referential on other failings of CSP, and this is being explored. It is not clear that browser vendors have demonstrated a solution to making CSP 'not interfere' with UA extensions, and thus CSP many be internally inconsistent. The sentiment communicated to me suggested the interpretation of 'not interfere' does not consider leakage of the state of the extension as interfering which would be disturbing. The UserCSP Firefox extension is being examined to consider if its use could possibly be invisible to the server: https://addons.mozilla.org/en-US/firefox/addon/newusercspdesign/ To the extent that rejection of issue 11 and related matters were due to the claim that a server could covertly acquire the information from the UA anyway, I would like this reason to be on record and I do not believe using this as an excuse does the WG any credit. The PUA Community Group is working to close some of the leaks and this may well require CSP behavior to be modified and lead to incompatibility. 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. 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. This is information that currently may not be available to the first party without obtaining it from the third party. This would be a disturbing direction for a w3c standard to be taking and would appear to conflict with DNT:1. This 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. I will follow up with a more coherent and complete response as soon as possible. cheers Fred > Subject: Re: Resolution of post-Last Call comments on CSP 1.0 by Fred Andrews and Boris Zbarsky > From: tlr@w3.org > Date: Sat, 13 Oct 2012 13:33:59 -0400 > CC: public-webappsec@w3.org; fredandw@live.com; bzbarsky@MIT.EDU > To: bhill@paypal-inc.com > > On 2012-10-12, at 18:11 -0400, "Hill, Brad" <bhill@paypal-inc.com> wrote: > > > We will hold off publishing the CR of CSP 1.0 for one week from this date (October 12) to give these individuals an opportunity to re-raise these concerns if they do not feel the WG has adequately addressed them. > > Also, if Fred and Boris agree with the disposition of their comments, an explicit "ok" would be nice -- in which case we can move on more quickly. >
Received on Saturday, 13 October 2012 22:46:44 UTC