- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Mon, 03 Mar 2014 10:10:53 +0100
- To: Joel Weinberger <jww@chromium.org>
- CC: "Oda, Terri" <terri.oda@intel.com>, Michal Zalewski <lcamtuf@coredump.cx>, Mike West <mkwst@google.com>, Dan Veditz <dveditz@mozilla.com>, Egor Homakov <homakov@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Eduardo' Vela <evn@google.com>
On 01-Mar-14 01:36, Joel Weinberger wrote: > Sorry to jump in so late here. From my perspective: Good with more opinions, so thanks for the input. :) > * CSP reporting is a tremendously valuable tool for Web developers in > testing CSP before they release it. Agreed. There is a lot of potential information the browser could give to web developers which would be tremendously valuable for them. Which sites the user normally browses, what kind of ad he is most likely to click, time and money spent online, user profile, etc. All of this would enable web developers to build better and more customized sites. That something is valuable for web developers does not necessarily mean we should enable it though. See e.g. Do-Not-Track for lots of discussions around this topic. As specification writers, it is our job to ensure the longevity and success of the web platform. This success depends on users faith in it, that they can use it safely and privately. Developers need for more information in order to enable a feature, is a short term strategy. If the feature is sufficiently valuable, developers will find a way to enable it anyhow, as they have done with other features. Many other features are intentionally crippled, to hide information that developers would really want, XHR and CORS have been mentioned as examples before. Revealing private information in this case, exclusively for the benefit of developers, would break with a long standing principle on the web. It undermines a number of other features and specifications, for instance img events being filtered on third party sites. Those specifications will need rewriting, as the security considerations in them no longer apply. Enabling this would be a tradeoff, convenience for web developers vs privacy for web users. To me, the latter wins every time. > Dan Veditz has me pretty convinced that on > pretty much any site that isn't plaintext behind the login, you can > already test this. Agreed. But this is not a valid argument to enable this by default in browsers. 70-90% of websites are reported vulnerable to XSS[1], this is not a valid argument that we should abandon the Same Origin Policy, even though this would be tremendously useful to developers, and sites are already vulnerable. Some sites are not vulnerable to logged-in detection, and allowing CSP reporting makes those sites vulnerable. That in itself is a sufficient reason for me not to allow reporting. This is also a clear indicator that CSP reporting opens up a new security hole on the web, and breaks the principles the web is built on. Sites which become attack targets, may want to protect themselves, but this may be impossible due to CSP. That in itself is a sufficient reason for me not to allow reporting. The threat scenario on the web may (will) change over the next years. CSP reporting blocks one way web sites and specifications can respond to this. That in itself is a sufficient reason for me not to allow reporting. > it's all about tradeoffs Agreed. Convenience for developers versus privacy of users, creating holes in existing web sites, undermining other specifications, the principles of the web and future security and flexibility of it. I find it strange that we are even having this discussion... [1] http://www.applicure.com/solutions/prevent-cross-site-scripting-attacks -- Sigbjørn Vik Opera Software
Received on Monday, 3 March 2014 09:11:32 UTC