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

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