Re: Privacy by Design in APIs

Hi Robin, 

I re-read your document again. I had made remarks about the lack of terminology already and here are some more comments. 

** Target audience

You state that the target audience is  

1) those people involved in the definition of JavaScript APIs, and 
2) those who implement such an API

(1) are the standards people but I am not sure whether the second group refers to the application developers who happen to use the API or whether it refers to the browser manufacturers who add the API to their browser implementation. 

I hope you are referring to the browser implementer and not to the application developers. 
It might be useful to clarify this since the content of the document would be very different. 

** Privacy and Security

You seem to wash away the differences between privacy and security. That may sound useful but there are actually quite some differences. For security we have a fairly well understood terminology, threat modeling, and security services. See, for example, RFC 3552. Beyond the technical aspects most people understand security reasonable well in the meanwhile, and we also have processes in place to address security in the standards development process. 

The same cannot be said about privacy. In addition, the threats with privacy go beyond what security threats are concerned about. See http://tools.ietf.org/html/draft-iab-privacy-considerations-02#section-3. 

For example, the issue of what happens with information when it gets transmitted to a server and is then re-distributed beyond the originally stated purpose is indeed a real problem.

So, in a nutshell I disagree with your statement that the difference between the two is "immaterial and irrelevant". 

** Privacy by Design

There are various folks who had come up with the idea of privacy by design and they have some specific idea in mind. If you, for example, look at the work by Ann Cavoukian then you see that she has takes a certain perspective of what that means. Your list of privacy by design "requirements" or "principles" does not match to anything I have seen. Maybe you want to avoid the PbD marketing.  

You write: "It is particularly important in privacy by design that users be exposed to as few direct privacy decisions as possible. Notably, it should never be assumed that users can be “educated” into making correct privacy decisions." While this sounds indeed nice all privacy principles I have seen talk about letting the user make informed decisions. So, there is certainly a balance between letting the user have control over what they do and not getting into their way. 

"Poor Information Scoping": In some sense you are talking about "providing the user with enough information" and "letting them make fine grained access control decisions". The problem is that this is nothing the JavaScript API designer can decide about -- this is about the application designer writing his software and making a decision about what his or her application actually does and whether there are choices for the user. For example, someone writing Angry Birds could think about whether they really need access to location, phone state, sms, etc. for their application to work.  This issue goes back to the question about the target audience for the document. 

"User Fingerprinting": This section essentially says that there isn't really something one can do about fingerprinting (which is probably correct). Particularly when you consider the broader range of JavaScript APIs there is indeed a lot of information that is available (driven by the popularity of JavaScript itself).

** Design Strategies

In the three sub-sections you are essentially saying to expose as little information as possible. I don't think that is a reasonable strategy for the API standardization. As argued under "poor information scoping" this only makes sense for an application developer to ask only for the permissions they really need for their applications to work. 

The examples you provide are more driven by the community that had specific use cases in mind: At the time when mouse functionality was designed I doubt that anyone had thought about writing flight simulators in JavaScript. With more sophisticated games you may indeed want to have more information about what is attached and to make use of the available hardware features. 

To illustrate the point with the location API you could argue that it only needs to provide city-level granularity because this would be more privacy friendly. While this is true it wipes out a certain number of applications where more accurate location information is useful. For example, for the emergency services functionality it would be important to know how the location was obtained (e.g., manually entered, GPS, operator provided, etc.). 

The biggest challenge, I believe, is that the server-side that provides the JavaScript code also describes about what functionality it wants. The most important privacy decision has already been made when JavaScript-based mobile code distribution Web platform was designed. All that is then left to the browser implementer is to ask the user whether it grants access to the information or not. Since you claim that no user education can be assumed and you also don't want to ask the user too often there isn't really a lot you can do to improve privacy from an API designer point of view. 

As a summary, I don't think any of your recommendations make a difference from a privacy point of view. For the browser implementer the only recommendation seems to be: "Don't act stupid: when someone wants to upload a file don't upload the entire filesystem.". Given the history of the UI for the security lock icon this is, of course, still useful. 

I am wondering whether you (or your TAG co-workers) have gone through a couple of Web technologies to determine how the design decisions influenced privacy properties. We did this exercise in the IAB and made a couple of interesting observations, such as
  * lacking a common terminology the investigated privacy threat was interpreted differently by various participants, and changed significantly over time
  * solutions were documented but there was typically no detailed description of the privacy threats, 
  * folks worked on selected solutions that in a bigger picture made no sense (particularly with regard to what was deployed).

Ciao
Hannes

PS: I had to laugh when I read "By default, the user agent should provide Web applications with an environment that is privacy-safe for the user in that it does not expose any of the user's information without her consent."

On Mar 29, 2012, at 6:35 PM, Hannes Tschofenig wrote:

> Hey Robin, 
> 
> Have you had a chance to look at this privacy consideration document:
> http://tools.ietf.org/html/draft-iab-privacy-considerations-02
> 
> You may find some of the content relevant.
> 
> There are really basic things you need to think about first. For example,
> think about the scope of your document. Who is the target audience? A
> resulting document will look very different if you are addressing the
> protocol developers in the W3C (as compared to someone who deploys a
> complete solution).
> 
> You also do not reference any terminology, which leads to endless confusion.
> For this purpose you may want to look at this document:
> http://tools.ietf.org/html/draft-iab-privacy-terminology-01
> 
> I have plenty of additional comments but I want to get these high-level
> things discussed first.
> 
> Ciao
> Hannes
> 
> 
> 
> On 3/29/12 4:21 PM, "Robin Berjon" <robin@berjon.com> wrote:
> 
>> Hi all,
>> 
>> this is a heads up that I've started work on a TAG draft finding for "Privacy
>> by Design in APIs". It is intended to provide some strategies for API
>> designers to be as privacy-friendly as possible.
>> 
>> You can find my draft at:
>> 
>>   http://darobin.github.com/api-design-privacy/api-design-privacy.html
>> 
>> And can fork and make pull requests at (note that it's in the gh-pages
>> branch):
>> 
>>   https://github.com/darobin/api-design-privacy/tree/gh-pages
>> 
>> It's a first draft and still has a number of rough edges. Feedback is very
>> welcome on pretty much any aspect — share and enjoy!
> 
>

Received on Wednesday, 4 April 2012 07:33:27 UTC