W3C home > Mailing lists > Public > public-tracking@w3.org > September 2012

Designing privacy into the User Agent

From: Fred Andrews <fredandw@live.com>
Date: Wed, 19 Sep 2012 03:01:49 +0000
Message-ID: <BLU002-W15199D2BEA36B8CE1D9078BAA9B0@phx.gbl>
To: "public-tracking@w3.org" <public-tracking@w3.org>

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

 		 	   		  
Received on Wednesday, 19 September 2012 03:02:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:34 UTC