PING - informal chairs summary - 22 August 2013

PING informal chairs' summary for 22 August 2013

Thank you to our guests from the Web Cryptography WG for joining us to discuss some of the privacy considerations associated with the draft Web Cryptography API [1] and the draft WebCrypto Key Discovery [2].
 
Special thanks to Ryan Sleevi, Mark Watson, Virginie Galindo, and to our scribes Nick Doty and Joe Hall.
 
(1) Web Cryptography
 
There are three documents under active development (Web Cryptography API, WebCrypto Key Discovery and non-normative Web Cryptography API Use Cases [3]).
 
Ryan Sleevi gave a brief introduction to the Web Cryptography API and its privacy considerations. The Web Cryptography API provides basic cryptography services (encrypt/decrypt, sing, hash). The draft API uses an abstract key object (opaque key handles): an attacker may or may not be able to extract the raw key. The key material is good if it is random and not shared with anyone in the world, but it is also a very long persistent identifier with strong mathematical binding. To mitigate the privacy risk, the WG has specified that key storage is handled by existing Web storage (e.g. IndexDB). PostMessage is used for inter-origin messaging. The draft API design leverages the privacy characteristics of those APIs. If users clear this storage, it will remove the keys (parallel to clearing “the cookie-jar”). So, the lifetime of keys is tied to the lifetime of existing storage mechanisms.
 
Nick Doty complimented the Web Cryptography WG on its documentation of the privacy considerations in the draft API. He queried whether “super-cookies” is the right term to describe the risk posed by persistent storage of keys associated with users (i.e. keys used as persistent identifiers). The basic idea behind the API design is that a user agent has a key identifier that a site can obtain via a particular name, but there is a desire from some WG members to support keys that are generated outside the API (e.g. those used for smartcards, device identifiers). Such keys may be irrevocable so the WG considers that there is a risk of “super cookies” being applied.
 
Nick also asked whether the WG expects more diversity in the implementation of algorithms than the enumerated list. There is no plan to extend the API list programmatically, but it is expected that the list will retrospectively updated. Realistically, the WG expects to see greater diversity in implementation, but they do not expect users to be able to enable and disable algorithms in the way that they handle fonts.
 
Nick observed that all the privacy considerations are non-normative and queried whether origin-specificity should be normative. Ryan explained that the API does not define a storage mechanism so the origin restrictions will have to come from IndexDB. PostMessage allows inter-origin communication between iframes, but no additional information is communicated in this scenario.
 
Mark Watson introduced the WebCrypto Key Discovery API, which is intended to be used for services such as Netflix that use devices like televisions and set-top boxes, where keys are pre-provisioned during the manufacture process for video access. Keys are origin-specific. They look like ordinary Web Crypto key id attributes. The keys can be accessed by name through an API to identify the device using the service. Users should be aware of this.
 
Nick raised a concern that these pre-provisioned keys (persistent identifiers) could be implemented in hardware, rather than as a cookie that could be cleared. Ryan replied that they (Google) share these concerns and do not plan to implement it in traditional desktops. This API is more intended for embedded devices, and even so Google has reservations about this even when it is connected to cookie storage – will users understand the risk? Mark explained that in anonymous mode the keys would not be visible to the application. If the application called for the name, it would return a null value. However, Nick observed that the key could still be transmitted across origins via postMessage. Ryan also noted that incognito mode in Firefox (and other browsers) is not seen as anonymous browsing mode. They prevent persist storage, but they do not prevent users from being tracked. He expressed the view that browser anonymity mode is mitigation against this risk. However, he also noted that the same risk already currently exists with other APIs (e.g. Geolocation API), i.e. those APIs can postMessage to other origins. Once the key object is shared with other origins it could be stored in existing storage mechanisms. Mark raised the issue of origin collusion on the service side using information from the client side, but this is not new or unique to keys.
 
Virginie Galindo (Web Crypto WG chair) requested a PING privacy review of both draft specifications, ideally within a month. PING members were invited to volunteer to lead and/or work on the privacy review.
 
(2) Update regarding the fingerprinting guidance
 
Nick provided an update of the recent work undertaken on the Fingerprinting Guidance for Specification Authors [4] and the discussion on the mailing list. There is a new section under mitigation and guidance about clearing local state. It is an open question whether to clear all local state at the same time. We discussed differences between passive, active and cookie-like (e.g. which pose the greater risk to users, which are easier/harder to mitigate, etc.). Joe Hall expressed the view that while passive fingerprinting is hard to detect, active attacks can be amazingly effective (much more so than passive). Nick explained that one area where the W3C could have an impact is to ensure specifications do not make the entropy of passive fingerprinting any higher than is necessary.
 
(3) Updates regarding SPA and the Privacy Considerations drafts
 
No updates were provided. This will be moved to the agenda for the next call.
 
(4) Outstanding privacy reviews
 
There are two outstanding privacy reviews: getUserMedia and Encrypted Media Extension (EME). Nick asked Mark whether there are any particular places that they are looking for PING input. Mark said that there is probably not much in the EME specification itself, but guidance/constraints as to what CDMs can do/not do with respect to privacy would be helpful.
 
(5) Discovery of privacy statements (under AOB – from the mailing list)
 
Nick asked whether there is anything that the W3C should do to encourage adoption of RFC 6903. Karen O’Donoghue mentioned EFF and ToS;DR work on TOSBack [5] and the WSJ Data Transparency Weekend (2012) [6]. During the WSJ event, the number of websites being monitored by the tosback2 crawler increased from about 50 to about 500. She also mentioned current work being undertaken by ISOC, EFF and ToS;DR on TOSBack to develop an archive with an open defined interface that will enable researchers and others to develop additional applications to monitor and analyze changes in websites’ ToS statements. Nick requested that Karen put PING in touch with the Tosback2 team.
 
[1] https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
[2] http://www.w3.org/TR/webcrypto-key-discovery/
[3] https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html
[4] http://w3c.github.io/fingerprinting-guidance/
[5] http://tosback.org
[6] http://datatransparency.wsj.com/

Christine and Tara

Received on Friday, 30 August 2013 09:36:32 UTC