41–50 of 56 posts
Firefox stores HSTS entries in a SQLite database, which you can query by running: echo "SELECT * FROM moz_hosts WHERE type='sts/use';" | sqlite3 permissions.sqlite from inside your profile directory. To clear HSTS entries (which the "Clear recent history" UI does not delete), you can do: echo "DELETE FROM moz_hosts WHERE type='sts/use';" | sqlite3 permissions.sqlite I've been periodically monitoring this database for…
I'm actually pretty irritated that this researcher makes it out as an iOS thing only, it feels like he/she just didn't care to try on anything other than the device they had in front of them. Chrome on Android behaves the same way the researcher described (fingerprinting works in Incognito tabs), but Chrome, Opera, Firefox, and IE on Windows all get different IDs.
Seems Chrome has addressed the issue with incognito mode - if you open the page in incognito mode you get a different code.
Not for me. Mac OS X 10.10.1, Chrome 39.0.2171.95. I get the same code even in incognito mode.
Steps:
1. Open browser, open [1] in new tab. Get code X.
2. Open [1] in new incognito window. Get code Y.
3. Reload that incognito window. Get code Y.
4. Close incognito window.
5. Open [1] in second new incognito window. Get code X.
Subsequent iterations of opening/closing regular and incognito windows and/or restarting Chrome all yielded code X.
I'm actually pretty irritated that this researcher makes it out as an iOS thing only, it feels like he/she just didn't care to try on anything other than the device they had in front of them. Chrome on Android behaves the same way the researcher described (fingerprinting works in Incognito tabs), but Chrome, Opera, Firefox, and IE on Windows all get different IDs.
Seems Chrome has addressed the issue with incognito mode - if you open the page in incognito mode you get a different code.
>However, unlike cookies, existing HSTS flags are still shared with sites when using "incognito" or "private" windows. fwiw, though Firefox is listed in there as "leaks across private mode", I get an entirely new ID when I open a private window. v34.0.5
Firefox stores HSTS entries in a SQLite database, which you can query by running: echo "SELECT * FROM moz_hosts WHERE type='sts/use';" | sqlite3 permissions.sqlite from inside your profile directory. To clear HSTS entries (which the "Clear recent history" UI does not delete), you can do: echo "DELETE FROM moz_hosts WHERE type='sts/use';" | sqlite3 permissions.sqlite I've been periodically monitoring this database for…
Earlier quoted context omitted.
Not for me. Mac OS X 10.10.1, Chrome 39.0.2171.95. I get the same code even in incognito mode.
Well that's interesting. This may shed light on some of the seemingly conflicting results. On Mac OS X 10.10.1, Chrome 41.0.2264.2 (Canary): Steps: 1. Open browser, open [1] in new tab. Get code X. 2. Open [1] in new incognito window. Get code Y. 3. Reload that incognito window. Get code Y. 4. Close incognito window. 5. Open [1] in second new incognito window. Get code X. Subsequent iterations of opening/closing regu…
This privacy risk is actually documented in the official HSTS specification, section 16.9 of https://www.rfc-editor.org/rfc/rfc6797.txt However, the spec doesn't propose a mitigation for it. I'm afraid many new security policy mechanisms can actually be used to track users or devices this way, because you can experiment to see whether the browser has heard about a particular security policy by observing its behavior…
The HPKP tracking problem is described in section 5 https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinni... which also includes another description of this HSTS problem.