1420653 - DeviceId is persisted even if cookies are disabled, allowing persistent fingerprint

Status: NEW

(Core :: WebRTC: Audio/Video, defect, P3)

Description

[Jun (Request needinfo for comment, I ignore other updates)]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

1. Go to https://attack.shhnjk.com/device_cookie.html
2. Note the User ID given by website.
3. Click on Go button.
4. Disable Cookie (https://support.mozilla.org/en-US/kb/enable-and-disable-cookies-website-preferences)
4. Restart the browser and access the site given in step 1.


Actual results:

DeviceId does not persist after the end of browsing session.


Expected results:

https://www.w3.org/TR/mediacapture-streams/#attributes-5 says:

"Since deviceId may persist across browsing sessions and to reduce its potential as a fingerprinting mechanism, deviceId is to be treated as other persistent storage mechanisms such as cookies [ COOKIES], in that user agents must not persist device identifiers for sites that are blocked from using cookies, and user agents must reset per-origin device identifiers when other persistent storage are cleared."

This isn't implemented.

Further more, other paragraph says:

"However, 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 the user agent may clear this identifier once the last browsing session from this origin has been closed. If the user agent chooses not to clear the identifier in this condition, then it must provide for the user to visibly inspect and delete the identifier, like a cookie."

But I don't see any place where developer tools allow user to inspect and delete the deviceId.

Comment 1

[Jun (Request needinfo for comment, I ignore other updates)]

Sorry, after the step 3, you need to click on allow microphone access. But you don't need to store the permission.

Comment 2

[:Gijs (he/him)]

:jesup, can you help triage this further? Thanks!

Comment 3

[Daniel Veditz [:dveditz]]

The current behavior was an intentional change in bug 1181428 as a compromise between utility and privacy. DeviceIDs are unique per site (and origin attribute, that is, containers, private browsing, and first-party isolation if enabled), and only saved on sites where the user has explicitly interacted with devices.

Yes, we should "treat these like cookies", but that doesn't mean you need to be able to inspect them. They are opaque values, even less useful than data in indexeddb which we also don't provide a mechanism to inspect in detail. Delete? For sure.

According to bug 1223773 comment 12 we've already hooked this into almost all cookie-like hooks. Did we regress those? Or (since it was not explicitly mentioned) did we never hook a cookie permission check into saving these in the first place? "Forget this site" is broken (bug 1152448) so that's not inconceivable.

Moving the needinfo? to Jan-Ivar who was involved in the earlier discussions.

Comment 4

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

(In reply to Jun from comment #0)
> Actual results:
> 
> DeviceId does not persist after the end of browsing session.

This is bug 1223773. I've had patches there for a long time, but disagreement prevented landing them.

(In reply to Daniel Veditz [:dveditz] from comment #3)
> They are opaque values, even less useful than data in indexeddb which we also
> don't provide a mechanism to inspect in detail. Delete? For sure.

With "visibly inspect" I believe the spec means a way for users to observe the presence (or absence) of the opaque value, so they can delete it like a cookie. E.g. Chrome's "See all cookies and site data" - chrome://settings/siteData

> According to bug 1223773 comment 12 we've already hooked this into almost
> all cookie-like hooks. Did we regress those? Or (since it was not explicitly
> mentioned) did we never hook a cookie permission check into saving these in
> the first place? "Forget this site" is broken (bug 1152448) so that's not
> inconceivable.

Jun, sans bug 1223773, disabling cookies would only prevent persistence of deviceIds past Firefox shutdown. Is that not working for you?

(Full disclosure: I don't recall adding an explicit check for cookies being disabled, though I might have assumed that, internally, the call to clear cookies on shutdown (startup really) would be called in that case, which we do hook into)

> "However, 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 the user agent
> MAY clear this identifier once the last browsing session from this origin
> has been closed.

The "MAY" here (emphasis mine) is what bug 1223773 implements.

> IF the user agent chooses NOT to clear the identifier in this condition,
> THEN it MUST provide for the user to visibly inspect and delete the identifier, like a cookie."

In other words, if we land bug 1223773 then we DON'T need to provide visual inspect-and-delete.

> But I don't see any place where developer tools allow user to inspect and
> delete the deviceId.

There isn't one.

Comment 5

[Jun (Request needinfo for comment, I ignore other updates)]

>Jun, sans bug 1223773, disabling cookies would only prevent persistence of deviceIds past Firefox shutdown. 
>Is that not working for you?

Disbling cookie doesn't affect persistence of deviceId. If user allowed access to microphone for only once (without tick on "Remember this decision"), deviceId persist forever.

Comment 6

[Martin Thomson [:mt:]]

I hear that we're talking about reconciling state management.  Maybe this could be added to the pile for bug 1147820.

I don't know what the story is for persistence of X in relation to cookie settings for X being any of (indexedDB, local storage, service workers, etc...).  Nail that down and the answer to this question comes out of that.