HSTS Super Cookies

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 when you ask it to violate the policy. If you tell different devices about different policies, their behavior will be different (as if you told different kids who were going to visit a park about different rules for how to behave in the park, and then observed who obeyed and who violated which rules as a way of identifying individual kids).

For example, you can also get tracking out of public key pinning, by selectively pinning certs for some subdomains and not others, and then seeing which subresources are successfully loaded when you present a huge number of pin violations. (I think that's also documented in the HPKP spec.)

  echo "SELECT * FROM moz_hosts WHERE type='sts/use';" | sqlite3 permissions.sqlite

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 always thought that (despite user hopes) the point of 'private' browsing was explicitly and only to avoid leaving traces on the user's computer anyway. (For example, I used it when shopping for Christmas presents.) The Firefox new private window has a warning to this effect:

> While this computer won't have a record of your browsing history, your employer or internet service provider can still track the pages you visit.

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

In general, the browser vendors seem to think that HSTS is worth the potential privacy leak. I've also heard some people say they're monitoring to see if anyone does it and will respond if it becomes a problem.

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.

https://cyberlaw.stanford.edu/files/publication/files/tracki...

FTA: "A website can encode a globally unique pseudonymous device identifier into any stateful web technology so long as it persists at least log2 n bits, where n is the number of Internet-connected devices (presently roughly 5 billion, requiring 33 bits)."

Defaulting to https due to a known HSTS flag seems good in this case, otherwise every incognito session would start out blank, right? (I'm ignoring the white list from the browser vendor)

It does not seem like there's a major use-case for secondary resources: images, css, javascript, etc loaded on the page itself, and which serve as the vector in this attack. Such resources must be requested via https on a https site itself anyways.

So, wouldn't it be better to just restrict the usage of HSTS protocol overrides to just the main domain being requested by the user in the URI bar?

Very clever!