- From: Christine Runnegar <runnegar@isoc.org>
- Date: Mon, 1 Jun 2015 05:11:36 +0000
- To: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
PING – informal chairs summary – 14 May 2015 Thank you to Brad Hill and Ian Jacobs for joining our call. Thanks again to Joe Hall and Nick Doty for acting as scribes! Next call will be on 25 June at the usual time. * Privacy review request from Web Applications Security WG concerning Subresource Integrity [1] Brad Hill provided an overview of the draft Subresource Integrity specification (SRI), which is the result of considerable thinking and, in some ways, an experimental step towards greater integrity and security on the Web. SRI defines a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation (specifically, hashed metadata annotations delivered as a new "integrity" attribute of the <script> and <link> tags). User agents check resources against the hash before including the resource in the DOM. The WebAppSec WG is particularly interested in being able to apply this approach to dynamic resources such as JavaScript and Cascading Style Sheets (CSS). The WG expects this will be most useful for libraries where the tag would be stable over a version of the library. One of the identified threats where SRI may be a useful mitigation is the situation where a CDN has been compromised, allowing compromise of other applications mediated by the CDN. It does not provide protection against network attacks. This is an experiment: it remains to be seen just how useful and how burdensome it is. It does introduce some brittleness because a resource can evolve over time. If the resource goes out of sync with the tag, it could break things. The intention is that SRI could be used with documents delivered over HTTP and HTTPS, but resources that are integrity-checked must be same origin or using CORS. It does not change the state of mixed content or privileged features. One of the concerns the WG has is to avoid cross-origin leakage, and other paths to leakage (e.g. timing channels). SRI does not try to eliminate all side channels for detecting that a user is logged in, but rather not to introduce any new side channels. As to the hashing algorithm, SRI uses SHA-256 because it is compact, but the specification also mandates that SHA-256, SHA-384 and SHA-512 be supported. The user agent will select the set of algorithms that are the strongest and check the hashes against those. The WebAppSec WG has specifically asked for feedback on: - Fetch Integration - Privacy and Security Considerations - CORS interactions - Future Considerations regarding broader integration into other HTML elements Extensibility The WebAppSec WG requests feedback via public-webappsec@w3.org with [SRI] in subject line, ideally before 26 May 2015. * Privacy review request from W3C Web Payments Interest Group concerning web payments use cases [2] Ian Jacobs gave an overview of the web payments use cases and walked us through some examples. The Web Payments IG is seeking early review before one or more WGs are chartered in August. In particular, the IG would like to know whether the privacy considerations are sufficient for the scenarios. The overall goal is to make web payments more secure and to ensure that only the information needed to conduct a transaction is shared. Once the use cases are complete, the next stage is to describe the specific functionality that will be needed for the use cases. This is another point where it will be useful to have input on the privacy considerations. Joe Hall and Greg Norcie provided some comments in advance of the call direct to the IG via the public email list (public-webpayments-comments@w3.org). One of the issues identified by them was the need to distinguish between loyalty cards, branded credit cards, rewards-based cards, etc. because the privacy implications vary. Another observation was that the approach seems to be based on the user transmitting their payment options to the merchant, rather than having the user select one from the range offered by the merchant. They also proposed the IG consider zero-knowledge credential verification, rather than passing credentials to the merchant server. Ian Jacobs noted that he had heard use cases for verification on both the server and client side. A hot topic in the IG is which security model(s) should be preferred. Action: Please review the draft [2] and share your thoughts on the privacy considerations on the PING email list (public-privacy@w3.org). * Comments requested on privacy and security considerations of Media Capture and Streams [3] This is an important specification because it will be used by WebRTC. Katie Haritos-Shea very kindly previously provided comments on the privacy considerations for Media Capture and Streams [4]. The last call comment period ends tomorrow (15 May 2015). This is insufficient time for PING members to review and provide feedback, and even if it is after last call, it would be better to highlight any critical missing elements before the document goes to a W3C Recommendation. Some new features present in many browsers are already relying on Media Capture and Streams, but it is still in the early phases of feature implementation, so having input at this stage is still valuable. Action: Please review the draft [3] and share your thoughts on the privacy considerations on the PING email list (public-privacy@w3.org). We will discuss this item on the next call. * Privacy review request from CSV on the Web Working Group concerning: Due to time constraints, moved to the agenda for the next PING call. * Self-review Security and Privacy Questionnaire [5] Nick Doty, Mike West and Tantek Çelik were invited to meet with the TAG in San Francisco in April, where this was discussed. The TAG is interested in moving this document forward with PING. The chairs will reach out to the TAG to discuss how best to progress this work together. * Should sensors require a privileged context? (Discussion raised in Device API WG) Due to time constraints, moved to the agenda for the next PING call. * PING @ TPAC We are planning to hold a meeting at TPAC. Please share your suggestions as to how we might usefully use the time. Christine and Tara [1] http://w3c.github.io/webappsec/specs/subresourceintegrity/ [2] http://www.w3.org/TR/web-payments-use-cases/ [3] http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/#privacy-and-security-considerations [4] https://lists.w3.org/Archives/Public/public-privacy/2014OctDec/0004.html [5] https://w3ctag.github.io/security-questionnaire/
Received on Monday, 1 June 2015 05:12:09 UTC