W3C home > Mailing lists > Public > public-privacy@w3.org > July to September 2012

RE: Private User Agent Community Group Proposed

From: Fred Andrews <fredandw@live.com>
Date: Thu, 20 Sep 2012 15:02:01 +0000
Message-ID: <BLU002-W19FAAEE1E8547D9168C7D9AA9A0@phx.gbl>
To: Rigo Wenning <rigo@w3.org>
CC: "public-privacy@w3.org" <public-privacy@w3.org>

> From: rigo@w3.org
> Date: Thu, 20 Sep 2012 08:09:41 +0200
> One of the problems in privacy and data protection is the 
> entanglement of technical and legal matters. You may fix a leak, but 
> may be that data leak was unimportant to privacy. And you may have a 
> hole that is terrible for privacy, but closing it would break half 
> of the Web and three quarters of its business model. 

Any leak adds to the fingerprint surface so no leaks are unimportant.

Some changes will likely be needed, but at the end of the day the only
businesses models that should be broken are those covertly sharing
the UA state.

> The last time I had this discussion was when Mozilla refused to 
> implement P3P client side because cookie blockers would be so much 
> more efficient. Cookie blocking was seen as purely technical while 
> P3P was "Policy stuff". 10 years later we have cookie blockers and 
> still the same privacy problem and in the DNT work, people still 
> miss a way to express compliance to more complex privacy regimes. 

Policy based solutions are important too, because users will release private
information in some transactions and if users know the business they are
sharing information with they can judge if the business can be held to

Are the current technological solutions to address cookies inadequate?

> When we established the P3P Safezone, the P3P WG did some non-
> scientific testing whether we would break many things if we would 
> suppress the referrer header. This was not the case (and I can 
> confirm that from my current practice). We know which headers are 
> talking. 
> Remains Javascript as the new panacea for the Web. A Turing-complete 
> language can be used for almost anything. And the question remains 
> what good practices would recommend. What is good or bad in 
> practices is mainly a political question. Once you have that 
> political idea, there is a lot of technical work and insight needed 
> to describe the limitations to be established within the browser for 
> the javascript engine. This touches on security concept like "same 
> origin" as well as the work going on in the Device API Working Group 
> to remotely access things like address books (and yes, they are 
> discussing privacy). The german IT-Security administration simply 
> recommends turning ECMAscript off if one wants secure browsing.

The 'good practice' being addressed is stopping covert sharing of the
UA state.

Is this really a complex policy issue?

>From this goal it is possible to develop technical solutions.

It should not be necessary to turn off ECMAscript.  There are a range of
solutions to explore:

* restrict the back channels - but allow access to the DOM etc.

This would suit a wide range of activities, and still support rich JS driven

* restrict access to identifiable information such as the DOM etc, but allow
access to back channels.

This could suit web pages that pull in information, such as email updates, or
social networking updates, or codecs, or ad streams, etc.  The JS running
in this context could forward the information to another context that
presents the information, and could be pushed information from servers,
or triggered by intentional user actions or run on a schedule etc.

* a combination of the above contexts working together on a webpage to
provide rich content with network access, but without the leaks.

> All this to say that "technical matters" is not a scope that will 
> buy you anything.

The scope is stopping covert sharing of UA state.  This can be defined
in technical terms.

Are you suggesting that stopping covert sharing of UA state will not
buy anything?
> Again, I'm not against Nerd's corner and I applaud your initiative. 
> But I dare pointing out that it makes only sense if it is deeply 
> rooted in the broader debate happening here. That said, Community 
> Groups can do whatever. Community Groups are playground. So my email 
> shouldn't stop you from doing what you want to do. My concern is 
> rather one of wasted momentum.

The only other alternative is allowing some convert sharing of UA state
which hardly seems defensible so what could the broader debate add to
the scope?

No policy has any influence over a party that does not respect it or has
immunity from it, and no UA measures to limit covert sharing if state
can address information that the user intentionally shares.  Consideration
of both policy and control of the UA state seem to be needed.


Received on Thursday, 20 September 2012 15:02:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:23 UTC