Re: Follow up issues from WebRTC / PING TPAC meeting

I said I would post some ideas.

On 9/27/19 6:33 AM, Mike O'Neill wrote:
> I think the main privacy issue is that the UID is invisible (the user has no way to see it has been accessed) and immortal (on Chromium based UAs the only way to reset it is to delete all cookies).

I think this is a point. We're all "no ids!", as if ids are rare, but 
they're trivial. The only difference between deviceId and 
Math.random().toString(36) is this.

Implementations also have bugs getting this snowflake right. Would 
concerns go away if we picked a storage class (cookie, localStorage, or 
indexedDB) and mandated a deletable (hashed) representation there?

> Double-keying makes it harder to correlate individual browsers cross-domain (because iframes on different sites get different results), but there are other way to correlate anyway e.g. cookie synching via dynamic urls, IP source address matching etc.
> (double-keying all storage would be a major step forward for privacy though).
>
> Safari makes the deviceId null on MACs and that does not seem to have caused much of a problem.

That's only ahead of initial getUserMedia grant. Safari has sacrificed 
the "choose camera beforehand" use-case, which it sounds most of us are 
onboard with?

The remaining discussion appears to be what's shared once this implicit 
device-info permission is granted, which is lots of stuff. Like labels.

Which leads me to my last idea:

 1. Remove deviceId
 2. Add a deviceName constraint (no-op without device-info permission)

Then let JS store the label instead:

   const stream = await navigator.mediaDevices.getUserMedia({video: 
{deviceName: localStorage.chosenCamera}});
   localStorage.chosenCamera = stream.getVideoTracks()[0].label;

We only needed deviceId in the first place to cover the "choose camera 
beforehand" use-case, when there's no label.

Would that make us happy?

.: Jan-Ivar :.