Re: [mediacapture-main] fixed, per origin, device ID creates tracking risk (#607)

> I agree, it would be good to have a single "storage partitioning, double-keying" definition / spec, but until that exists, we need to deal with the state of standards as is. If future spec comes and makes specifying double-keying in this spec unnecessary, thats great and a perfect reason to revise this spec and remove it.

@snyder Isn't it the opposite? Future partitioning of cookies and localStorage wouldn't make this unnecessary. Rather, it would seem like a prerequisite for the suggested mitigation to matter.

> all embedded's would be able to track the user,

They would be able to do that today without this spec using:
localStorage.fingerprint = Math.random().toString(36);
So where is the issue?

> This risk is somewhat mitigated by tying their lifetime to cookies, but this in practice is insufficient, since many privacy systems protect their users w/o clearing cookie stores (e.g. Safari's ITP, Brave enforces a fixed life time on JS set cookies, etc.).

If the lifetime is tied to cookies, and Brave enforces fixed life time of cookies, doesn't that mitigate it?

The [spec]( *"recommends to treat the per-origin persistent identifier deviceId as other persistent storage (e.g. cookies) are treated."*

I think our intent here was to make this no worse than cookies. OTOH there doesn't seem to be much point in wasting effort making it better than cookies, because JS would just store the ids in cookies then.

Those are non-normative recommendations though, so the spec could perhaps be stronger normatively here.

In Firefox, we're considering [some mitigations for enumerateDevices pre-gUM-grant]( but those are motivated more by the actual user system bits exposed, like number of cameras and number of microphones, not the id.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 24 July 2019 03:02:43 UTC