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."
Using Chrome 5 development version, the site says it can't find any history on my machine at all (not using incognito).
Firefox, on the other hand, has a potty mouth.
'For we walk by faith, not by sight.' II Corinthians 5:7
Hey Taco! "Vulnerable" and "Affected by" are not synonyms.
Three Squirrels
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.
In today's news:
Just a small sliver of web users are victims of Browser History Stealing. Most are running Windows 7, connecting through an IPhone and paying Facebook for the privilege.
Well for starters, I can email you a joke of the day and log whether you've been to the craigslist personals lately. Your wife might not like knowing that.
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
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).
People generally use the same or similar usernames and passwords for most of their online identities. If you you know someone in particular uses facebook.com, hotmail.com, kittenwar.com and randombank.com you can use facebook and kittenwar as attack vectors against their email and banks. Alone, history sniffing does not present a huge threat. But it can dramatically increase someones vulnerability to identity theft.
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.
> Look, just give it up already. Everything you do is being tracked, by
> somebody, anybody that's interested.. You can't hide anything from your
> service provider...
I rather doubt that my ISP or anyone else knows my private GPG key.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Doesn't unchecking the "keep my history" button under "privacy" take care of this?
Eloi are stupid, throw morlocks at them!
Hey, wait a second ....
I tried...I tried really hard and almost soiled myself with the effort, but I just can't care about my browser history being "stolen".
that's like calling my garbage being stolen every week when the big truck comes and takes it away.
Hell, the more time people spend stealing browser histories is time they're not spending doing something I do care about, so keep at it!
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.