Thanks Nick for your review. At first sight it looks like there are two items we should investigate a bit more: - Permissions API and site revocation (I think we're getting this one right, but it is still some work remaining) - Events from multiple frames/tabs Cheers, Stefan On 21/03/16 01:09, Nick Doty wrote: > Thanks Stefan for continuing to remind us on this and to the WebRTC > folks for compiling such a clear description of the issues and the > resolutions. I've provided my thoughts below; I don't speak for the > Privacy Interest Group as a whole, but hopefully these comments will > be useful. PING folks interested in Media Capture, I'd appreciate if > you'd read these over and note any points where I'm off base or not > accurately representing concerns you might have raised. > > At a high-level, I believe the changes made have clarified the > privacy and security trade-offs for readers of the spec and addressed > the concerns about the permissions model. This is excellent work. > > Continuing concerns I have are noted below (revocation of permissions > using the Permissions API; simultaneous event-firing for background > tabs). It might be that these have already been considered and > addressed by the Media Capture Task Force, but I thought they were > worth noting. > > Hope this helps, Nick > > This list basically follows the order on the wide review page: > https://www.w3.org/2016/03/getusermedia-wide-review.html#ping > Although the Events issue at bottom didn't make it on to that list. > > ## PING: Document tradeoff for non-HTTPS usage of getUserMedia #249 > > This is clearer in the privacy and security considerations section, > thanks. I expect some people won't be happy that one-off use is > allowed for non-HTTPS access, but our raising the comment wasn't a > suggestion that the group reverse its decision on that topic. > > I believe this response addresses the concern. > > ## PING: Refer to security-arch on the MUST inside Best Practice for > HTTPS #250 > > Our comment was noting the use of normative language in a > non-normative best practice. The document now makes it clear that > there is a normative requirement in a normatively referenced security > architecture document. > > I believe this response addresses the concern. > > ## PING: Mark fingerprintability of device enumeration #251 > > Done, thanks; I think this will make it clearer for implementers who > are concerned about fingerprinting risks. > > I believe this response addresses the concern. > > ## PING: Recommend clearing persistent device IDs when clearing > cookies > >> We added text to clarify that persistent identifiers (including >> device ids) are to be cleared with cookies, and that the >> identifiers don't persist unless device access has been granted. > > Awesome. I also think the language has been improved on specifying > the scope of uniqueness of identifiers as well as their persistence. > I'm not sure if everyone on the public-privacy list has been > satisfied with the idea of introducing another identifier with the > same scope as a cookie, but I don't believe it's introducing a new > privacy issue. > > As already noted, I believe this response addresses the concern. > > ## Scoping of permissions > >> We revised our permission model to be double-keyed by the top-level >> origin and the entry-script origin; furthermore, iframes will have >> to be expliticitly be allowed to use getUserMedia, via a new >> allowusermedia attribute > > I think this is great. As discussed at TPAC, double-keying is a > promising way to address the privacy and security concern and I'm > glad to see it written up. An attribute on iframes also gives the > site owner additional control. Great. > > I believe this response addresses the concern. > > ## CSP as a signal for persisting permissions > > I suggested this as one option during the discussion of how a site > could indicate whether or not they wanted permissions to persist. I > think it was worth considering, but the conclusion I heard from the > WebRTC mailing list and from WebAppSec was that it wasn't the way > forward, because it was 1) complex to implement, 2) not appropriately > scoped to the origin or types of attacks. > > For what it's worth, Brad Hill had an alternative suggestion, > regarding sandboxing and origins: > https://lists.w3.org/Archives/Public/public-privacy/2015OctDec/0119.html > > I believe this response addresses the concern. > > ## Revocation > > I believe there were open questions on both user-side revocation and > site-side revocation of persisted permissions. > > On user-side revocation, Rigo had noted that RFC 7478 mandated user > agents provide the capability for users to revoke permissions, and we > weren't sure that had been translated into > draft-ietf-rtcweb-security-arch. I think I may have dropped the ball > on not creating a pull request on that point; if it's still useful > for me to do so, let me know. The Media Capture spec assumes that > user-side revocation is required, though I don't think it introduces > any specific normative requirement. > https://lists.w3.org/Archives/Public/public-media-capture/2015Oct/0061.html > > I raised the concern that sites should also have a way to revoke > persisted permissions that they may have received, as one way of > limiting the risk to their users where they requested camera access > in a way that might have just been one-time and subsequently had a > security breach of some kind (like a reflected XSS attack). The wide > review document suggests this is resolved via the Permissions API: > >> We reworked our permission system to be based on the Permission >> API, where revokation is addressed > > However, I couldn't find any references to the Permissions API in the > Media Capture and Streams document. Is there any requirement or > expectation that user agents that implement the Media Capture spec > will also implement the corresponding Permissions API functionality? > Or an example for how sites can use the Permissions API to query or > revoke permissions using that API? > > The current editor's draft of the Permissions API does include a > PermissionsDescriptor for camera and microphone, and a method for > revoking permissions. The Permissions API is at least under > development for both Chrome and Firefox: > https://platform-status.mozilla.org/#permissions Although I don't > think the current Firefox patch includes camera and microphone among > the supported permission names: > https://bugzilla.mozilla.org/show_bug.cgi?id=1105827 > > To the extent that it's unclear whether sites will be able to revoke > their Media Capture permissions using the Permissions API, I remain > concerned about this point. That said, maybe the fact that the > Permissions API editor's draft has included it is a promising sign > and the Privacy Interest Group could provide feedback on the > Permissions API regarding this point. > > ## Event firing > > I raised this issue in my initial set of comments, and while there > was some discussion with Harald, I'm not sure it ever got documented > as an issue or had any resolution. I provided a little more detail in > my response here: > https://lists.w3.org/Archives/Public/public-privacy/2015OctDec/0028.html > > My concern is that firing a devicechange event simultaneously in > different browsing contexts (including tabs or iframes not in the > foreground, or in different browsers altogether, that have not asked > for any permissions) creates a risk of unexpected correlation of > browsing activity. >Received on Monday, 21 March 2016 07:38:14 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:49:32 UTC