- From: Alissa Cooper <acooper@cdt.org>
- Date: Thu, 4 Mar 2010 13:00:05 +0000
- To: "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>
- 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>
One thought inline... On Mar 3, 2010, at 2:10 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Re "You surely aren't suggesting that we design to a model that > gives a > false sense of security to users?": certainly not. By mentioning all > these aspects in communication to the user we would though be > *implying* > at least that we have real-time solutions to them, and I don't believe > we do. In the absence of real-time solutions, at least if the user is > comfortable that the webapp publisher and distributor have adequately > tested and certified the design of the webapp, and applied appropriate > pre-determined policies for user data access, then the user can not > worry about these details. And if something bad did slip through the > screening process, webapp permission can still be removed by > installation of a new policy or certificate revocation. Just to reiterate what I said on the call yesterday: there are apps and sites with good, user-protective policies, and there are apps and sites with not-so-good policies. For privacy at least, apps with good policies disclose those policies somewhere (usually in a human- readable privacy policy), and some apps with not-so-good policies disclose them as well, although many do not. Giving appss/sites a place to communicate the most salient points from their policies could incentivize more good policies and create transparency about what the policies are (since most people do not read or understand privacy policies as they are today). Alissa > > Re "policy expression on the data processor's side", this is useful in > the process of processor vetting (pre-approval) and auditing > (post-approval), as those will help determine initial and ongoing > trust > in the processor. But I don't see a solution to using this information > effectively in real-time, for each user and information request. > > Thanks, > Bryan Sullivan | AT&T > > > -----Original Message----- > From: Thomas Roessler [mailto:tlr@w3.org] > Sent: Wednesday, March 03, 2010 1:52 AM > To: SULLIVAN, BRYAN L (ATTCINW) > Cc: Thomas Roessler; Dominique Hazael-Massieux; Frederick Hirsch; W3C > Device APIs and Policy WG > Subject: Re: Proposed text for privacy requirements > > 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 Thursday, 4 March 2010 13:00:41 UTC