Re: Comments/Questions on Media Capture Streams – Privacy and Security Considerations

On Sep 21, 2015, at 1:03 PM, Mathieu Hofman <Mathieu.Hofman@citrix.com> wrote:
> 
> Quick thoughts on XSS attack and persistent permissions.
>   <>
> From: Harald Alvestrand [mailto:harald@alvestrand.no <mailto:harald@alvestrand.no>]
> Sent: Monday, September 21, 2015 4:23
> To: Nick Doty <npdoty@w3.org <mailto:npdoty@w3.org>>; public-media-capture@w3.org <mailto:public-media-capture@w3.org>
> Cc: public-privacy (W3C mailing list) <public-privacy@w3.org <mailto:public-privacy@w3.org>>
> Subject: Re: Comments/Questions on Media Capture Streams – Privacy and Security Considerations
> 
> 
> On 07/14/2015 04:28 AM, Nick Doty wrote:
> 
> The "note" section includes a description of a very serious attack. Is there anything that can be done about this beyond a note to website implementers, who may never read this section of the specification? Is it the case that any site that requests getUserMedia permission that subsequently suffers any sort of XSS vulnerability or URL parameter failure as you note will silently give live access to the user's video/audio to an attacker? As a site developer, am I liable if I use getUserMedia in one part of my site, users persist the permission and then somewhere else on my site I have a bug that allows for XSS or a URL parameter failure?
> 
> I'm not sure what the word "liable" means in this context - it's a word I usually try to avoid using unless I'm sure what I mean by it.
> 
> Any site that requests getUserMedia permission and has that permission persisted will have access to that permission - that's a given. If the site can be tricked into running other sites' Javascript - that site has a problem. I think that's an issue in all contexts, since running other sites' Javascript immediately renders all the considerations for "secure origin" null and void.
> 
> I don't know that this is something that Media Capture needs to call out specifically.
> 
> 
> 
> One way to help developers avoid this catastrophic scenario would be to allow sites to indicate whether they were confident about opting in to persisted permissions. A casual developer who calls getUserMedia() wouldn't have to worry about that failure due to some bug on their site. A serious developer who is confident about their security situation and whose functionality would benefit greatly from persistence could call getUserMedia(allowPersist=true).
> 
> Hm. I'd like to hear others' opinions on this.
> 
> Aren’t other permissions such as location not vulnerable to the same attacks? Does any of them have a similar “opt-in persist” mechanism?
> 
Yes, there can be similar attacks on other APIs, and I think to some extent there would be good reason to consider this kind of change for multiple specifications. As you and I both note, camera/microphone access falls a little farther on the "catastrophic" side of the spectrum, which is why I'm highlighting this here.

We have discussed in other groups, for example at Geolocation last TPAC, other "opt-in" style permissions. As part of the basic principle of data minimization, we consider it good API design for site developers to be able to specify the minimum data that they need, not just to make the request more palatable to the end user, but also to limit their own risk. I think persisted permission is a special case of this in the security space, and something we've become more aware of with evidence of pervasive monitoring.
> I understand audio/video device access is a little more sensitive than location, so here is a possibility I might be able to live with: to make sure the developer understands the risk of XSS attacks on device access, make CSP (Content Security Policy) a requirement for persistent permissions to be saved/used. I don’t think we should be specific about the content of the CSP, just that it be there as acknowledgement to the risk, both when saving the persistent permission, and when allowing access without prompt when the origin has persistent permission already granted. The latter part is to protect against a secured media application on one location, but less secured pages at other location on the same origin.
> 
> I’m curious to hear others’ thoughts on this?
> 
Was there more discussion of this proposal that I missed (off of public-privacy, say)?

I'm not sure we want the presence of any CSP to trigger this persistent permissions capability; I wouldn't want adding a CSP policy to your site to potentially be a thing to increase security risk. But if you're proposing a CSP clause for this, that makes sense to me, especially if it can also be used to specifically limit where on the site a persisted permission can be used.

Thanks,
Nick