Re: CSP 1.0: relaxing mandated enforcing and monitoring to avoid probing and to avoid content being written to depend on CSP.

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