RE: Proposed text for privacy requirements

I completely agree that accessible, understandable, and comprehensive
disclosures of policy to users are an expectation of most trusted sites.
The reputation of the site owner or app publisher also goes a long way,
especially if policies are easily accessible and the user's experience
shows that they are accurate. We focus our disclosures on websites
because that's the most effective place to communicate with the user.
But we also promote easy access to these policies through menus and
other "about this app" type features of applications, which can provide
a summary of the policy (and if possible, the status/control of user
preferences related to them), or at least link to the same sort of
info/controls on a support website.

Doing these things on small devices is problematic from a usability
perspective (e.g. it's hard to be both understandable and comprehensive
on a small-screen device). But there can be a good balance between
summarized local info and more complete remote info.

Overall, I think it's good for W3C to consider recommendations for what
this info should be (as in Geolocation). There are also some good
examples of how simple info and controls can be provided to the user
(ala one-shot/session/blanket security prompts) in MIDP and BONDI. But
more broadly, how this info and related controls are provided to the
user are best left to implementations.

Thanks, 
Bryan Sullivan | AT&T

-----Original Message-----
From: Alissa Cooper [mailto:acooper@cdt.org] 
Sent: Thursday, March 04, 2010 5:00 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

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 15:31:24 UTC