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

RE: Proposed text for privacy requirements

From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
Date: Wed, 3 Mar 2010 06:10:01 -0800
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD10EE70F9@BD01MSXMB015.US.Cingular.Net>
To: "Thomas Roessler" <tlr@w3.org>
Cc: "Dominique Hazael-Massieux" <dom@w3.org>, "Frederick Hirsch" <frederick.hirsch@nokia.com>, "W3C Device APIs and Policy WG" <public-device-apis@w3.org>
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.

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.

Bryan Sullivan | AT&T

-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org] 
Sent: Wednesday, March 03, 2010 1:52 AM
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
> "* 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
Received on Wednesday, 3 March 2010 14:10:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:18 UTC