RE: Request for feedback: Media Capture and Streams Last Call

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the last Privacy IG call I pointed out a privacy issue in Media Capture (http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/#access-control-model) .

This is where a MediaDeviceInfo object with the deviceId property is returned without any authorisation. The value returned is effectively a UID cookie singling-out the device (and obviously therefore the individual using it). This creates the possibility to easily fingerprint any user agent that supports the API.

To say the privacy risk of this is alleviated because of the same origin policy is disingenuous, as this is equivalent to placing a user unique random number i.e. a UID cookie with an infinite persistence, and of course it will be used for tracking.

It is irrelevant that the value is scoped to a single origin because any embedded third-party in their own origin iframe will be able to identify the user and even pass the identifier server-side or via the many cross-site scripting methods to the top level browsing context or to other third-parties.

Even though the identifier is reset when cookies are cleared, it should not be a requirement on users that, in order the protect their fundamental right to privacy, they have to in perpetuity periodically scrub all their cookies, some of which they may have consented to, indicate a tracking “opt-out” or that do not have a privacy impact.

The following code shows the problem if you execute it in a page on Firefox (you have to use version 39 or higher, I used Nightly 41.0a1 and the Developer Toolbar)

navigator.mediaDevices.enumerateDevices()
.then(function(devices) {
devices.forEach(function(device) {
console.log(device.kind + ": " + device.label +
" id = " + device.deviceId);
});
})
.catch(function(err) {
console.log(err.name + ": " + err.message);
});

On google.com I get:

audioinput:  id = tXIH1cq1vzHRkdcju5qTQIOCJzX5GP1jYwPwryhuwQs=

and on Yahoo.com I get:

audioinput:  id = tprWdvs/eh/pzhzYAcmutm+tzpHwLjebknxbqxN37dI=

If I close all the tabs, clear web history and cache, and reload the browser, on Yahoo.com I still get:

audioinput:  id = tprWdvs/eh/pzhzYAcmutm+tzpHwLjebknxbqxN37dI=

But if I clear all my cookies and again visit Yahoo.com, this time I get:

audioinput:  id = ksCnhotp5uP6utLbv7s2hqffIs0P+pW0Jakmmcnkeo0=

Conclusion.

The deviceId property should not be returned unless the user has authorised this to occur. This is in fact legally required in Europe (e.g. by the e-privacy and data protection directives).

In addition, as I also pointed out in the call, any persistent permission or user identifying storage should have a “sunset” duration associated with it, as RFC6265 allows for but other APIs (e.g. localStorage) do not. This has been asked for several times by the Article 29 Working Party amongst others.

My general point about the “fetishisation” of the same origin policy, was about the tendency to see it as a privacy or security panacea when, as exhibited clearly in this case, it is not. The SOP is a fundamental basis for higher level security and privacy enabling protocols but many times is insufficient in itself.

Mike


Mike O'Neill
Technical Director
Baycloud Systems
Oxford Centre for Innovation
New Road
Oxford
OX1 1BY
Tel. 01865 735619
Fax: 01865 261401
 /
 Email: michael.oneill@baycloud.com
/Professional Profile
 
 
 
 
 
 







From: Greg Norcie [mailto:gnorcie@cdt.org]
Sent: 25 June 2015 17:13
To: public-privacy (W3C mailing list)
Subject: Fwd: Request for feedback: Media Capture and Streams Last Call


- ---------- Forwarded message ----------
From: Greg Norcie <gnorcie@cdt.org>
Date: Thu, Jun 4, 2015 at 3:53 PM
Subject: Re: Request for feedback: Media Capture and Streams Last Call
To: "public-privacy (W3C mailing list)" <public-privacy@w3.org>

Hi all,
Sorry for the late reply.
Overall, this spec looks really good, we at CDT just had a few small suggestions:
It would be nice if there was a simple, user friendly way to revoke consent for a stream (especially audio/webcam streams). As it currently stands, once consent is granted there doesn't seem to be simple way to revoke it.
In section 10.6, it is stated that persistent permissions must be be served over HTTPS and have no mixed content. It would be nice to see the "definition" of mixed content expanded to include the various issues mentioned in Bonneau's recent paper[1]. For example, if a site elects to use pinning, it should be considered to have mixed content if it loads non-pinned content.
Also, as an aside, we used the TAG questionnaire, and while it was very useful, we think it could use some tweaking. And in the spirit of open source, we'll be proposing some tweaks (probably sometime late next week)
[1] http://www.jbonneau.com/doc/KB15-NDSS-hsts_pinning_survey.pdf



- --
/***********************************/
Greg Norcie (norcie@cdt.org)
Staff Technologist
Center for Democracy & Technology
1634 Eye St NW Suite 1100
Washington DC 20006
(p) 202-637-9800
PGP: http://norcie.com/pgp.txt

Fingerprint:
73DF-6710-520F-83FE-03B5
8407-2D0E-ABC3-E1AE-21F1

/***********************************/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using gpg4o v3.4.103.5490 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJVj9nEAAoJEHMxUy4uXm2JP30H/2f7oNIA4itTDqnZp30mqbQa
kStVMCSmoXWv5gndptoI3zlZNTuUbD12Jqe9x+zOnJ7EZM6pKylrNNMYpZmyMb/L
Xy8RiT+9t7b4KQjoVdSWeyPETCJxjG+sDGq5YovlML7n0ItL8HnMIkbhDaabeL79
J/wGkzwy5vqnXQYfDas6jMCAflBt1Erik32xI2nmRFv88R9j7YBaocegQpJX8RiL
zbMwGrHk63HSChkoehwWIzgEdnrP3jBJNT0JM862BjnswwzmuIeESEulEEZx7V7H
Ytokqs/pydzr3UNuZ07pAUU2UxBemOhj91lK1Ei4ZNYCQpGOPuB7nBsBhBUTUvg=
=3bYA
-----END PGP SIGNATURE-----