- From: Fred Andrews <fredandw@live.com>
- Date: Thu, 20 Sep 2012 15:02:01 +0000
- To: Rigo Wenning <rigo@w3.org>
- CC: "public-privacy@w3.org" <public-privacy@w3.org>
- Message-ID: <BLU002-W19FAAEE1E8547D9168C7D9AA9A0@phx.gbl>
> 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 account. 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 applications. * 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. cheers Fred
Received on Thursday, 20 September 2012 15:02:35 UTC