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)
HSTS Super Cookies
21–30 of 56 posts
Re: HSTS Super Cookies
#22In 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.
Re: HSTS Super Cookies
#23Seems Chrome has addressed the issue with incognito mode - if you open the page in incognito mode you get a different code.
Re: HSTS Super Cookies
#24Wow, can't get it to go away on Firefox 33.0 Ubuntu. I was able to clear it by manually deleting the info from the permissions.sqlite3 database as described by agwa. Very clever!
Re: HSTS Super Cookies
#25> The impact is that it's possible for a site to track you even if you choose to use "incognito" or "private" browsing features in an effort to avoid such tracking. 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…
Re: HSTS Super Cookies
#26Earlier quoted context omitted.
That would somehome indicate to me (without having looked at the code), that this has been implemented like this on purpose.
The basic background problem is that in the "normal" case, HSTS is a security and privacy protection rather than a tracking mechanism. That's why one would typically want it to persist as much as possible. But it has the potential for tracking effects too (as this project demonstrates). I guess the current browser behavior is indeed an attempt to project user intentions based on that.
Re: HSTS Super Cookies
#27Re: HSTS Super Cookies
#28Re: HSTS Super Cookies
#29Using Firefox 34.0 on Ubuntu, I get a different code in the private browsing window. No add-ons are enabled.