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

Hi Rigo and Fred,

I'd like to better understand the privacy implications of the data contained in the report. As I'm admittedly not a privacy expert, it's not clear to me that the data included in the report is of a sensitive nature. Assuming a privacy concern exists, showing UI to the user is but one method of mitigation for such an issue. I think if armed with a more specific understanding of the report data that is private and why, then we can make a more informed decision about how best to protect the user's privacy. 

For example, perhaps the concern is that the report-uri might be a party other than that from which the protected resource was requested by the user (it may or may not be an actual concern, I'm using this as a hypothetical). An issue like that might be addressed by limitations on the origin of the report-uri.

Can you elaborate on what data contained in the report is of a private nature (e.g. might disclose information about the user that might not otherwise have been known by the site)?

-Jacob

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Thursday, October 18, 2012 3:36 AM
To: public-privacy@w3.org
Cc: Adam Barth; Fred Andrews; Hill, Brad; public-webappsec@w3.org
Subject: Re: Resolution of post-Last Call comments on CSP 1.0 by Fred Andrews and Boris Zbarsky

Dear Adam, Brad, 

having specified a mechanism of policy violation reporting without having considered privacy is a problem. 

The current specification says in 4.11:
==
The report-uri directive specifies a URI to which the user agent sends reports about policy violation.
==

It goes on saying: 
==
To send a violation report, the user agent must use an algorithm equivalent to the following:
==

The following algorithm disregards the user using the web application. It would be very easy to add a step that allows a decision by the user to send the report or not. This is what current operating systems do and I look forward to an argument on why this is omitted here. 

In light of DRM systems in Apps and the current discussions in media about mobile applications revealing data about the user, requiring a response on privacy is far from trolling. 

The issue may be big or not and I'm willing to participate in the TPAC session organized by Brad. But "phoning home" without the user knowing is a serious issue that is very specific to CSP. Can you elaborate how this is resolved in CSP other than "this is an implementation question"? IMHO because CSP creates a "phone home" 
feature, it should also address the consequences. 

Best, 

Rigo Wenning
W3C Privacy Activity Lead


From: Fred Andrews [mailto:fredandw@live.com] 
Sent: Wednesday, October 17, 2012 3:43 PM
To: Hill, Brad; public-webappsec@w3.org; public-privacy@w3.org
Subject: RE: Resolution of post-Last Call comments on CSP 1.0 by Fred Andrews and Boris Zbarsky


Viewing the DOM/script platform as being incapable to maintaining privacy has
been used by the WG to exclude some consideration of privacy in the CSP spec.
The WG has revised the amount of information sent in reports and I commend
them for this.

What the WG has failed to consider is the capability of the UA to maintain privacy,
and it would be hard for the WG to argue that a UA could not block reports and
thus the conclusion of the WG that the platform is not capable of maintaining
the privacy of the security violation reports in false.  Thus I believe the refusal of
the WG to consider privacy issues is a failing of the WG.

The reason stated below for rejecting issue 11 may mislead some reads and I
request that it be changed to more completely reflect the reality of the WGs decision.
The that "violation reports do not disclose any information not already available
to the author of the resource" is clearly false because if the author already knew
the information then there would be no need to send the report.

I suggest that the reality is that the WG refuses to consider privacy matters because
it views the DOM/script platform as being incapable to maintaining privacy and would
appreciate it if the reason could be revise along these lines for the record.

It may be helpful to privacy advocates to understand the reasons for rejecting privacy
considerations in ongoing standards so that they can ponder paths forward.

cheers
Fred
________________________________________
From: bhill@paypal-inc.com
To: public-webappsec@w3.org; fredandw@live.com; bzbarsky@MIT.EDU
Date: Fri, 12 Oct 2012 22:11:16 +0000
Subject: Resolution of post-Last Call comments on CSP 1.0 by Fred Andrews and Boris Zbarsky
As we prepare to move to CSP 1.0 to Candidate Recommendation, I find I have erred as a chair in the procedure to publicly document the WG's resolution of Boris Zbarsky and Fred Andrew's post-Last Call comments in the following messages:
 
http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0013.html
http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0005.html
 
We opened issues, notified the list of such, and the resolution of these issues is publicly visible, but I was requested as part of CR review that the group document this more fully and explicitly on the list and reply directly to the commenters by email.
 
The full resolution of each of these issues, as recorded in our teleconferences, is available at the links below, a brief summary of the WG's action is included inline here, and the commenters are cc'd on this message.
 
Issue 11 was re-raised to address privacy concerns about the CSP reporting feature.
https://www.w3.org/2011/webappsec/track/issues/11 
 
The WG rejected making any changes based on Mr. Andrews' comments as violation reports do not disclose any information not already available to the author of the resource.
 
Issue 16 was raised to address editorial concerns about the scope and authority of CSP in the client execution context.
https://www.w3.org/2011/webappsec/track/issues/16 
 
The WG accepted and incorporated this feedback.
 
Issue 17 was raised to address concerns about interference by CSP with extensions/plugins.
https://www.w3.org/2011/webappsec/track/issues/17 
 
The WG considered that this core concern was already adequately addressed by the current text, and more detailed non-normative guidance can be added to future versions as implementation experience suggests.
 
Issue 18 was raised to address concerns about the purpose and use of CSP.
https://www.w3.org/2011/webappsec/track/issues/17 
 
The WG closed this issue, choosing to make no modifications to the specification text, as the suggestions were outside of the chartered goals of the WG, and the existing text did not preclude it from being used in the suggested manner but such uses would be highly specific to proprietary technology implementations,
 
Issue 19 was raised to address concerns about use of non-ASCII characters in CSP.
https://www.w3.org/2011/webappsec/track/issues/19
 
The WG closed this issue, choosing to make no modifications to the specification text, user agents need to translate IRIs into URIs for use in  HTTP and everything in CSP 1.0 is defined in terms of networking  operations at the HTTP layer.
 
 
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.
 
Thank you,
 
Brad Hill
WebAppSec WG co-chair

Received on Thursday, 18 October 2012 17:03:40 UTC