PING - informal chairs' summary - 23 May 2013

Informal chairs' summary - 23 May 2013

Many thanks to Marcos Caceres for providing us with an excellent overview of the app:URI scheme and its privacy considerations.
 
Thanks very much to JC and Nick for scribing.

Regrets: Erin Kennedy, Karima Boudaoud.

The next call will be on 27 June 2013 at the usual time.

* The app: URI scheme [1] and privacy considerations (Marcos Caceres from the SysApps WG)

[1] http://app-uri.sysapps.org/#privacy

This URI scheme is currently in use in Firefox OS for "packaged applications". Similar URI schemes are used by Microsoft (Windows 8), Google (in Chrome), and currently by Opera's extension platform (widget://). The SysApps WG is trying to unify these schemes and address some of the privacy issues.

Marcos provided an overview of this scheme, noting that challenges occur when there are multiple instances of an app running, which may appear as though they are originating from different locations (causing issues for the same origin policy). This specification proposes the usage of different IDs for each app, and that each app can have its own cookie and storage to avoid overwriting other apps' data. This ID scheme, which could use a UUID approach, gives rise to the privacy concerns: every person gets a unique number, which facilitates a large amount of tracking.

Discussion ensued on this topic. Nick Doty wondered if the unique ID was necessary; Marcos pointed out that the reason was because browsers are designed to use IDs like  "app://foo/myfile.js" so this is needed to get around a massive rewrite of browser code. Further discussion focused on whether the ID needed to be persistent or not; Marcos stated that it did not need to be, but that the app would have to regenerate it. He proposed that all history would be cleared and to start with a new number; for example, if you had a Facebook app running, you would get the same cookie, but logging in would serve to identify the user. This means that it would suffice to clear all data and start with a new ID. Nick asked if there had been any pushback on this point and Marcos confirmed that there was, because users might lose their data, but he stated that this would actually be all right as mechanisms could be provided to back up the data. Wendy Seltzer supported this idea of clearing the data and asked if there were other best practices that could be incorporated. Marcos said they could ask for user consent if the domain were to be allowed to track location. Hannes Tschofenig noted some security concerns with this scheme in regards to the same-origin policy; it would be necessary to know how to reach the party you intended to communicate with (e.g., a UUID wouldn't be enough to let the application be reachable, as there is no resolution mechanism to translate the ID into an IP address). Marcos noted this was somewhat out of scope, but on a related topic, there is some consideration that instead of using an ID, one could use a human-readable string. There is some fear of hijacking: how would you download an app, verify the app and send it to the server as authorized? This may be incorporated into the app:URI scheme, as part of the complete solution.

It was noted that this is a complex problem space that could benefit from some clarity, and it is evolving; Marcos noted there has been some discussion of these points, such as using CORS and on faking origins,  looking at the implications and possible solutions, such as somehow getting a token from the server that owns a domain to prove this app is "okay." A lot more discussion of this subject seems to be warranted, which was encouraged on the mailing list.

* Security and Privacy Considerations in Proximity Events and Ambient Light Events
Nick Doty raised some questions regarding the proposed Security and Privacy Considerations [1] for Proximity Events and Ambient Light Events were addressed by Frederick Hirsch, accompanied by updated text for the draft specification [2]. Anssi Kostiainen updated the draft specifications, see:

https://dvcs.w3.org/hg/dap/raw-file/default/proximity/Overview.html#security-and-privacy-considerations
https://dvcs.w3.org/hg/dap/raw-file/default/light/Overview.html#security-and-privacy-considerations

Feedback was solicited by the end of the week.

* Privacy guidance documents

- Specification Privacy Assessment (SPA) [Editor: Frank Dawson]

This document seeks to provide a methodology for undertaking systematic privacy reviews of W3C specifications, and guidance for writing privacy considerations.
Frank is working with Nick to put this document up on Github, hopefully in the near future. Once it has been placed there, feedback will be solicited from the group.

- Privacy Considerations for Web Protocols [Editor: Hannes Tschofenig, Nick Doty]
This document seeks to provide guidance to Web specification authors on privacy threats and ways to mitigate them.
The updated version is at http://www.tschofenig.priv.at/w3c-privacy-guidelines.html
Hannes and Nick reviewed the set of privacy questions generated by the preliminary privacy reviews  (http://www.tschofenig.priv.at/privacy-questions-markup.doc) to see how they might apply to the privacy considerations document, which were discussed with other PING members. Hannes asks that we review this updated document to see how it could be further improved; feedback is welcome on the wiki (http://www.w3.org/wiki/Privacy/Privacy_Considerations) or the email list.

- Fingerprinting Guidance for Specification Authors [Editor: Nick Doty]
There are no new updates to the draft since the last call (at: http://w3c.github.io/fingerprinting-guidance/). However, Nick noted that the app:URI scheme (discussed above) may be a good example to use for illustrative purposes, for "cookie-like" approaches. PING participants are encouraged to add text in Github.

* Privacy review of EME [led by Wendy Seltzer]
Wendy would like to have some volunteers to help look at the privacy considerations of the Encrypted Media Extension specification. Work is still ongoing on EME so the privacy review is not urgent, but it would be helpful to identify some volunteers now.

* Privacy review of getUserMedia [led by Hannes Tschofenig]
Hannes has started with a preliminary read-through of the getUserMedia specification. Data minimization may prove difficult to apply in this case because it may affect the audio quality of a conference call. Volunteer help on this item would also be appreciated. Joe Hall very kindly volunteered to take a small role.

It was also noted that the Tracking Protection Working Group work is currently taking up time that PING participants might otherwise be able to devote to privacy reviews and development of privacy guidance/process documents.

Link to the minutes: http://www.w3.org/2013/05/23-privacy-minutes.html

Christine and Tara