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

On review, this reply turned out pretty long-winded, but I think it's all important.   The short version is:

1.	The WG has substantially and in good faith addressed Mr. Andrews' concerns.  One short-tempered email he provoked from a member is hardly representative of the WG's attitude as a whole towards, and its history of addressing, privacy concerns.  If he represented that email as the entirety of the situation, he is omitting much.  I apologize that the tone of the discussion has gone where it has; that is a fault of mine as a chair, which I am already working to improve.

2.	Regarding specific technical issues and suggestions, the WG feels that CSP makes significant user-centric advances in security and privacy against real XSS attacks widely employed today by unaccountable, criminal actors.  The issues raised and changes proposed by Mr. Andrews are either already accounted for by the current text, are actually counter-indicative to privacy, or have the potential to do substantial harm to the overall specification for little or no practical gains in privacy.  On the whole, we feel that advancing CSP as it stands will provide much more tangible benefit for user privacy protection than incorporating the suggested changes would.

Long version below...
----------
Rigo,

 I think we have two issues here, that I'd like to address in-turn.  The first regards the tenor of the discussion with Mr. Andrews.  I don't think either side is free of guilt in trespassing the level of civility we hope for here, and it is my responsibility as a chair to moderate that, so please accept my apologies for my failure to do so.

  That said, the WG does take privacy very seriously, and it is not accurate to say that we specified the reporting mechanism without considering privacy.  Privacy was carefully considered as part of the initial design, the feature has been further refined with privacy concerns in mind, and it sends very little information.    We absolutely do not "disregard the user", and I'm afraid that is an accusation that only serves to further escalate tensions as this group is full of people who are passionate about and have devoted their careers to protecting users on both the privacy and security fronts.  Not as an appeal to authority but simply as an example, one of the people responsible for much of the early design and implementation of CSP was also the proposer of DNT. (Sid Stamm)

  Adam and other members of the WG have responded to Mr. Andrews' concerns, in good faith and considerable detail, on several occasions.  The frustration Adam expressed was, I believe, not with the technical merit of the topic, but rather because our careful effort to explain the extremely limited scope and power of CSP reporting in the broader current and historical context of what browsers and web applications are and do has been met with inflammatory responses, attacks on the integrity of the WG, and couched in ideological terms that ignore the realities of the technology.  Additionally, these issues have been raised after Last Call, as implementers are exactly at the moment of shipping a technology that has been available, widely discussed and uncontroversial in the privacy and security community for years. 

  Again, I should have stepped in sooner to help diffuse these tensions and set the tone.  It was my responsibility and please accept my apologies. 

  On the technical merits of the issues, I do not think that it is entirely appropriate to define the CSP reporting mechanism as a "phone home".  What constitutes a "phone home" depends on the context of the action and user expectations around it.  You get prompted to send a crash dump of your local word processor because you were working on something in the context of your local machine that you might not want to send over the network.  It's a privacy invasive "phone home" if your OS informs a third party of your location every time you boot the system, if that's not necessary to its operations and outside of the user's contextual expectations; but it might not be on a dedicated mapping device.

 In that way, defining a "phone home" on the Web is much more difficult as it is a fundamentally networked platform that is based on pervasive resource retrieval and state transfer.  Is an <img> tag a "phone home"?  A <form> tag?  Is XHR and are AJAX applications?  What if an app watches resource loads with a DOM modification listener and reports those?  Do these require user-confirmation prompts?  Does the text of these specifications require specific language instructing implementers to make these opt-in?  Traditionally they have not because the user's expectation is that he or she is operating with a networked application, and this kind of network interactivity is at the heart of what it means to be part of the Web.  CSP doesn't change that in any qualitative way, and maintaining the user's security (and, not incidentally, their privacy) is absolutely a fundamental part of the user-expected operational context of any webapp.   In fact, some early prototypes of CSP were implemented entirely as .js polyfills.  Not to disparage the hard work and creativity of the editors, but CSP is mostly just a declarative shortcut to allow existing web platform features to be effectively deployed by resource authors in the defense of users.

  While it would be "easy" to, as you suggest, add a confirmation dialog before sending a report, it would also kill CSP.  The silent reporting mechanism is an essential part of the deployment story, and it is the only feature many of our adopters plan to use.  Modern web applications are extremely complex, and those charged with securing them aren't always those who develop them.  It is critical to deploying CSP that resource owners be able to use reporting to identify the normal behavior of their applications with regard to resource loads so they can craft appropriate policies.  

  Switching hats from chair to PayPal here, we would also likely never deploy CSP if violations triggered a user prompt.  Most of the time we expect CSP violations will be triggered due to developer errors and application scope drift, and not an actual attack.  The cost/benefit tradeoff of risking the intrusive, confusing, frightening ("OMG, did I get hacked?") and brand-damaging experience of a user prompt when it will nearly always be for a false positive is just not appropriate, and the risk of such mistakes would be incredibly high if we couldn't even test it in report-only mode first. I know other adopters feel the same.

  Switching hats back... there is also a mountain of evidence and experience that user security prompts are not helpful.  Avoiding these prompts is not disregarding the user, it is evidence-based compassion for the user. 99.999% of users don't have the context or ability to interpret and react appropriately to what they are being asked, they often make the wrong choice and leave themselves vulnerable, and the experience is overall a negative one.  

   Beyond this general misapprehension on the nature of CSP reporting, Fred has raised two substantive technical points: (1) that CSP might interfere with a user-installed extension in a manner that allows a resource author to infer the presence of that extension and (2) that the presence of CSP functionality can be inferred by a client web application instance and used in identifying the version of the browser.

  With regard to (1), the specification already says that CSP should not interfere with user-installed extensions and preferences.  It does not go into further detail, as we have said previously, because:

