Re: Proposed text for privacy requirements

Le dimanche 28 février 2010 à 11:03 -0500, Frederick Hirsch a écrit :
> I'd like to propose the following draft text for the Privacy portion  
> of the  "Device API Security,Privacy and Policy Requirements" document  
> [1].  (We can merge this rough draft with the text that Dom provides.)  

I guess the gist of what I had in mind (behind my ACTION-95) refers to
what is mentioned below as "minimization"; in terms of requirements it
induces, what I had in mind was:
• APIs SHOULD make it easy to request as little information as required
for the intended usage;
• APIs SHOULD make it possible for user agents to convey the breadth of
information that the requester is asking for;
• APIs SHOULD make it possible for user agents to let the user select
and filter information before it is shared with the requester

My comments on the other aspects raised by [PrivacyIssuesGeolocation]
below.

> The following aspects of privacy should be addressed with more  
> detailed requirements [PrivacyIssuesGeolocation]:
> Appropriateness - is the information collected appropriate to the  
> context

This is probably one of the key topics on which we need to take a
stance: should our APIs have and/or require hooks that allow Web sites
to state their intended usage for the said API?

This has been already discussed quite a bit in the Geolocation WG; one
of the outcomes of these discussions was that browsers vendors didn't
want to show information as part of the "chrome", to avoid confusion
about the trustiness of the said information.

I guess I'm not sure how much effort was put in designing a way for
providing that information, while avoiding the trust issue; some
possible (semi-random) thoughts: a link to an anchor in the page or to
an external page?

> Consent - Is the user in control of decisions to disclose information?  
> How is this control manifested, per use, per recipient, etc.
> What is the model, opt-in, opt-out?
>
> Transparency and Feedback - Are flows of information transparent to  
> the user? Can the user access log information?

I think we already agree on the idea that possibly privacy-sensitive
APIs require user consent one way or another, preferably through a user
action integrated in its workflow, and preferably in a non-blocking
fashion. How much of this can be enforced in terms of normative
requirements in the APIs is something that we'll still need to figure
out.

But the second aspect of this is the question of persistence of this
consent; I think this is a much less clear territory; there are I guess
two approaches to this aspect: leave it entirely to user agents (and let
the market decide), or integrate it in a policy framework of some sort.

> User Control - Does the user have control over the sharing of  
> information, active or passive? Are there defaults?
> 
> Notice - What information is provided to the user by the entity  
> requesting information regarding that request? Can a user attach rules  
> regarding use to the information provided?
>
> Secondary Use - Is consent required for secondary use?  Are there  
> mechanisms for setting limits or asking permission?
> 
> Distribution - Can the entity requesting the information redistribute  
> it?
> 
> Retention - Can policy statements about retention be made? Is the  
> information provided with a timestamp to enable retention limits?
>
> Aggregation - Can information be aggregated, are persistent unique  
> identifiers used?

At our API-design level, I think these points all relate to attaching
policy information to the data when sharing them; the main objections
that were raised on this in the Geolocation WG were:
• getting the user to understand and set rules on sharing their
information is really hard
• 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
• developers are very likely to ignore policy data sent along with the
data they're actually interested in, and not be in a position to act
upon these policies even if they wanted to

I guess some concrete input on how to go around these problems would be
most welcome.

Dom

> [PrivacyIssuesGeolocation] Doty, N. Mulligan, D. Wilde, E. "Privacy  
> Issues of the W3C Geolocation API". UC Berkeley School of Information.  
> 24 February 2010. URI: http://escholarship.org/uc/item/Orp834wf

Received on Monday, 1 March 2010 13:32:51 UTC