Devicechange event firing potentially being a fingerprint

[stefhak]

This is part of Nick Doty's feedback after reviewing how his comments made during LC have been addressed. What Nick says: "I raised this issue in my initial set of comments, and while there was some discussion with Harald, I'm not sure it ever got documented as an issue or had any resolution. I provided a little more detail in my response here: https://lists.w3.org/Archives/Public/public-privacy/2015OctDec/0028.html

My concern is that firing a devicechange event simultaneously in different browsing contexts (including tabs or iframes not in the foreground, or in different browsers altogether, that have not asked for any permissions) creates a risk of unexpected correlation of browsing activity."

[dontcallmedom]

cc @npdoty since he raised this

[dontcallmedom]

Some thoughts on this:

• I don't think any other hardware-generated events (device orientation, battery come to mind) do this; this shouldn't prevent us from leading the way, but if we do, it would probably worth getting input from other groups, possibly asking the TAG
• if we were to do this, I can imagine several approaches:
  • only generate the event if the site has been granted access to one device; but this doesn't enable the use case where a Web app will start providing an AV feature upon the plugging of the first mic/camera
  • only generate the event if the page is "visible" (as per the Page Visibility spec)
  • or suggest UAs should fuzz the emission of the events (and their timestamps), possibly as an informative mitigation (in which case we should probably add a note on this in the privacy section as well)

[alvestrand]

From Dom's comment, it seems that work on this class of issue would be pioneering in the W3C. I am reluctant to commit the WG to being a pioneer on this particular area. @npdoty comments?

[jan-ivar]

Subject says "fingerprint" but seems like "risk of unexpected correlation of browsing activity." is the issue. Isn't this where another tab can trick a user into answering a user prompt by, say, timing it to the insertion of a headset, tricking them into thinking it must be from the same site they're currently using for webrtc calling?

[jan-ivar]

Could this be mitigated by only firing on the browsing context that has focus, and defer firing on other contexts until they receive focus?

[stefhak]

@jan-ivar yes, I think I could have used a better subject. The issue you mention actually seems to make this worse than, say, the battery API. Your solution sounds like (a version of) @dontcallmedom's solution to only fire for visible pages. Anyway, it seems we have some potential solution ideas, but we've not worked through the consequences of them. I'm not sure we should pioneer this area.

[alvestrand]

The problem with not firing on other contexts is (of course) that comms applications will frequently be running without focus - for instance, a voice chat will often be running in a non-focus window while the user is doing something in another window and talking about it on the voice chat.

If (for instance) the handler for a devicechange event wants to make a notification alerting the user that he might need to change his selected microphone, delaying the alert is the wrong thing to do for the user.

One mitigation here that makes the exposure less: There's no simple way for a page to force a devicechange event.

I agree with Stefan that this is not an area where we're in a good position to be initial explorers.

[josephlhall]

Since this thread has some confusion about the specific discussion @npdoty brought up, I'm going to include that excerpt from the discussion @stefhak points to above:

Events

spec: When a new media input or output device is made available, the user agent MUST queue a task fires a simple event named devicechange at the MediaDevices object.

@npdoty: This event appears to be fired even for web pages that have not requested any permissions from the user. Is that intended?

@alvestrand: Yes. However, that was not a very deeply discussed decision - so it might be changeable.

Particularly if this event will be fired before any permission is granted, it is important that it not be fired simultaneously in all browsing contexts. Sites can use simultaneous firing to correlate browsing activity in different tabs, different windows (including private windows), different browsers, in a way that may be unexpected to the user and undermine other protections they're attempting to implement. Some specs have resolved this problem by noting that the event should only be fired for the front-most or active browsing context. I'm not sure how this would work for availability of devices - it would be strange indeed if my comms client would only notice new devices if it was the foreground tab.

I'm not sure I would expect a tab that I wasn't using but had access to a microphone to take action immediately upon plugging in a new microphone.

Separate and more important, does every tab and iframe that doesn't have permission to access cameras or microphones need to receive a simultaneous event when you plug a camera or microphone in? That seems like functionality unlikely to help the user, while making it harder to isolate activity via private browsing windows or separate browsers.

[dontcallmedom]

thanks @josephlhall for the reminder; so would a mixed approach work?

• before mike or camera permission has been granted, the events are only emitted in "active" (visible?) browsing contexts
• once mike or camera permission has been granted, emit the event immediately

(thinking aloud; but the chairs' point that we might not be in a position to lead the broader effort of consistent change remains)

[josephlhall]

I think that's a decent compromise, in that it avoids firing to unpermissioned contexts unless that has focus. I suspect @npdoty will point out that this doesn't deal with a permissioned non-focused context correlating activity across tabs/windows, but that's exactly where it sounds like the WG might be in undesirable exploratory territory. Thanks!

[alvestrand]

I'd be happy to restrict the firing to pages with the list-devices permission (equivalent to the "mike or camera permission has been granted"); this already modulates the output of enumerateDevices, so it's not a long jump.

[stefhak]

@dontcallmedom 's proposal resonates well with me as well. Is it reasonably simple to implement? (Speccing seems straightforward)

[alvestrand]

If we make it exactly the same condition as for listing extra device info (list-devices), I think it is.

[alvestrand]

Tagging @guidou for comments on implementability

[guidou]

Restricting the firing to pages with permission to list extra device info (as suggested by @alvestrand) seems easier to understand and implement.

[jan-ivar]

I like @alvestrand 's stricter proposal as well. mediaDevices is a global property, and firing on every tab in existence never seemed like a good idea.

[npdoty]

For what it's worth, this isn't an unprecedented concern and we have some experience with potential mitigations. For example:

• Proximity limits events to top-level browsing context:

The events defined in this specification are only fired in the top-level browsing context to avoid the privacy risk of sharing the information defined in this specification with contexts unfamiliar to the user. For example, a mobile device will only fire these events on the active tab, and not on the background tabs or within iframes.

• Mozilla's work on Idle API recommends fuzzing of event timing.

(I think Ambient Light also had something about top-level browsing context, but that spec has since been re-written as a generic sensor and so I don't see text about that any more.)

Per @josephlhall there is still a privacy risk regarding simultaneous event firing in different contexts even if those contexts have already been granted mic/camera permissions, but the risk is greatly reduced (it becomes an issue of sites you log into using two different browsers, say, rather than getting used by every background iframe ad). I think the spec could note that user agents may provide some fuzzing of the timing to mitigate that risk if they wish.

[npdoty]

I described the issue on our Ambient Light review in January 2013: https://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0007.html

[dontcallmedom]

I've added some text to #340 to suggest fuzzing as a mitigation:

These events are potentially triggered simultaneously across browsing contexts on different origins; user agents can add fuzzing on the timing of events to avoid cross-origin activity correlation.

and in the privacy considerations:

When permission has been granted, the devicechange event will be emitted across browsing contexts and origins each time a new media device is added or removed; user agents can mitigate the risk of correlation of browsing activity across origins by fuzzing the timing of these events.