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

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Tuesday, October 27, 2015 3:45
To: Nick Doty <npdoty@w3.org>
Cc: Mathieu Hofman <Mathieu.Hofman@citrix.com>; Martin Thomson <martin.thomson@gmail.com>; Harald Alvestrand <harald@alvestrand.no>; public-media-capture@w3.org; public-privacy (W3C mailing list) <public-privacy@w3.org>
Subject: Re: Comments/Questions on Media Capture Streams – Privacy and Security Considerations



On Tue, Oct 27, 2015 at 1:44 AM, Nick Doty <npdoty@w3.org<mailto:npdoty@w3.org>> wrote:
On Oct 27, 2015, at 10:53 AM, Mathieu Hofman <Mathieu.Hofman@citrix.com<mailto:Mathieu.Hofman@citrix.com>> wrote:
What we're saying is that every XSS or related security bug you have in the
future, in addition to having security implications for your site's business, will
also expose every previous user of your site to video and audio surveillance.
It's not, "using this API involves sensitive data, so audit to find security bugs
when you're using it", but rather "if you ever used this, you have to commit
to perfect security diligence in perpetuity."

At the least, I think Mathieu's suggestion about CSP might be useful in
updating that section of the spec. We could give more specific
recommendations about use of CSP and maybe user agents can take that
signal into account when determining whether to grant a permission based
on a prior granting.

Actually I'm coming back on my original idea. I don't think CSP can be of any help, now that I realize CSP can be added to a compromised page using html meta element.

That certain attackers can add CSP policies doesn't prevent their usefulness in this area. What we're concerned about is whether a previously-provided permission grant for getUserMedia can be safely relied on for later access to camera/microphone without a permission prompt. If a CSP policy is in place when getUserMedia was first used by a site and is still in place, then the browser can be provided some confidence that a permission still makes sense and is relatively less likely to be a XSS attack.

Wait, now you want the browser to *persist* the CSP policy and check
that the same policy is still in place? That's totally infeasible, if only
for the obvious reason that either (a) we check that the CSPs are
identical in which case we'll get all kinds of false positives or
(b) we have to do some kind of "substantively the same" check.

I think what was meant here is that CSP be present when saving the persisted permission and when using a saved persisted permission. The content of the CSP doesn’t have to be the same, just that it be enabled during both save and read of the persisted permission. That way, the site was hopefully protected when the user first granted the persisted permission and later still protected when the site uses a stored persisted permission.


If you called getUserMedia on your small site and don't have a CSP policy and someone later finds an XSS attack, the lack of a CSP might be an indicator for the user agent not to persist the permission request.

But again, since the attacker can *inject* CSP of his own, any check that
relies on the existence of CSP is trivial to circumvent.

Well if there was originally no CSP, the persisted permission would not have been stored, so there should be a user prompt. The CSP requirement wouldn’t protect a new user visit, just a repeated visit. The 2 vectors left are: site is vulnerable despite CSP presence (bad CSP); and website had CSP, user granted persistent permissions at that point, website removed CSP, gets compromised, and attack re-injects own CSP. In both cases, the developer arguably didn’t implement CSP correctly, but it’s not a failing of CSP itself.

Mathieu