Re: Remove paths from CSP?

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