This is all very cute, but the real exploit isn't embarrassing your friends and co-workers by revealing their kinks. Imagine a phishing site which could sniff your browser history to see which bank you use, and then provide a customized login form masquerading as that same site.
Exposing browsing history via CSS color information in the DOM is a serious security hope that should be closed by browser vendors.
It's definitely a useful trick for only showing certain content to certain users. For example, I wrote a script so you only show Digg buttons to visitors that have been to digg.com: http://int2e.com/blog/improved-digg-integration-script/
Note. It is possible for style sheet authors to abuse the :link and :visited pseudo-classes to determine which sites a user has visited without the user's consent.
UAs may therefore treat all links as unvisited links, or implement other measures to preserve the user's privacy while rendering visited and unvisited links differently. See [P3P] for more information about handling privacy.
It's not really relevant to anything. I could say it's another reason to go back to using BBS's instead of the WWW, but that's not really a useful observation is it.
I don't think disabling JS by default is equivalent to going back to BBSes. IMO it's how JS and other client-side scripting technologies should have been implemented from the very beginning, on an opt-in basis with the onus on the site developer to convince users that it's worthwhile to enable the feature for their site.
But that's not what noscript does; it allows you to whitelist known-good scripts, and only run those. So when you go goodsite.com, you can see the cool javascript animations, but when you browse to steals-your-history.com, your history won't be stolen.
Sure, goodsite.com can choose to spy on you... but that is less likely than some other random site being the bad one.
"... but when you browse to steals-your-history.com, your history won't be stolen."
Ah, but you won't know if your history's being stolen, right? The exploit can be hidden from the user's eyes, hidden in an ad, for example, that the site you trust shows you without realizing that ad is hacking your history. Phishing sites, too, of course.
A big problem caused by this elegant hack is that it uses services web users can't easily do without, services that most browser users don't know about (and, ideally, shouldn't need to understand). I guess you're suggesting that a user must be more wary of websites, avoiding unknown ones. Is that what you're suggesting?
It'll be interesting to see what can be tried to remedy the privacy issues caused by this.
I use NoScript too, but you can do it in pure CSS and Noscript won't block it: just set a:visited for the link you're interested in to use a certain background image, which will only hit your server if the link is actually visited.
AFAIK the bug I shown is not currently fixed. The idea is to perform a request for an image in the target site (usually the logo), meter how many milliseconds it takes, if it takes very little (near to zero) you already visited the site. If the latency is instead in the normal range you didn't. See the article for more info.
20 comments
[ 4.0 ms ] story [ 46.1 ms ] threadExposing browsing history via CSS color information in the DOM is a serious security hope that should be closed by browser vendors.
It's one of those things which has questionable ethics…but honestly? A little awesome...
http://news.ycombinator.com/item?id=404564
http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes
Note. It is possible for style sheet authors to abuse the :link and :visited pseudo-classes to determine which sites a user has visited without the user's consent.
UAs may therefore treat all links as unvisited links, or implement other measures to preserve the user's privacy while rendering visited and unvisited links differently. See [P3P] for more information about handling privacy.
Demonstrates how powerful the technique is.
... why would I be down-voted for mentioning a solution which prevents 100% of JavaScript history attacks???
At one time browsers didn't display images by default eiter. It was horrible.
Sure, goodsite.com can choose to spy on you... but that is less likely than some other random site being the bad one.
Ah, but you won't know if your history's being stolen, right? The exploit can be hidden from the user's eyes, hidden in an ad, for example, that the site you trust shows you without realizing that ad is hacking your history. Phishing sites, too, of course.
A big problem caused by this elegant hack is that it uses services web users can't easily do without, services that most browser users don't know about (and, ideally, shouldn't need to understand). I guess you're suggesting that a user must be more wary of websites, avoiding unknown ones. Is that what you're suggesting?
It'll be interesting to see what can be tried to remedy the privacy issues caused by this.
http://antirez.com/page/cachetest.html
AFAIK the bug I shown is not currently fixed. The idea is to perform a request for an image in the target site (usually the logo), meter how many milliseconds it takes, if it takes very little (near to zero) you already visited the site. If the latency is instead in the normal range you didn't. See the article for more info.