W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Re: Proposed text for privacy requirements

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 3 Mar 2010 10:51:51 +0100
Cc: Thomas Roessler <tlr@w3.org>, "Dominique Hazael-Massieux" <dom@w3.org>, "Frederick Hirsch" <frederick.hirsch@nokia.com>, "W3C Device APIs and Policy WG" <public-device-apis@w3.org>
Message-Id: <5340726C-49B4-4F86-8802-87E671B6CC23@w3.org>
To: "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>
On 3 Mar 2010, at 08:27, SULLIVAN, BRYAN L (ATTCINW) wrote:

> As Dom points out, these aspects are not so easily solved. This is part of what I referred to as a "can of worms".
> 
> Before we go too far with attempting to create normative requirements re policy and policy expression language use, the implications on the user experience and real-world limitations on enforcement need to be addressed.
> 
> " getting the user to understand and set rules on sharing their information is really hard"
> And scary. The more controls (which hint at risks) you give a user, the more they get the correct impression that this is a risky business and maybe not worth the effort.

You surely aren't suggesting that we design to a model that gives a false sense of security to users?

> " if the user sets her preferences in the browser, she would expect the browser the enforce these preferences while the browser cannot control the data once it's been transmitted"
> Once it's in the hands of some other system, all bets are off. Only when there is some "self-destruct" mechanism that enables auto access revocation, or some mechanism that enables the customer to use the data without ever really knowing what it is, this problem will not be solved. Trust in the receiver is as far as you can go.

You're arguing from a false dichotomy here.  The point of policy expression on the data processor's side is to have them make promises about what they will do, and to later on hold them accountable to those promises.
Received on Wednesday, 3 March 2010 09:51:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:06 GMT