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

On Mon, Sep 21, 2015 at 1:03 PM, Mathieu Hofman <>

> Quick thoughts on XSS attack and persistent permissions.
> *From:* Harald Alvestrand []
> *Sent:* Monday, September 21, 2015 4:23
> *To:* Nick Doty <>;
> *Cc:* public-privacy (W3C mailing list) <>
> *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?
> 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?
I would not be in favor of this. Measurements by some of my Mozilla
suggest that it's quite common for people to have ineffective CSPs, and this
just seems like a recipe for yet people to have useless CSPs in order to get
access to the camera/microphone.

WRT to the specific suggestion of requiring a CSP at time of *use* of
persistent permissions, if we assume that the attacker can do JS injection
(which seems like a requirement to exploit an issue of this type), then
I believe they will be able to do document.write() to insert a CSP, so this
doesn't seem like an effective security measure


Received on Saturday, 24 October 2015 03:40:14 UTC