Re: comments on "Privacy Considerations for Web Protocols"

>> 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.

Nick, I think you are thinking of some of the W3C workshop papers, e.g. http://www.iab.org/wp-content/IAB-uploads/2011/03/frederick_hirsch-revised.pdf

The following may also be relevant: “Web Application Privacy Best Practices”, W3C Note, http://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/

I think what this paragraph from Hannes is also saying, and maybe we should clarify, is that privacy requires a system view, end-end, and this is what applications and implementers are able to analyze, while individual specifications are often components. The security and privacy considerations for components can highlight minimization and potential vulnerabilities and countermeasures, but overall issues like data retention and reuse (to give two obvious examples) usually cannot be addressed in a specification in isolation.

regards, Frederick

Frederick Hirsch, Nokia
@fjhirsch



On May 29, 2014, at 4:38 AM, Nicholas Doty <npdoty@w3.org> wrote:

> 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?