- From: Mike West <mkwst@google.com>
- Date: Fri, 14 Sep 2012 09:20:17 +0200
- To: Fred Andrews <fredandw@live.com>
- Cc: Adam Barth <w3c@adambarth.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi, Fred! On Fri, Sep 14, 2012 at 2:46 AM, Fred Andrews <fredandw@live.com> wrote: > Browser fingerprinting exploits information about the UA to identify users, > see: https://en.wikipedia.org/wiki/Device_fingerprint What you call "fingerprinting", many web developers call "feature detection". You're correct in saying that more information about the browser's capabilities allows more specific identification of the browser, but in this case, the data isn't personal: the fact that CSP is supported can generally be determined from the user-agent string. Anything that claims to be Chrome 16+ can be assumed to support CSP. Moreover, dropping reports on the floor does little, if anything, to prevent a determined web author from probing the client's capabilities. As Erlend notes, the server can look for the absence of requests, or can do clever things in JavaScript like checking for error events or measuring element sizes. Prevention is impractical at best. >> In fact, that's commonly a goal of new features. In CSP 1.1, we plan >> to add an explicit mechanism for the server to detect which CSP >> features the UA supports. > > Is there a compelling need for the server to be able to detect CSP? The need isn't server-side, it's client-side. The API currently specified as experimental in CSP 1.1 (https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#script-interfaces--experimental) is there in response to requests from JavaScript frameworks and libraries which need to run in a variety of contexts. They require information about the context in which they're executing in order to make decisions about implementation. See the "Usage" section of the spec for some examples. -mike
Received on Friday, 14 September 2012 07:21:09 UTC