Thanks for all the insightful comments about how this "didn't work for you" or "I'm paranoid so I survived this"?<p>It works. It works enough of the time and on enough browsers to be very relevant to anyone who cares about the privacy/security of internet users at large.<p>This is an impressive proof of concept, and an important thing to be discussing, yeah?<p>[EDIT] To clarify, I tested this on Firefox 8.0.1 on my 2011 iMac with Lion and it worked flawlessly one by one as I visited the sites "Facebook, Reddit, Flickr", they turned from gray to green in each subsequent test.
Very simple summary of the technique:<p>To test if a user has recently visited Facebook, see how long it takes for the Facebook logo to load when called from your own page. If it's relatively fast, you can assume the image has been cached by the user's browser ... meaning the user has recently visited Facebook. If it's relatively slow, you can assume no cached version of the logo is available, so the user probably hasn't visited Facebook recently.<p>Results are fuzzy because "relatively fast" and "relatively slow" are not precise.
It is missing some sites which have https-everywhere rules. Still a scary thing; looking at the comments in the source, would coalescing load events deter the attack, or at least make it probabilistic and slow? And why isn't Firefox displaying requests to the sniffed sites while it attempts to access them? The request is already issued, even if the script manages to abort it before it completes.
Let's hope it doesn't attract the typical browser developers' slapdash response of "let's fix this by breaking the DOM," as happened with the :visited trick.
I accidentally fireproofed myself against this attack. I have the Web Developer extension installed and I forgot I had the Disable Cache option on.(The script works as advertised with it off.) Not really practical solution if you want pages to load fast.
As it turns out, I'm one of the minority of users who keep NoScript in paranoid mode until I really want to see something supplied by JS -- and then I'm likely to only give temporary permission and turn that off when I'm done.<p>Obviously, this didn't work against me.
Why the need for a "sub-ms" timer implementation? Just do a while loop and constantly check for the SOP exception (or for Xms to have elapsed). Set a timeout between checking URLs. The ~10ms blocking of each URL check will not be noticeable to the UI.<p>Nice PoC though, and thanks for the lack of press release ;)<p>Edit: I just tried this out and it appears that the looping JS blocks the iframe from loading. I would have figured the iframe would be a separate JS thread. I'm wondering -- do all iframes share the same JS thread? Can one iframe block another? Anyway, it's clear that some sort of asynchronous solution is necessary.
It reports completely bogus entries for me, which I never visit:<p><pre><code> Blogger - admin
Bing
Google search (UK)
eBay
PayPal
MySpace
LiveLeak
Playboy
Sears
Lowes
Newegg
</code></pre>
These are besides entries like Wikipedia, Google, Facebook, Youtube, LinkedIn, Reddit - which most other people here are visiting.<p>If this is based on actual info taken from :visited selectors, apparently they are useless (maybe these are reported because of banners or scripts loaded from those sites or something?) and one could do a better job by just faking it.
People may be using it wrong. My browser cache clears every exit (likely for most people at HN). I had a new session going so it didn't detect where i went because there was no history. When i went on facebook and tried it again, facebook showed up. So the attack does work in some cases.<p>The one good thing that could come out of this is that websites with the gianto bar of "follow me/like me" icons could be different sized based on if you detect that the user has went to certain social media site.
it detected some sites ive never been to (arent in history) oddly. they dont seem in cache or via adverts either.
some others i went to were detected, but..
The webtiming paper provides more information on this form of attack - <a href="http://sip.cs.princeton.edu/pub/webtiming.pdf" rel="nofollow">http://sip.cs.princeton.edu/pub/webtiming.pdf</a><p>The summary of the paper makes me sad -
> We are not aware of any practical countermeasures to these attacks. There seems to be little hope that effective countermeasures will be developed and deployed any time soon.
Very random results. I used this on Firefox (beta nightly) and on a fresh start got no entries. When I opened Facebook in another tab then quickly ran again, it said I had gone to Facebook, Twitter and Blogger. When I retried, just Facebook. It also said I went to almost all the eCommerce websites without me having visited any.
I have largely varying results in FF9.<p>The idea is interesting but, considering that the performance of the client (-box) can affect the results, it doesn't feel very viable.<p>What about DNS cache probing? Is it possible? I guess it will suffer from similar results but at smaller scale.
It got just youtube right for me. Considering the websites it's saying you might have visited, there's a high probability of getting at least some right because a large population on the internet visit those sites. Looks bogus to me!