61–70 of 99 posts
I hit the page from Chrome 45.0.2454.101 and it literally did not get a single site that I regularly visit. It did make a hit on Reddit, I guess, but I have only visited the site two or three times, and you could probably say that about 2/3 of the population.
interesting, are you using any browser addons? please file a bug at https://github.com/diracdeltas/sniffly , thanks
Earlier quoted context omitted.
interesting, are you using any browser addons? please file a bug at https://github.com/diracdeltas/sniffly , thanks
Same here. Most sites are those that I visited shortly a long time ago.
I hit the page from Chrome 45.0.2454.101 and it literally did not get a single site that I regularly visit. It did make a hit on Reddit, I guess, but I have only visited the site two or three times, and you could probably say that about 2/3 of the population.
Hardly.
Earlier quoted context omitted.
No. Leaks were known far beyond the "supercookie", but attacks were not as high quality as these.
Could you link some older sources discussing some of these leaks? I'm having trouble finding any. Not doubting you, since you're probably right; would just be interested in reading them.
I may write a blog post later about this, but here are a few that come to mind (only counting things that have demos or have been observed in the wild):
* css-visited browser history sniffing (fixed several years ago): http://dbaron.org/mozilla/visited-privacy * HSTS unique-subdomain combination supercookies: http://www.radicalresearch.co.uk/lab/hstssupercookies * lcamtuf's cache timing attack: http://lcamtuf.coredump.cx/cachetime/ * webrtc local ip leak: https://diafygi.github.io/webrtc-ips/ * panopticlick: https://panopticlick.eff.org/ * evercookie: http://samy.pl/evercookie
The site attacks seems to fail in Tor Browser. It returns a list of sites that have nothing to do with my browser history. Probably because Tor Browser reduces the time precision.[1] It seems like it would be nice to require some sort of user privilege escalation like accessing location, or webcam to access high precision timing. This would close off a huge class of time related side channels. [1] https://trac.torpro…
See discussion at https://trac.torproject.org/projects/tor/ticket/17423
Earlier quoted context omitted.
I pulled the list of domains out of the Alexa Top 1M plus some domains that my friends run. But I'm not biasing results towards showing up as visited by popularity or anything like that. I didn't set up analytics to figure out how accurate results are for the average person; having manually checked with a few people's browsers, I'd say the accuracy rate is ~75%.
At a glance, looks about 75% accurate for me. But what really freaked me out is that it correctly flagged a financial institution (not a major one) where I have an account yet feel pretty sure I haven't visited the website in months.
Probably a good idea to edit the title to indicate that this is an example attack site as well, not my favorite thing in general to land on without warning. No js seems to mean no worries though.
The results never leave your browser, though, so there's not much to worry about.
You are not allowed to read the content of those resources for security reasons, and the fact that you can detect whether they have been loaded seems just as broken (although obviously this usually only has privacy impact, while reading the contents easily allows impersonating the user or stealing secrets).
This attack abuses this by using HTTP URLs and causing HTTPS to trigger onerror by using a content security policy that disallow HTTPS, which allows to measure timing of the HTTP->HTTPS redirection, which is instantaneous if the site had already been visited due to HSTS caching.
So I think two changes are needed:
1. The browser should never fire onerror on non-CORS-allowed 3rd party resources, but instead fire onload even if an error happens
2. The onload event should ideally be triggered 1 second after the resource has been seen regardless of whether it has been loaded or not. If that breaks too many websites, the timing granularity should be rounded to the greatest period possible.
There is also the problem of lots websites having CORS policies that allow * , so should probably also fix browsers to not allow sites to have CORS * policies, at least for this purpose.
Alternatively, it might be possible to load those resources normally, but effectively consider them to be a "3rd party origin from 1st party origin" that is different from "3rd party origin" and from other 1st party origins for all caching purposes.
However, this seems risky because if the 3rd party site manages to somehow fingerprint the user (e.g. because the IP address is whitelisted) then that information is potentially leaked to the 1st party site. For example, it would be possible to detect whether your IP is whitelisted by a domain that otherwise returns errors to everyone.