Issue metadata
Sign in to add a comment
|
DeviceId never gets changed with enumerateDevices(), allowing persistent fingerprint
Reported by
s.h.h.n....@gmail.com,
Nov 26 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: 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 the problem: 1. Go to https://attack.shhnjk.com/device_cookie.html 2. Note the User ID given by website. 3. Disable Cookie (https://support.google.com/accounts/answer/61416?co=GENIE.Platform%3DDesktop&hl=en) 4. Restart the browser and access the site given in step 1. What is the expected behavior? Same User ID is displayed. Persistent finger print without cookie. What went wrong? 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. Did this work before? N/A Chrome version: 62.0.3202.94 Channel: stable OS Version: OS X 10.13.1 Flash Version:
,
Nov 27 2017
Per https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Why-isnt-passive-browser-fingerprinting-including-passive-cookies_in-Chromes-threat-model We don't consider device ID or any other kind of fingerprinting as a vulnerability. I'll remove the security label and let engineering team to decide if there's any related functional bug in this reporting.
,
Nov 27 2017
Not sure the right label, but this is definitely not a cookies issue.
,
Nov 27 2017
I thought we used a per-browser salt with the device id and the values exposed to the renderer to avoid this?
,
Nov 29 2017
,
Nov 29 2017
This is fixed in M64.
,
Nov 29 2017
Also note that the repro instructions are incorrect. It is not possible to use device IDs to allow persistent fingerprinting of users after they clear cookies. We use a random salt to generate device IDs in the renderer process. The salt is reset after clearing cookies, so restarting the browser after clearing cookies results in new device IDs. Before M64, we were caching the salt per renderer process, so device IDs remained the same after clearing cookies only in existing renderer processes. As long as the site is opened on a different renderer process (typically a new tab) device IDs will be different. The same happens if the browser is restarted. Since M64, we do not cache the salt anywhere, so device IDs are reset even for existing renderer processes. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by jialiul@chromium.org
, Nov 26 2017