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

> From: mkwst@google.com
> Date: Fri, 14 Sep 2012 09:20:17 +0200
> To: fredandw@live.com
> CC: w3c@adambarth.com; public-webappsec@w3.org
> Subject: 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.

If someone can be tagged then they can be tracked and it is often easy to
identify them by correlating their actions and by the timing of their actions.

> 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.

Erlend's concerns have been addressed.  If CSP reporting is op-in and
if CSP restrictions are implemented as a trip-wire then probing can
be reliably detected.

Leakage of private information need not an be an all-or-nothing matter.   Viewing

it this way is about as useful as viewing security as an all-or-nothing matter.

Preventing larger classes of leakage is actually quite easy - how practical the
solution is probably depends on your perspective.  If the solution doesn't support
Google Analytics and other tracking schemes used by other w3c interest groups
then I can appreciate it would be viewed as 'impractical' to them, however the
solution could be very practical for a larger class or users.

> >> 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.

So let me get this straight.  You propose to expose the CSP policy to attacking
injected scripts allowing then to search all policy for an attack approach without
detection or to otherwise lay dormant without detection?

And all for the purpose of allowing 'frameworks' to conveniently inject Google Analytics
tracking.

What can I say.

cheers
Fred