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

Re: Verifying the disposition of responses to PING originated comments on “Media Capture and Streams”

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 21 Mar 2016 07:36:09 +0000
To: Nick Doty <npdoty@ischool.berkeley.edu>
CC: Christine Runnegar <runnegar@isoc.org>, "tjwhalen@gmail.com" <tjwhalen@gmail.com>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>, "webrtc-chairs@w3.org" <webrtc-chairs@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B374EF448@ESESSMB209.ericsson.se>
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


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