Re: Designing privacy into the User Agent

Hi Fred,

This message and follow-up discussion is probably better suited for the Privacy Interest Group rather than the Tracking Protection Working Group (moving public-tracking to BCC). As you note, these suggestions are about privacy controls for standards and user agents generally, rather than online tracking in particular.

We've heard a couple of suggestions [0] that these work items could be brought into the Privacy Interest Group (where interest has been expressed around guidance for fingerprinting and privacy reviews of other specs, including CSS issues). And the PING has a call on Thursday [1], perhaps you could join us to discuss?

Thanks,
Nick

[0] http://lists.w3.org/Archives/Public/public-privacy/2012JulSep/0058.html
[1] http://lists.w3.org/Archives/Public/public-privacy/2012JulSep/0059.html

Begin forwarded message:

> Resent-From: public-tracking@w3.org
> From: Fred Andrews <fredandw@live.com>
> Subject: Designing privacy into the User Agent
> Date: September 18, 2012 8:01:49 PM PDT
> To: "public-tracking@w3.org" <public-tracking@w3.org>
> Archived-At: <http://www.w3.org/mid/BLU002-W15199D2BEA36B8CE1D9078BAA9B0@phx.gbl>
> 
> 
> A proposal has been submitted to create a community group to engineer
> solutions to privacy at the user agent and this could also help
> address some of the tracking concerns.  Two more sponsors are
> currently needed to get this group started, so if this issue if of
> interest to you then please see:
> http://www.w3.org/community/groups/proposed/#pua
> 
> The burden on sponsors should be relatively low as the matters are
> largely engineering and much of the work is expected to take place in
> a public mailing list.
> 
> Developing the designs in public under the W3C Patent Policy may help
> protect against patents on privacy technology and help bring better
> awareness of the issues and solutions to other groups.  Help
> sponsoring this group would be appreciated.
> 
> The new group will not be addressing privacy policy matters or
> mechanisms for users to declare tracking or privacy preferences to
> servers or content providers.
> 
> The group will focus on engineering privacy into the UA and it is
> expected that proposals will be largely testable against their
> effectiveness at achieving privacy while preserving functionality and
> convenience for users.
> 
> It would appear that privacy can not be achieved without some
> restrictions which will inevitable cause some loss of functionality.
> The development of designs and extensions to mitigate such loss is
> proposed to be within the scope of the group.
> 
> Some examples of the approach I advocate as a starting point may help
> you decide if they wish to be involved:
> 
> * Javascript has access to a wide range of information about the UA
> and has access to communication channels to leak this information.
> Limiting access to such information and/or limiting the back channels
> will be explored.  For example, development could proceed by limiting
> JS from access to any back channels.  This would result in a lot of
> loss of functionality, but from this staring point we could develop
> designs and extensions to mitigate some of the loss of functionality.
> For example, exploring if any access can be reopened on account of
> users having explicitly knowledge of the transmission of the
> information.  An example extension might be a declared schedule of
> resources to load that could replace JS that is currently used to load
> images for sideshows or used to load resources for animated or
> revolving advertising.
> 
> Such a restricted user agent could still support general browsing and
> content consumption, online shopping and payment, online banking,
> blogs, and a range of JS powered web apps.  It would certainly be more
> functional than a UA with JS disabled.  Web apps that depend on JS
> pulling in resources, such as AJAX designs, would not be supported
> with such restrictions, however the group could explore extensions to
> replace common patterns of lost functionality.
> 
> 
> * CSS media queries can expose private UA information by selectively
> loading resources. This could be solved by loading all resources
> before media queries are applied and developing alternatives to media
> queries.  For example, dependence on a media query for the selection
> of high contrast or black and white images might be reduced by a CSS
> extensions to declare image color and contrast transforms that would
> suit such devices.
> 
> 
> There are obviously lots of other areas to address and scrutinize for
> leaks, but this should gives some idea of the general approach.  If
> you can help in some manner your participation would be welcomed.
> 
> cheers
> Fred