Re: Decisions by the group

Hi Christine, Hi Tara, 

sorry for the late response. 

Your response makes sense to me and it inline with what I believe can be accomplished. 

In particular, regarding 

(1) I believe the focus on pure APIs was too small since there is other work in the W3C that desires attention from a privacy point of view. 

(2) guidance for the W3C standardization community is certainly good. (*) 

I believe you will have to discuss item #3 in the group to have a consistent approach. Having followed the discussions around the location API I had noticed that there was a huge reluctance to make use of policy preferences set by the user and attached to the location (as it moves along). When we look at the DNT work then this is exactly the approach that was chosen.  It might be too early to say which approach worked better (from a privacy protection point of view) but the two are obviously quite different. 

Ciao
Hannes

(*): In your meeting invitation, which was submitted about two weeks after this mail, you also listed another bullet that talked about privacy guidance for deployers and that would of course be different to what item #2 in this mail says. I believe a standardization organization, like the W3C or the IETF, are not a good venue for that type of work because deployments move too fast and the expertise isn't in these organizations to get this right. 

On Jul 25, 2012, at 5:11 PM, Christine Runnegar wrote:

> Hi Hannes,
> 
> Thanks for raising these important questions. This is our perspective, having regard to the charter:
> 
> 1) Our goal is to develop a guidance document for W3C standards (at large).
> 
> In particular, this would include providing guidance on:
> - identifying privacy risks/vulnerabilities associated with Web standards
> - how to build privacy into the design of a specification 
> 
> Note: there may also be value in also developing additional specific guidance for particular standards.
> 
> And, we can look more broadly if we want to.
> 
> 2) The target for the guidance document for W3C standards is the standardization community (specifically, people who develop W3C standards) and those who then deploy them.
> 
> Note: there may also be value in developing additional guidance targeting implementers and deployers (e.g. best practice documents).
> 
> 3) We do not have the answer to this one, and would encourage discussion on this list.
> 
> One thing to keep in mind is that perhaps more than one model (or strategy) may be relevant depending on the standard.
> 
> However, before we get to guidance, perhaps it would be useful for the group to identify privacy risks/vulnerabilities associated with Web standards. Again, we encourage discussion on this list.
> 
> Christine and Tara
> 
> On Jul 20, 2012, at 1:58 PM, Hannes Tschofenig wrote:
> 
>> At yesterday's conference call I was asked about my opinion what to do in the PING working group. While I tried to answer that question on the phone I am not sure I got my points accross. Here is an attempt to summarize my thoughts. 
>> 
>> There are three aspects for group members to decide:
>> 
>> 1) What is the scope of a guidance document? 
>> 
>> The W3C covers a pretty broad scope of work. In response to Robin's writeup that was focused on privacy guidance for those who develop JavaScript APIs I argued that this scope is too narrow. There is other work in the W3C that is looking for guidance as well. My favorite example is CORS.
>> 
>> What does the group think is useful to cover?
>> 
>> 2) Who is the target audience of the recommendation?
>> 
>> I had shared my views about this topic already in previous mails and tried to explain what the difference between the standardization community, implementers, and deployment is.
>> 
>> The group has to decide what the audience is because the recommendations will be different for these different groups.  
>> 
>> 3) What is your model for privacy protection?
>> 
>> Before going into the details of providing guidance it is useful to think about the main direction.
>> I have seen different themes (and all have their pros & cons). Here are some examples (and one could combine different approaches):
>> 
>> a) Notice and Consent model
>> 
>> Before the collection of data, the data subject should be provided with a notice of what information is being collected and for what purpose and an opportunity to choose whether to accept the data collection and use.
>> 
>> There are also further design aspects about when this consent should happen. One model is to push it to contracts (e.g., terms of service and privacy notices when you sign up for the service) and another model is to ask the user at the time of sharing (in real-time). As a simplified summary, the latter may require additional specific work or integration of some protocol mechanisms (e.g., OAuth) and the former doesn't. 
>> 
>> The challenges here are that sometimes (often?) the users aren't asked before sharing happens. An example from an article published yesterday about the reality: http://www.cultofmac.com/179733/19-of-ios-apps-access-your-address-book-without-your-permission-until-ios-6-report/
>> 
>> We also want to avoid notification fatigue and want to provide a good choices instead of take-it or leave-it schemes (which we see all too often today). Here is an example of a better permission dialog (of course a fake screen): http://blog.benward.me/post/968515729
>> 
>> This sounds like one has to standardize the user interface but this is not necessary. Instead, one can talk about the user interaction in an abstract way. Barry Leiba provide an example in this document for OAuth: 
>> http://tools.ietf.org/html/draft-leiba-oauth-additionalsecurityconsiderations-00
>> 
>> b) Data Minimization
>> 
>> With this approach the idea is that you figure out what data you need as a bare minimum for your service to work and design the system accordingly. Then, the end devices only provides the data to various service providers that they really need. This is an approach that is often chosen by researchers since it has a lot of impact on the overall system design. The beauty of this approach is that when information is not available to a party then that party cannot leak it or cannot share it in a a way that violates the user's expectations. 
>> 
>> One challenge is that those who design the system don't like to restrict themselves.
>> 
>> c) User preference indication
>> 
>> This model is the result of realizing the some parties already get data anyway (or have it already) and so we want to tell them how to use it. This is the GEOPRIV sticky policy approach or, a more recent approach, the DNT header. 
>> 
>> The drawback of that approach is that it heavily relies on data protection authorities (DPAs) to enforce non-compliance. Whether there will be any enforcement remains to be seen. 
>> 
>> 
>> 
>

Received on Thursday, 23 August 2012 15:12:03 UTC