Re: comments on "Privacy Considerations for Web Protocols"

Hi Nick,

thanks for the comments.

On 05/29/2014 10:38 AM, Nicholas Doty 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.

I see two approaches, namely:

1) Omit the entire paragraph and therefore to be silent about the lack
of a definition.

2) Briefly indicate that this document does not attempt to define a one
sentence definition of privacy. A possible sentence could read as follows:
"
Note that this document does not try to attempt to define the term
'privacy'. We therefore follow the approach taken by
[IAB-PRIVACY-CONSIDERATIONS].
"

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

This process related aspect might actually need to be moved into the
document Frank had been working on since his document is focused on the
process aspects.

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

Yes. I agree.

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

Maybe it should say "... privacy notices are often used by parties that
deploy software..." rather than stating the more generic notice &
consent example.


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

Would it sound better to say "To what degree designed protocol subject
to fingerprinting?"?

> 
>> 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 would actually briefly summarize design decisions in a document itself
(particularly if they are special, or contentious).

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

Certainly.

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

I would prefer to move it to the W3C github. It would be great if you
could do that.