PING - informal chairs' summary - 24 April 2014

PING - informal chairs’ summary - 24 April 2014

Note: Next meeting - 29 May 2014 at the usual time

A special thank you to Philippe Le Hegaret, Arvind Jain, Tobin Titus and Alois Reitbauer and from the Web Performance WG for joining PING to discuss privacy considerations associated with the draft Navigation Error Logging specification [1].
 
Thanks also to Nick Doty for very kindly, once again, acting as scribe.
 
* Navigation Error Logging
 
Navigation Error Logging defines an interface to store and retrieve error data related to the previous navigations of a document (i.e. a way for Web developers to track navigation and observe the errors that users experience). The draft API defines a way to query the error information that is stored in the browser. Reporting can be done in real time. The information that is exposed by the API is “high-level”, limited to network connectivity, DNS resolution or HTTP errors. As an example, only the specific URL for the document where the error occurred is returned, not the URL from which the user navigated to that URL. Sub-resources, such as a CORS error loading a Javascript file would not be returned. Access is restricted to same origin.
 
The Web Performance WG has included a draft privacy and security section in the specification.
 
The Web Performance WG is currently considering what additional error information should be able to be queried by the API, such as information as to the type of DNS error. The WG had a detailed discussion at TPAC 2013 and decided on a limited data approach. The WG would appreciate some guidance on the privacy and security implications of providing more detailed reports. Note: such guidance should involve close consideration of each error type.
 
There was a query about the strictness of the “same origin” policy and how the API will function in the mash-environment, namely where the content is sourced from multiple domains and/or a company uses several domains (e.g. .com, .cm). The concern was about possible information leakage. Response: The API will only return information for the host name. However, it was noted that there is the potential (as is the case with other query APIs) for an attacker to get access to the stored repository by spoofing the origin.
 
There was also a query about whether the API supports user configuration. The Web Performance WG decided not to include this functionality because, in evaluating the categories of information that were able to be accessed via the API, they did not identify any privacy-sensitive information that they thought would require user consent. This led to a discussion about user preference. In particular, we discussed the situation where a user might not wish to expose their network configuration (e.g. the fact that they are using Tor). Rigo Wenning observed that if the API is not capable supporting user permissions, there may be legal difficulties in some jurisdictions (e.g. Europe). He also expressed the view that the API should include best practices in this regard. Even if a user is technically able to block the API from retrieving the data from his or her device, there are the additional issues (a) whether the user is aware that the Web developer is seeking to retrieve the data and (b) whether he or she gives permission. These are issues that will require further consideration.
 
There was also a discussion about whether the Web Performance WG has considered the interactions between this specification and the Content Security Policy (CSP), and a suggestion that the Web Performance WG include the Web Applications Security WG in the discussion.
 
Nick queried whether there is a use case for a configurable URL -  a single well-known reporting URL (e.g. to mitigate against possible JavaScript attack). He also mentioned RFC 5785 Defining Well-Known Uniform Resource Identifiers (URIs) [2], which defines a path prefix for “well-known locations”, “/.well-known/”, in selected Uniform Resource Identifier (URI) schemes. Arvind reported that the report URI can be restricted to the specific report pattern.
 
Philippe will take the issues raised in this call back to the Web Performance WG for their consideration. Wendy Seltzer and others from PING will also give further consideration to those issues and possible solutions.
 
* Web NFC API [3] (see Nick Doty's email at [4])
 
Nick Doty sent an email [3] regarding the Web Near Field Communication API suggesting it would be useful to examine the privacy considerations. Christine asked whether anyone would be willing to review the draft. Hannes Tschofenig expressed more interest in Bluetooth LE because it seems to have had more uptake than NFC tags. In this regard, Nick suggested Hannes reach out to the System Applications WG to see if they are undertaking any work in this area.
 
* Re-chartered Geolocation WG and privacy considerations
 
The Geolocation WG has been rechartered. The Chair would like to discuss with PING how to incorporate privacy considerations into their work at an early stage. PING chairs will invite the Geolocation WG to join the next PING call.
 
* TPAC and privacy session
 
There was support on the call for a PING meeting and/or privacy session at the W3C Technical Plenary and Advisory Committee (TPAC) meeting in Santa Clara, California (27-31 October 2014). Please share your ideas for such a session or sessions on the email list.
 
* Privacy guidance and process documents
 
Joe Hall, Nick Doty and Christine Runnegar are aiming to provide comments on Hannes’ privacy considerations document before the next call.
 
[1] http://www.w3.org/TR/2014/WD-navigation-error-logging-20140211/
[2] https://tools.ietf.org/html/rfc5785
[3] http://lists.w3.org/Archives/Public/public-privacy/2014JanMar/0002.html
[4] http://www.w3.org/TR/2014/WD-nfc-20140114/

Christine and Tara

Received on Friday, 2 May 2014 07:25:20 UTC