Efficient history-stealing attack to identify website-visitors | Hacker News Reader

Efficient history-stealing attack to identify website-visitors

33bits.org

26 pointsyungchin9 comments

For reference, part 1 of this series was discussed here: http://news.ycombinator.com/item?id=1134370

This is the worst thing to hit the web since url shorteners. Just stop it. Wipe it from your mind. It's unethical. You are gathering information from your visitors that you have neither asked for, nor been given permission to retrieve.

It should be illegal. It's an invasion of privacy. Don't do it. Don't even learn that it is possible.

I hate to say this, but it hasn't hit the web. It is the web.

You're correct, It is an invasion of privacy. It is awful. But, I think it's better that this information be openly discussed by the tech community rather than hiding our heads in the sand.

That's an interesting take. But I fear the day the business types get hold of the idea. And the shady types. Oh boy.

I think it's too late to put history scraping back into Pandora's box. There are several articles on it already out there. Those who are less scrupulous already have all the information they need.

At this point, I think the best that can be done is to make people aware of the practice. No browser should leak history by default. It's a huge security vulnerability, and should be regarded as such. Start putting pressure on Mozilla, Google, MS et al to fix it.

To be clear, I am only advocating the self-censorship of this information until the browsers you mention have had a chance to fix it and people up grade.

I guess really you just gotta delete your history all the time. Or make history links only work for the domain. If you see a link in a page that is not on the domain where the page originates, then make it the same color as the unvisited links.

I just hunted around for a bit, and found a few possibilities. Now all we need is User Javascript that can run before the site loads, in all browsers, and we're golden :) User Javascript strikes me as more likely to be implemented than anything specific to this problem.

http://news.ycombinator.com/item?id=1139172

w00t. For any who are interested, Opera and Chrome have the capability of having "user javascript" that runs before the website begins loading, which allows secure objects to prevent things like this. Nothing built-in for IE / Safari / Firefox, from what I can tell. Greasemonkey loads after the page is done, so it can't guarantee this sort of thing is blocked.

In Chrome (dev only, currently, and weird / lacking the ability to manage them after install), use a "// @run-at document-start" line in your script: http://dev.chromium.org/developers/design-documents/user-scr...

In Opera, it looks like it always runs them first: http://www.opera.com/browser/tutorials/userjs/

And the important piece, something which can block this kind of probe, Caja: http://code.google.com/p/google-caja/

Obviously other possibilities exist, and this will likely need tweaking, but it's a solid start. If nothing else, it reads as a fairly simple how-to to make your own leaner version if you just want to target this.

Interesting... that's a clever way of scraping data.

Rather simple proposal for a fix: don't allow JS to read the :visited pseudo-class. I've yet to see anything use it cleverly anyway (though I fully admit this does not mean it cannot be used cleverly).

Personally, I'd just disable it by default / have a setting somewhere to always return "false" to that query, and I'd like a prompt to enable it for scripts as desired (sha-1 the js on a site, and remember permitted ones. Auto-breaks when changed). Ideally, it'd be nice to allow / block based on current-domain too. Prompts are a bad idea for most people, though.

Anyone know if doing this would be possible on browsers right now? I don't know what the APIs allow.

Reply on news.ycombinator.com