This document explores a way of making privacy work better on the web, in a way that is understandable to users and that imposes constraints as minimal as possible on authors and implementers.
Privacy has been a hot topic in the Device APIs and Policy WG due to the sensitive nature of the information that our work intends to expose. Notably, we discussed it rather extensively during the first day of our March 2010 meeting in Prague.
The approach we've decided to take is to break the problem down into smaller, hopefully more manageable pieces:
This is the part that is explored in this document. During the F2F, I floated the idea that privacy could be (at least in part) treated as a licensing issue. When you get content from someone, you get it under a license; so when you give your data to someone, couldn't it be provided under similar terms?
Starting from there, the next step is pretty obvious: could we have a simple, limited, easily explained vocabulary in a vein similar to Creative Commons? What's great with throwing ideas against the wall early in the morning without knowing whether they might be good or if they are alcohol induced, is that one often finds out that other people have had that idea before. This is very reassuring because it entails that either you've had a good idea, which is cause for celebration, or you've found new drinking buddies. The devil is, of course, in the details.
There are many aspects that can be listed when it comes to what actions one may consider acceptable or not with given personal information. My goal is not to get into this discussion here; I will limit myself to noting that all proposals that I have seen so far still seem too complex to be comprehended.
For the purpose of having concrete content to use in the examples below I devised a rather simple privacy licensing scheme intended primarily to be readable. Most notably I completely gloss over legal issues that vary across locales (e.g. in French law it's illegal not to make it possible for someone to update data concerning them). There are two actions that a service may take with one's data — retention and redistribution — and a modifier on both which is whether it will be in aggregate or not.
nr) which
means that the data gets thrown away when your interaction session stops, short term
(sr) which means that the service keeps the data for a limited time, and permanent
(pr) which means that it will never forget it (or perhaps only in specific cases, such
as account deletion).
red) indicating whether the information may be provided to third-parties
whoever they are. Cases in which a service is forced to redistribute information (being held-up at gunpoint,
being forced by a legal search, etc.) do not count as redistribution.
a is added to either of the previous tokens.
This yields a small set of simple codes. If you keep my data for three months, and show the anonymous countries
from which your users come from on a publicly accessible map: sr-reda. If you want my name to
generate anagrams but don't keep it: nr. If you're keeping my birthdate permanently but only
using it to wish me a happy birthday: pr. If you're gathering my email address to sell it to
spammers at every occasion: pr-red. If you're keeping a permanent, internal track of your users'
first names: pra.
This section lists all the various implementations options that can be thought of. This is just a first draft containing the ideas that I can think of off the top of my head. It is not complete. I have deliberately not filtered out anything.
Some of the solutions are service-initiated while some are user-initiated — it is not clear at this point where to best place the weight here. There may be room for more or less negotiated options, but those are likely to be more complex. Some options for how to handle this at the UI level are included as well.
Last update: 2010-04-01
A site indicates its policy in its response headers, like P3P. For instance:
Privacy: pr-red.
Services simply add a set of well-known icons to their content, just like CC.
rel value
A new rel value of "privacy" is introduced:
<link rel='privacy' href='http://w3.org/plic/sr-reda'/> <a rel='privacy' href='http://w3.org/plic/sr-reda'><img .../></a>
An HTTP header is sent with ever HTTP request indicating the user's stated privacy preferences,
e.g. Accept-Privacy: sr-reda. Such preferences are presumably configured in the UA.
Services must either comply, or refuse the request.
...
An service may wish to conform to the user's preferred licensing terms. An API such as
window.navigator.privacyLicense could return that.
The browser acquires the privacy licensing metadata and displays it in the chrome.
The browser acquires the privacy licensing metadata and displays it contextually with the interaction that the user is making. For instance, if the user is filling out a form, the browser provides an indication of whether it matches the user's intended preference. In that case, a large, red tooltip could appear next to the field that the user is filling out stating “This service does not comply with your preferred privacy.” By being in the content it is very user-visible, but does not have chrome-level “trust”; since it is non-modal it doesn't get killed.