W3C home > Mailing lists > Public > public-privacy@w3.org > January to March 2015

PING - informal chairs' summary - 26 February 2015

From: Christine Runnegar <runnegar@isoc.org>
Date: Tue, 3 Mar 2015 06:21:48 +0000
To: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-ID: <C73583B4-52F3-4FB2-8C5C-92E301D150F1@isoc.org>
PING - informal chairs’ summary – 26 February 2015

Many thanks to Joe Hall for acting as scribe.

Regrets from Frank Dawson and Jose M. del Alamo.

Welcome to new PING members!

There will be an informal face-to-face meeting at IETF 92 on 26 March 2015 (11:30 – 13:00) in Vista. Next call details to be advised.

Please note that feedback on privacy and security considerations for Manifest for Web Application is due 5 March 2015. Please volunteer on the wiki:


* Personas (Charles Nevile and David Singer)
David provided an overview of the “persona” idea introduced at the 2014 W3C Workshop on Privacy and User-centric Controls [1]. By way of introduction, David mentioned that, according to a paper he read recently, 25% of Internet users think “private browsing” stops servers from remembering their browsing session, however, this is not the case. While engaging private browsing mode initiates a separate session in the user agent and discards the history on the user’s device when the session is terminated, that data is not discarded by the browser servers, search engine servers, or other web servers that were part of the session. Currently, a server is not aware when a user is in private browsing mode. This means that even if a user uses private browsing mode, for example, to buy a surprise gift or research a medical condition, another user may subsequently see advertisements based on the user’s search history.
David made the point that privacy is not always about secrecy: it is about context. He gave the example of a customer being willing to have a discussion about a bank overdraft with a bank employee at the bank, but not with the same employee at a party.
He proposed an idea for using a HTTP header field to allow a user to communicate to a server “at the moment, I'm using a particular persona”. In other words, a mechanism to allow the user to ask servers to keep the data associated with different personas separated (i.e. to respect context). A second component would be some sort of signal from the server acknowledging the segregation. This would improve trust, and a lie could be addressed by regulators. He and Charles observed that, without a persona signalling mechanism, servers may not know that a user wishes to keep sessions (and histories) segregated and may aggregate separate sessions through user agent identifiers such as IP address, fingerprints, etc.
Nick Doty noted that TAG conversations regarding standardising private browsing mode included discussion of the difference between client-side clearing and server-side clearing.
Charles expressed the view that users are more concerned about how tracking data is used rather than the tracking itself. On the question of anonymity, Charles also observed that it is relatively easy for servers to de-segregate even “anonymous” users.
There was some discussion of existing profiles/persona features in the Firefox and Mozilla browsers, to what extent they might address identified use cases, and what level of granularity might be possible (e.g. from a technical and usability perspective) for such a persona idea (e.g. discover what backend servers know, ask them to segregate and forget).
Action items =>
David will post a summary of his idea on the public-privacy email. Please discuss the idea and consider what PING and/or other W3C working groups could and/or should do.
* Web RTC local IP address disclosure (Wendy Seltzer)
WebRTC WG has asked for privacy and security considerations around the disclosure of a user's local IP address in Web RTC: Real-Time Communication in Browsers [2]. Wendy created a space on the wiki [3] to collect some of the considerations. This is in part a response to news items that WebRTC exposes local IP addresses, not just public IP addresses. (Note: the local IP address may be different from the public IP address, if for example, a user is using a VPN, Tor or a NAT.) WebRTC uses P2P technology so local IP addresses are needed for communication. She suggested that PING could help by answering these questions:
- what risks are associated with the exposure of local IP addresses?
- in what circumstances should WebRTC have access to local IP addresses?
- what user controls should there be?
Mike O’Neill observed that an attacker can easily obtain the local IP address by running a little JavaScript and that it is a simple way to do fingerprinting. He volunteered to consider the privacy considerations of WebRTC local IP address exposure. Wendy noted that the local IP address is even available when the user is not engaged in WebRTC communications.
Nick asked whether local IP address exposure is an issue for any other APIs. He noted that the issue was discussed in the development of Network Service Discovery, but that he is not aware whether it was implemented.
Action items =>
Please review the WebRTC local IP address disclosure issue and fill in the wiki [3].
Timing – please complete before 26 March 2015
* Header enrichment (Nick Doty and Wendy Seltzer)
(postponed due to a full agenda)
* Fingerprinting guidance (Nick Doty)
Action items =>
Please review Nick’s updates to the draft Fingerprinting Guidance for Web Specification Authors [4] outlined in this email [5] and provide comments before 26 March 2015.
* Privacy reviews and guidance
Thanks to Nick and the Internationalization Working Group, we now have a wiki to track the progress of our privacy reviews [6]. Each review should have a shepherd (who is responsible for compiling the input and ensuring the final review text is submitted to the relevant working group) and one or more volunteers for each review.
* Manifest for Web Application
The Web Applications Working Group has requested feedback on privacy and security considerations of Manifest for Web Application [7] by 5 March 2015.
* W3C TAG Finding – Securing the Web
The TAG published a finding “Securing the Web” on 22 January 2015 [8]. It contains a “to-do” list [9]. It also identifies some concerns with HTTPS.
Nick advised that there has also been some discussion in the TAG certificates and HTTPS, about HTTPS as a three-party protocol.
The Web Application Security Working Group has a draft coming out today – Upgrade Insecure Requests [10] (that defines a mechanism which allows authors to instruct a user agent to upgrade a priori insecure resource requests to secure transport before fetching them). They also a have a draft – Requirements for Powerful Features [11] for features that require privileged content. The TAG will be helping the WebAppSec WG identify features that should be allowed to access this type of content.
Joe, who is “show-runner” for the confidentiality piece of the IAB Privacy and Security Program referred to the IAB Statement on Confidentiality [12]. He emphasized that HTTPS is not only about confidentiality, but also integrity. He is interested in any differences between the IAB and the TAG documents. Mark Nottingham has been invited to the PING face-to-face meeting in March, so this may be a good opportunity to discuss these aspects.

Minutes are available here: http://www.w3.org/2015/02/26-privacy-minutes.html 

Christine and Tara
[1] http://www.w3.org/2014/privacyws/
[2] http://www.w3.org/TR/webrtc/
[3] https://www.w3.org/wiki/Privacy/IPAddresses
[4] http://w3c.github.io/fingerprinting-guidance/
[5] https://lists.w3.org/Archives/Public/public-privacy/2015JanMar/0095.html
[6] https://www.w3.org/wiki/Privacy/Privacy_Reviews
[7] http://www.w3.org/TR/2015/WD-appmanifest-20150212/
[8] http://www.w3.org/2001/tag/doc/web-https
[9] http://www.w3.org/2001/tag/doc/web-https#building-a-secure-web-with-w3c-standards
[10] http://www.w3.org/TR/2015/WD-upgrade-insecure-requests-20150226/
[11] http://www.w3.org/TR/powerful-features/
[12] http://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/
Received on Tuesday, 3 March 2015 06:22:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 3 March 2015 06:22:22 UTC