comments on "Privacy Considerations for Web Protocols"

Hannes and Privacy Interest Group folks,

I promised long ago to send comments on the July draft of "Privacy Considerations for Web Protocols" document that Hannes has put together. I hope these notes will be useful for improving that document and for discussion of our privacy/security guidelines discussion in general.

Re: http://www.tschofenig.priv.at/w3c-privacy-guidelines.html (which notes last update on 18 July 2013). I've quoted sections from the document below in order to provide some comments.

> This document does not attempt to define what privacy is (in a Web context). Instead privacy is the sum of what is contained in this document. While this may not be exactly what most readers would typically assume but privacy is a complicated concept with a rich history that spans many disciplines and there remains confusion over the meaning.

While I generally like the idea of not over-defining a plural concept such as privacy, I'm not sure about this paragraph. In particular, a subsequent paragraph in the Introduction makes the same point. That being said, I'm not sure "sum of what is contained in this document" is correct either. I think our goal isn't to touch on everything that privacy might be, but to identify some areas key to Web protocols.
> Whether any individual document warrants a specific privacy considerations section will depend on the document's content. In some cases privacy may be part of the security considerations or may not be relevant to certain specifications at all. In some other cases a fruitful discussion about privacy properties of a system requires several specifications to be evaluated in concert to offer meaningful guidance. 
> 
+1. As a process matter (and maybe this goes to our SPA doc as well), I don't think a mandatory section is a great approach. Also (and see comments later on), we may want to explicitly suggest that privacy and security reviews and privacy and security guidance be done in concert.

> Changing the underlying security and privacy foundation typically leads to modifications of the entire architecture. Consequently, it is wise to consider security as well as privacy early in the design process. With regard to the level of privacy and security investigations the goal is not to be exhaustive (such as by producing as much text as possible) but rather to capture the most important aspects. Unfortunately, security  and privacy experts will often not be available in the early design phase since there are too few of them around. Hence, it is important to produce a writeup that allows those from the security and privacy community to quickly capture the main architectural spirit of the newly designed API feature, or protocol. It is too easy to get lost in details and feedback from external reviewers will ensure that potential concerns are identified early.

I generally like this approach: both the identify early and the issue-spotting/write-up for external expert reviewers. Since this is more process-oriented, can we move this (or coordinate) with the SPA process doc?

> For example, notice and consent is best realized by parties that implement and deploy software rather than by those who purely develop specifications since many deployments use non-standardized functionality for informing their user base about the privacy properties of their service and for obtaining the users consent before they are able to use the service.

I like the idea of explicitly noting which principles will tend to be addressed where (in standards vs. in deployments, which "parties"). I think DAP folks (Frederik?) have done some writing on best practices for deployers and implementers, for example. That being said, I'm not sure notice and consent are purely implementer/deployer-focused, since permission scoping and granting as well as hooks for notices are often determined during API design.

> The following questions are relevant for specification authors: Is the designed protocol vulnerable to fingerprinting? If so, how? Can it be re-designed, configured, or deployed to reduce or eliminate this fingerprinting vulnerability?

Should we be using terms like "vulnerability"? (Maybe so, it just made me think when reading through.) In general, for security threats but especially for privacy, I think we're going to refer to minimizing or mitigating rather than eliminating.

> Does the protocol make trade-offs between privacy and usability, privacy and efficiency, privacy and implementability, privacy and security, or privacy and other design goals? Capture these trade-offs and the rationale for the design chosen.

This is more a general comment for our process rather than a comment on this particular section: should we be capturing the trade-offs and privacy-relevant design considerations in a section of the specification itself? Or in a separate privacy review doc during the process?

I hope these comments are helpful. Maybe a next step would be to try applying these guidelines (and the questions on minimization) to a review of a recommendation, like the reviews of past RFCs going on over at IETF.

—Nick

P.S. Hannes, should I send pull requests about this version of the document?
	https://github.com/hannestschofenig/tschofenig-ids/blob/master/w3c-privacy-guidelines/index.html
Or can we set this up in the Github w3c organization?