1178366 - Double-key deviceId for device enumeration

Status: RESOLVED DUPLICATE of bug 1181428

(Core :: WebRTC, defect, P2)

Description

[Martin Thomson [:mt:]]

There is no real usability loss by doing so, but this prevents sites from tracking users by including iframes in different origins.

I wouldn't change the clearing or keying behaviour; a site can have a single hmac key that it uses for generating all the identifiers.  Just mix in the origin from the location/awesome bar into the hmac input.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

There is usability loss obviously in that said frames will no longer remember you from last time, when the last time you saw the frame was in a different context.

This differs from the guarantee given to the same sites when they're not framed. The guarantee being the ability to implement a pleasing user experience as long as the user does not actively work against it.

I'm neutral to its value. This loss may be marginal (and indeed a feature), I'm not the right person to judge, but I worry we're reacting without considering consistency. We're not double-keying cookies in frames for instance. I would also check with the spec to make sure we're keeping with its intent.

I'd rather make sure we're consistent and moving toward some coherent model here. It's odd to me if WebRTC deviceIds are unique and without precedent in its needs here.

Comment 2

[Eric Rescorla (:ekr)]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #1)
> There is usability loss obviously in that said frames will no longer
> remember you from last time, when the last time you saw the frame was in a
> different context.
> 
> This differs from the guarantee given to the same sites when they're not
> framed. The guarantee being the ability to implement a pleasing user
> experience as long as the user does not actively work against it.
> 
> I'm neutral to its value. This loss may be marginal (and indeed a feature),
> I'm not the right person to judge, but I worry we're reacting without
> considering consistency. We're not double-keying cookies in frames for
> instance. I would also check with the spec to make sure we're keeping with
> its intent.

It's been discussed, but there are enough existing systems that rely on it
that it causes excessive breakage.

Comment 3

[Daniel Veditz [:dveditz]]

The Tor Browser double-keys cookies iirc so it can't be "excessive" breakage, but our audience does differ from theirs and is less tolerant of breakage on social sites.

Are these IDs persistent between private and non-private browsing? That would be bad.

The spec seems to say that the IDs are generated unique every session rather than persistent (§9.2.2 step 2.3.3) but this bug seems to imply otherwise. Of course the spec also seems to imply giving the same list to every site so clearly there's some additional design somewhere. Can someone point me at that?

Do we have any telemetry of how many of each kind of device people have? Since sites can now get that info from _everyone_ without requesting or receiving any getUserMedia permission we should get some data to reassure ourselves it's not too fingerprinty.

What is the value of enumerating opaque device IDs if you don't have getUserMedia permission? Especially if they change every session as implied by the spec.

Comment 4

[Eric Rescorla (:ekr)]

(In reply to Daniel Veditz [:dveditz] from comment #3)
> The Tor Browser double-keys cookies iirc so it can't be "excessive"
> breakage, but our audience does differ from theirs and is less tolerant of
> breakage on social sites.

I believe it's generally considered excessive from the perspective of the
average user.


> Are these IDs persistent between private and non-private browsing? That
> would be bad.
> 
> The spec seems to say that the IDs are generated unique every session rather
> than persistent (§9.2.2 step 2.3.3) but this bug seems to imply otherwise.
> Of course the spec also seems to imply giving the same list to every site so
> clearly there's some additional design somewhere. Can someone point me at
> that?
> 
> Do we have any telemetry of how many of each kind of device people have?
> Since sites can now get that info from _everyone_ without requesting or
> receiving any getUserMedia permission we should get some data to reassure
> ourselves it's not too fingerprinty.
> 
> What is the value of enumerating opaque device IDs if you don't have
> getUserMedia permission? Especially if they change every session as implied
> by the spec.

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Daniel Veditz [:dveditz] from comment #3)
> Are these IDs persistent between private and non-private browsing?

No, deviceIds in private browsing are separate from non-private ones, and also differ by never being persisted to disk.

> The spec seems to say that the IDs are generated unique every session rather
> than persistent (§9.2.2 step 2.3.3) but this bug seems to imply otherwise.

2.3.3. is not about deviceId, but groupId which is unique per session. It's a simple grouping construct in each list.

> Of course the spec also seems to imply giving the same list to every site so
> clearly there's some additional design somewhere. Can someone point me at
> that?

The text for deviceId is [1]:

"All enumerable devices have an identifier that MUST be unique to the application and persistent across browsing sessions"

So they are persisted. Admittedly "application" doesn't seem well defined.

Our implementation hashes the system's raw internal device ids with HMAC-SHA256 with the site's origin as a key, to produce the deviceIds that content JS sees.

> Do we have any telemetry of how many of each kind of device people have?

Not that I know of, but I would naively guess:

  - Camera: 1 on desktop and 2 on phones.
  - Microphone: 1 (+1 on OSes w/built-in virtual "default' one).

Not that you asked me to guess, but that seems intuitive to me, and matches everyone I know. No substitute for data of course.

> Since sites can now get that info from _everyone_ without requesting or
> receiving any getUserMedia permission we should get some data to reassure
> ourselves it's not too fingerprinty.

There's a debate on that on the list FWIW (which probably spawned this bug) [2].

> What is the value of enumerating opaque device IDs if you don't have
> getUserMedia permission?

Harald takes a stab at this here [3]

> Especially if they change every session as implied by the spec.

They are persisted, as mentioned above.

[1] http://w3c.github.io/mediacapture-main/getusermedia.html#widl-MediaDeviceInfo-deviceId
[2] https://lists.w3.org/Archives/Public/public-media-capture/2015Jun/0050.html
[3] https://lists.w3.org/Archives/Public/public-media-capture/2015Jun/0048.html

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #5)
> Our implementation

Sorry, that should have read:

Our implementation hashes the system's raw internal device ids with HMAC-SHA256 with a random number (the origin-key) associated with the site's origin, as the key, to produce the deviceIds that content JS sees.

Clearing cookies clears the origin-key.

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #5)
> > What is the value of enumerating opaque device IDs if you don't have
> > getUserMedia permission?
> 
> Harald takes a stab at this here [3]

Not very effectively. His better point was for "A UI that is resumed" which would imply permission was in fact previously given. His first point, UIs that adapt to system capabilities, don't require persistent IDs.

Double-keying IDs in iframes is a hack to lessen the damage from persistent IDs. A better solution is simply not to have persistent IDs unless the user has given the site permission to use Media. On those sites the user is trading information for features. On every other site the user gets nothing for the additional tracking ability persistent IDs introduce.

(I'm not even arguing about the additional identifying bits leaked by number and type of devices, but I'm sure the Tor Browser will have to do something about that.)

Comment 8

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Daniel Veditz [:dveditz] from comment #7)
> A better solution is simply not to have persistent IDs unless the user
> has given the site permission to use Media. On those sites the user is
> trading information for features. On every other site the user gets nothing
> for the additional tracking ability persistent IDs introduce.

See https://lists.w3.org/Archives/Public/public-media-capture/2015Jul/0004.html

Comment 9

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

comment 8 was implemented in Bug 1181428. Closing this as dup of that.