MUST clear requirement for deviceId

[martinthomson]

I apologize for not properly following the giant cluster of issues around #322, #326, #328, and #330, but I don't believe that the main reason I opened #322 was properly addressed.

The offending text is this:

All enumerable devices have an identifier that MUST be unique to the page's origin. As long as no local device has been attached to a live MediaStreamTrack in a page from this origin, and no stored permission to access local devices has been granted to this origin, then this identifier MUST NOT be reusable after the end of the current browsing session.

As noted in #322, this is not what browsers currently do. Nor is it what I believe that they should do. They should do what Harald says Chrome does. The other parts of the text are fine, but this isn't right.

I would be OK with "the user agent MAY generate a new identifier for every new realm created for the origin, see [[section with better details]]."

[alvestrand]

The scenario that led to the persistent-but-origin-dependent device ID was the scenario where one configured an application to work with a certain camera. One would then want to have this piece of configuration persist after the camera was closed.

In Option-1, there is no way to remember the setting after closing the camera and closing the session (whatever a session is) without ceating a stored permission.. One has to restart the camera-picking procedure every time the session restarts. (Think kiosk mode devices.)

In Option-2, one still gets the permission prompt (no permission is stored), but the application is able to remember the camera between session.

(Another option that was valid under some versions of the permissions spec was to store an explicit "ask" permission to achieve the same effect. That's another way to skin the cat.)

[ShijunS]

Would the following be a reasonable compromise for various devices and scenarios?

A. If stored permission to access local devices has been granted to this origin, then this identifier MUST be persisted across browsing sessions. B. If any local devices have been attached to a live MediaStreamTrack in a page from this origin, then this identifier MAY be persisted across browsing sessions.

I think we all agree on A. Re B, browser vendors can introduce browser-specific settings so users can turn it on/off for their devices and scenarios. So, we don't have to define dependencies on cookies, histories, or another permission, etc. in this version of the spec.

[jan-ivar]

@ShijunS I think you're looking at the wrong part. IMHO the (past or present) tense of the trigger condition is less relevant than _what it triggers_:

if any local devices have been attached to a live MediaStreamTrack in a page from this origin, or stored permission to access local devices has been granted to this origin, then this identifier _MUST be persisted across browsing sessions. "_

I don't see how _MUST be persisted across browsing sessions_ is ambiguous in any way. These ids must be persisted, or sites wont be able to remember my camera from last time, except in Chrome.

[ShijunS]

@Jan-Ivar. Reaching common understanding of the trigger condition (not really the past/present tense) is important for us to reach interop for "what it triggers".

FWIW, implementation wise, the Chrome model in handling the permission seems now to make more sense to me. Having a stored permission by default should cover the scenarios pretty well.

[jan-ivar]

@ShijunS The trigger condition is effectively any successful gUM call from a page from an origin. Once triggered, the browser is supposed to persist that origin's deviceIds for eternity (∞ = clear cookies).

It may look like this mirrors stored permissions in Chrome, but it doesn't: Users can revoke permissions, but deviceIds persist. I don't see a shortcut here.

[ShijunS]

@Jan-Ivar. The specific portion of the spec can certainly use some clarification. Implementation wise, I'm fine with the Chrome approach mentioned by Harald - seems straightforward.

[stefhak]

@ShijunS thanks for elaborating on the different parts here. I think you are definitely right in that more clarification is needed is needed in the spec. And we also need to agree on what behavior that is to be mandated by the spec.

As @jan-ivar and @alvestrand points out, one intention was to enable a site (even if it did not request or the user/browser did not approve persisted access to microphone(s)/camera(s)) to find out if a preferred device is connected, and if so request it. It was also intended that clearing cookies would reset this (and the spec should be clearer). This behavior would be useful for sites (and end users) if they do not have persisted access to use input devices.

We could remove this if the default will be that browsers persist access to input devices by default. It would simplify since the options are fewer, either the site does neither have access to input devices nor stable deviceIds, or it has access and stable deviceIds. It would also make it clearer to the end user: if there is persisted rights to use camera and mike the issue of fingerprinting is probably less important, and if there is not persisted rights we have not added a big fingerprint.

The problem with removing would IMO be that we remove the possibility for some middle ground: the site can ask for the "right" devices, but the user must approve every time. And also for the case @jan-ivar mentions: the user can revoke persisted permissions, but the site can ask for the "right" devices next time.

I'm not sure how important those cases are, but this was a background to why the spec say what it says.

[jan-ivar]

We could remove this if the default will be that browsers persist access to input devices by default.

@stefhak A different default seems insufficient. You'd have to eradicate non-persisted access entirely.

[stefhak]

@jan-ivar I agree.

[stefhak]

https://lists.w3.org/Archives/Public/public-media-capture/2016Jun/0046.html was sent to the list. This issue was subsequently discussed at the June 28 2016 virtual interim meeting (minutes at recording at https://lists.w3.org/Archives/Public/public-media-capture/2016Jun/0057.html). The outcome of that discussion was that @jan-ivar would create a PR that allowed implementations to do what the spec currently mandates, but also to treat deviceIds more like cookies (which would include text about not allow persisting deviceIds if cookies are not allowed, to clear if cookies are cleared, to make persisted deviceIds visible to a user inspecting cookies and more).

[jan-ivar]

Yup, though I thought the idea was to mandate what the spec currently does OR treat deviceIds more like cookies... i.e. give UAs a choice.

[stefhak]

Yes, it's clear that UAs should have a choice. If that was not clear from my text it was my mistake, but I think the real discussion will start when we have a concrete proposal to review.

[alvestrand]

Fixed in #381