Live data from Hacker News

HSTS Super Cookies

radicalresearch.co.uk

21–30 of 56 posts

Re: HSTS Super Cookies

#21
I'm not quite sure if I wouldn't _expect_ the incognito mode to respect HSTS. I'd think that you would use incognito mode for ~sensitive~ tasks.

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)

Re: HSTS Super Cookies

#22
This has been known for quite a while. I managed to find a case where HSTS allowed information leakage between private/non-private frames within the same browser in Firefox, but I think that's been fixed.

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.

Re: HSTS Super Cookies

#23

Seems Chrome has addressed the issue with incognito mode - if you open the page in incognito mode you get a different code.

Chrome has different SSL validation on each operating system - on Linux it uses it's own NSS instance, on OS X and Windows it uses the OS level certificate validation routines. Not sure how HSTS plays into that.

Re: HSTS Super Cookies

#24
post #20

Wow, 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!

Under History > Clear Recent History, make sure "Site Preferences" is also checked.

Re: HSTS Super Cookies

#25
post #19

> 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…

Many people use it to spawn what is effectively a "guest session" in which they can log into some site with account B when they're already normally logged in with account A, without having to log out of account A. Or, similarly, to temporarily deactivate such things as Google's per-user search results personalization. Sites that leak credentials into such "guest sessions" break their usage for such purposes. (In fact, since in Chrome incognito windows are just a special case of user profile switching, HSTS probably leaks credentials between user profiles as well, completely mooting the point of them.)

Re: HSTS Super Cookies

#26
post #15

Earlier 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.

My point was the subtle difference between automated data clean at end of browsing session and the reported manual action. Nothing else.

Re: HSTS Super Cookies

#27
post #17

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.

Same here, got same code on OSX 10.9.5 Chrome 39.0.2171.95

Re: HSTS Super Cookies

#30
It sounds like HTTPS Everywhere is overlapping functionality with HSTS. Is there some way that HTTPS Everywhere could just inject HSTS rules rather than looking up every URL and rewriting it before sending a request?
Post reply on HN