RE: CSP 1.0: relaxing mandated enforcing and monitoring to avoid

Dear Brad,

Thank you again for the insights.

I appreciate that the w3c might view fingerprinting and tracking as inevitable, but their options appear to be rather constrained by interest groups.  Users do not have such constraints and UA development driven by user needs may well be able to address this issue.

Note that the firefox 'noscript' extension webpage currently reports 2,180,733 users, and the Ghostery extension 675,177 users.  There is some interest in such tools - even if they have knobs on them.

CSP could have also helped improve safety for users interested in privacy and could have complemented their needs, so it is a bit disappointing that their needs can not be considered.

It should be possible for content servers to choose to support both the published CSP and users interested in privacy by not requiring reports be returned, not depending on being able to trip their own restrictions, and not depending on DOM access.

Policy based solutions to tracking, such as DNT, just increase the fingerprint surface - its good for a laugh though.

There are many sources of leaks, but there are technical solutions to address large classes of these leaks.  I see it as quite practical for children and new web users to start with such UAs as they would be inherently safer and less of a cognitive burden.

It is true that a privacy sensitive UA would be identifiable from current standard UAs - it can probably not all be spoofed well.  These UAs would need a significant share of usage for protection.   By design and necessity they would all want to appear the same which would help improve their share.  Privacy is not an all-or-nothing matter, and improved privacy and safety may well be enough for many users.

cheers
Fred

From: bhill@paypal-inc.com
To: fredandw@live.com; eoftedal@gmail.com; w3c@adambarth.com
CC: public-webappsec@w3.org
Date: Fri, 14 Sep 2012 22:16:10 +0000
Subject: RE: CSP 1.0: relaxing mandated enforcing and monitoring to avoid









Fred,
 
The rough consensus of folks at the W3C these days seems to be that, as currently built, tracking/fingerprinting is an almost inevitable and unavoidable consequence
 of the general-purpose web browser.  That’s not a value judgment, just a statement of fact that’s becoming more true every day. 

 
That’s why the Tracking Protection Working Group (http://www.w3.org/2011/tracking-protection/) is
 focusing on a policy-based solution rather than trying to make tracking technically impossible. 

 
Users who seek to avoid the technical possibility that their browser will be fingerprinted really need to seek out a user agent that is specifically designed
 with that goal in mind.  Even if we surfaced to the user the option to disable reports, other parts, or all of CSP, it would only be a small part of a giant list of such opt-outs the user agent would need to provide for meaningful protection.  Such a list
 would be unapproachable by the average user, and just the act of customizing it would likely result in a browser that’s even more uniquely identifiable than the one they started with.
 
We’re not trying to shirk responsibility here, but it’s just not a problem we can solve in this group, or even incrementally provide options that are meaningful
 to more than a vanishingly small fraction of users.
 
-Brad Hill
 



From: Fred Andrews [mailto:fredandw@live.com]


Sent: Friday, September 14, 2012 8:12 AM

To: Erlend Oftedal; Adam Barth

Cc: public-webappsec@w3.org

Subject: RE: CSP 1.0: relaxing mandated enforcing and monitoring to avoid


 


 

> From: 
eoftedal@gmail.com

> Date: Thu, 13 Sep 2012 22:12:44 -0700

> To: fredandw@live.com; 
w3c@adambarth.com

> CC: public-webappsec@w3.org

> Subject: RE: CSP 1.0: relaxing mandated enforcing and monitoring to avoid

...

> But is there really a way of removing the possibility of detecting if

> CSP is implemented? The website could always just have the browser

> visit some pages with CSP enabled and see which requests come through.



Yes, if the reporting is opt-in and violations are reported to the user and cause

the embedded widget to halt.   Servers would not be able to probe using the report-only

return channel, and content that tried to trip its own restrictions to probe the clients

implementation could be detected by the client and alert the user or be inhibited.



cheers

Fred