a) As such interference is already forbidden, if it occurs it is an implementation bug, not a spec bug	

b) We have no concrete examples of this actually happening from which to draw experience and offer advice

c) Extensions systems and their implementation are highly specific and proprietary and it is not clear there is specific advice that can be meaningfully offered in a standards-oriented manner

  The group has said that to the extent implementation and deployment experience actually allows us to speak to such issues, we will add language to version 1.1.

  With regard to (2), we will discuss that further at the TPAC session, but, to put it bluntly, preventing active fingerprinting of browser versions is a technical impossibility with or without CSP.  Making browsers indistinguishable across make and model is an untenable threat model and has never been a design goal of web specifications generally or browsers themselves.  Even aside from the fact that identifiers are advertised in the UA string, browsers contain millions of lines of code, thousands (or perhaps tens of thousands) of API points, and resources get to run arbitrary code inside them.  It is impossible that things embodying so much complexity would be indistinguishable, and no accident that the most popular web application library in history, jQuery, is mostly about trying to hide these pervasive differences from exasperated developers.  CSP doesn't make the situation any worse, but adding subfeature-specific user customization points to CSP actually might, as user preferences are more identifying than browser versions and infinitesimally few users would exercise these options.  

  Furthermore there is nothing to stop individual implementers from providing user controls, and there is a long history of user agents doing this, independent of any specification text or suggestion to do so.  (for example, controls on loading of images, user-specified overrides of fonts and styles, etc.)  We see no need to and little value in complicating the specification's definition of compliance with implementation-specific choices of this nature.

  CSP has a chance to make a significant impact on Cross-Site Scripting, one of the most pervasive and difficult to prevent web application vulnerabilities, and one that is employed specifically against individual users, often to identify them and violate their privacy.  User interest is at the heart of our work and we have considered privacy very carefully, but the consensus of the group seems to be that it is not a good tradeoff to add requirements that would either be ignored by implementers or which would lead to CSP never being used, especially when the best reasons presented for doing so are edge-cases that are already forbidden and which nobody has yet encountered, or futile, token and possibly counter-productive efforts at achieving an impossibility.

Brad Hill



> -----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
> 
> On Wednesday 17 October 2012 16:02:13 Adam Barth wrote:
> > What you've written below is nonsense.  Please stop trolling this
> > mailing list.
>

Received on Thursday, 18 October 2012 23:11:12 UTC