Towards best practices for privacy in APIs

Hi,

During the workshop we discussed the possibility of gathering best 
practices for API design that focus on privacy. We also discussed 
setting up a place where we could document how implementations had dealt 
with privacy aspects of certain APIs (e.g., <input file> and geolocation).

In my paper [1], I used a simple critical framework (based on Daniel J. 
Solove's 2007 book The Future of Reputation [3]) for doing such 
evaluations based on accessibility, control, and confidentiality. The 
framework served its purpose for the short paper I wrote - but we 
obviously need something better.

Other sources, such as Nick Doty, Deirde K. Mulligan and Erik Wilde's 
paper "Privacy Issues of the W3C Geolocation API" [2], provides a more 
comprehensive critical framework based around appropriateness, 
minimization, user control, notice, consent, secondary use, 
distribution, retention, transparency and aggregation.

Daniel J. Solove book, Understanding Privacy [5], also provides an 
extensive taxonomy which could potentially be applied as a critical 
framework to evaluate and discuss privacy aspects of implementations. I 
don't know if anyone has actually done that or not in the literature.

Another interesting framework we could look at is the one that is the e 
seven principles of the OECD’s recommendations for protection of 
personal data, which are summarized on Wikipedia [4]:

[[
  Notice — data subjects should be given notice when their data is being 
collected;

  Purpose — data should only be used for the purpose stated and not for 
any other purposes;

  Consent — data should not be disclosed without the data subject’s consent;

  Security — collected data should be kept secure from any potential abuses;

  Disclosure — data subjects should be informed as to who is collecting 
their data;

  Access — data subjects should be allowed to access their data and make 
corrections to any inaccurate data; and

  Accountability — data subjects should have a method available to them 
to hold data collectors accountable for following the above principles.
]]

To get the ball rolling, in my paper, I made the following 
recommendations. I don't suggest we use we use this exact wording, as 
the following is just a slightly modified copy paste from my paper.

1. Browsers must avoid confirmation dialogs that don’t allow users to 
make informed decisions.

2. Digital signatures must be only used to verify data integrity and 
verify continuity of authorship, and should not exclusively be used as a 
means of enabling APIs.

3. Where device capabilities are required by applications, those 
capabilities must be declared by the author up-front. Where capabilities 
are declared and potentially affect a user’s privacy, the system must 
provide a user interface to view which capabilities will be used by an 
application.

4. As exemplified by the Geolocation Spec, and where necessary, 
standards bodies must mandate that conforming user agents provide user 
interfaces that give end-users access and control over privacy preferences.

5. Where it makes sense, it must be possible to change providers – 
particularly third-party providers. And where the provider is a third 
party, the provider’s privacy policy must be accessible and 
intrinsically linked in the user interface.

6. Communication between the provider and the client must be encrypted, 
particularly in the case of third-party providers.

7. Browser vendors must work together to reach de facto or de jure 
standardization of iconic activity indicators (as has effectively been 
achieved with the padlock indicator for secure communication).

8. Policy and law makers should work with the public to come up with 
more accessible privacy policies (i.e., like the creative commons icons, 
but for privacy policies).

9. When it comes to storing privacy choices that an end-user has made, 
such as which provider to use, those choices should be treated as 
sensitive data and appropriately secured via, for example, cryptographic 
means. End user’s should be informed of any attempt by a third party to 
temper with their choices.

I would like to add this one too:

10. Where possible, a "reverse cookie" or "rule set" should be used to 
give users control over how their data is used/stored by a third party 
(as third parties do when they sent data to clients).


Kind regards,
Marcos

[1] http://datadriven.com.au/2010/06/privacy-of-geolocation-implementations/
[2] http://escholarship.org/uc/item/0rp834wf
[3] http://docs.law.gwu.edu/facweb/dsolove/Future-of-Reputation/text.htm
[4] http://en.wikipedia.org/wiki/Data_Protection_Directive
[5] http://docs.law.gwu.edu/facweb/dsolove/Understanding-Privacy/
-- 
Marcos Caceres
Opera Software

Received on Wednesday, 21 July 2010 15:52:54 UTC