RE: CSP formal objection.

Hi Mike!

The original dispute was not just about 'fingerprinting'.  The dispute was hijacked, and misrepresented as just being about fingerprinting, and then the argument was made the fingerprinting is inevitable and thus CSP leaking more state is not significant.  Please do not attempt such strategies again, I find it offensive, and are wiser to the strategies used.  Please focus on the use cases and requirements, and the technical design of the specification for a conforming web browser.

I do not believe there is a valid technical case for making reporting a requirement for a conforming user agent.

* A desire by some service providers that reporting should be ubiquitous is not a valid use case or requirement and thus not a valid input into the design process.  The user is always free to opt-in if the reporting is in their best interests.

* The claim was made that the UA is still free to do as it wishes and thus websites could not depend on reporting.  However the CSP is a specification for a conforming UA, hopefully a common default that we endorse as being in the best interests of users, and a web site discriminating against conforming UAs will have much less standing.

* The claim was made that the UA could just not implement CSP.  However this excludes the UA from much of the benefits of the CSP.  There is no valid reason to link a UA benefiting from CSP to a requirement that the UA report in a particular manner.

* A lot of claims were made that securing the UA state was not a valid requirement, that the UA is already leaky.  I dispute this.  It depends on the environment that the UA connects to and there are many basic cases in which a UA controlling reporting would be effective.  It also ignores further defenses that the UA could take.

I believe there is a good technical case to make for reporting to be opt-in - a recognition that the user trusts the web site and wishes to report a violation to help the web site improve its CSP, but that in general users would be better not to be exposed to the risks of reporting.  Enabling reporting should be the exception not the default.

* I would like to see the CSP specification framed in a manner that makes it absolutely clear that the CSP is advisory information supplied by the web site to the UA with the intention that it defines constraints under which the web site will operate and that a conforming UA could choose to selectively enforce these constraints for the benefit of the user.

* The CSP specification should make it absolutely clear that reporting is feedback that could help a web site detect problems with these constraints.

* It should be absolutely clear that the CSP is not intended to move security from the UA to the cloud via reporting.  That a web site is not expected to be able to depend on reporting or to use the reporting to provide a security service.

* It should make it absolutely clear that reporting could be used to monitor or discriminate against the user and thus reporting is opt-in and not the default, and that a UA may need to implement further defenses.  Some mention of extensions would be relevant in this context.

Give recent actions by the Director of the W3C, making wild disputed interpretations of the principles of the web, it is no longer possible to just assume an interpretation and it will be necessary detail the interpretations being applied in the specification.

cheers
Fred

From: mkwst@google.com
Date: Fri, 7 Feb 2014 15:20:13 +0100
To: fredandw@live.com
CC: public-webappsec@w3.org
Subject: Re: CSP formal objection.

Hi Fred!
On Fri, Feb 7, 2014 at 8:31 AM, Fred Andrews <fredandw@live.com> wrote:





It seems that the technical issues have not been solved, and the UA vendors have not followed though with the commitments made, and this changes the landscape so I reopen the dispute.

Really? My impression is that Chrome does a generally reasonable job with extensions (though a less reasonable job with bookmarklets). There are edge cases that we don't have good solutions for, but I'd hardly call the state of affairs dire. If that's incorrect, please do submit bug reports. I'll do my best to fix them.

I would like the CSP to be amended to note that the sending of CSP reports is optional in a conforming implementation and that the UA should expect a website to supply a useful CSP that does not depend on the website implementing an overly broad CSP and analyzing the reports.


I don't really understand this sentence. Can you explain what you mean with regard to the UA's expectations with regard to the website?
In any event, I assume the request relates to the discussion we had at the end of 2012[1, 2] regarding fingerprinting. My impression was that we'd resolved that in the WG (though I recall that you didn't agree with the consensus reached).


[1]: http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0029.html[2]: https://www.w3.org/2011/webappsec/track/issues/11


--
Mike West <mkwst@google.com>Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91



Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891Sitz der Gesellschaft: HamburgGeschäftsführer: Graham Law, Christine Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)