Slashdot Mirror
76% of Web Users Affected By Browser History Stealing
An anonymous reader writes "Web browser history detection with the CSS:visited trick has been known for the last ten years, but recently published research suggests that the problem is bigger than previously thought. A study of 243,068 users found that 76% of them were vulnerable to history detection by malicious websites. Newer browsers such as Safari and Chrome were even more affected, with 82% and 94% of users vulnerable. An average of 63 visited locations were detected per user, and for the top 10% of users the tests found over 150 visited sites. The website has a summary of the findings; the full paper (PDF) is available as well."
TFA describes a honey-pot based study. It doesn't describe a real-world study of people whose browser histories were actually stolen by actual malicious websites.
The English word fart is one of the oldest words in the English vocabulary.
According to http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/ a future version of Firefox will address the :visited privacy issue.
One could also set layout.css.visited_links_enabled=false via about:config to disable :visited completely (at least until the issue is fixed in a future Firefox release).
No need for cookies, you just use javascript and CSS.
I actually implemented a history sniffer for an online advertising company a few years ago; we were using it as an additional selling point for potential advertisers, as in "We can tell you what percentage of your visitors have visited your rivals' landing pages".
Worth remembering you can only test against a list of exact urls that you're interested in, you can't just go browsing through a visitor's history. In other words, if I wanted to know how many pages you'd read on Slashdot, I'd need to test against every single possible URL.
Realistically that's pretty useless - I'd try to sell Ars Technica a solution that told them how many of their visitors have been to http://slashdot.org/. The obvious issue here is that neither I nor Ars Technica would need to get permission for this from either Slashdot or you; at the very least my product would need to give you an option to opt out.
I don't think you're correct in your list of options for protecting against the vulnerability. As a general principal, client side code from an untrusted source (ie. the web) should only have access to client side content which originated from the same source. In the case we're talking about, the content has been modified by the client based on private client state (ie. visited links), at this stage, the content should no longer be accessible to the code. If the rendering pipeline were more compartmentalized (ie. think XSLT translation steps), then code in one department wouldn't have access to content that has been modified based on private client state.
In this manner, the client environment could modify the content at will (ie. changing style for links to web sites you've been to, blocking ads, stripping flash, turning off client side code functionality entirely, etc.) without fear of what's being harvested or inferred. I don't know what a client's browser does to a dom to make it consumable by the deaf or blind, but if that's something that can be detected by untrusted code then I believe it's another example of violating a user's privacy.
Here is a demonstration of the hack using only CSS: http://ha.ckers.org/weird/CSS-history.cgi You can also use: background: url"(logger.php?site=pornsite.com"); No need for the background to be a real image. This even works if you're using Noscript with Firefox.