Sniff browser history for improved user experience | Hacker News Reader

Sniff browser history for improved user experience

niallkennedy.com

22 pointsskorks12 comments

Respectfully, this is a batshit crazy idea. History sniffing is a gaping security flaw. The thing we need to do with it is eliminate it. What we don't need to do is arm unscrupulous developers with arguments for why the behavior should be protected.

In this post I will teach you how to mine the rich treasure trove of personalization data sitting inside your visitor's browser history for deep personalization experiences.

There is no discussion of the privacy issues, which seems like a huge omission. I wouldn't use this on a website unless you like playing with fire.

He mentions it (very) briefly with the Audi example. But yeah, this is a bit terrifying. I hadn't thought about this trick before now, and I don't see how you could easily turn it off...

See http://news.ycombinator.com/item?id=800693 and associated link.

Summary: To mitigate, either (a) tell your browser not to save any history, or (b) in Firefox, go to about:config and turn off layout.css.visited_links_enabled. (Chrome doesn't seem to have about:config ...)

This should probably be the default ...

Agreed about making that the default.

Another workable approach are keeping a full history graph, and only showing visited links on the site where you originally clicked on them.

Or, the browser could highlight visited links in a way that can't be detected with JavaScript code.

This isn't hard to fix, so obviously we just haven't been complaining loud enough.

Here is an example using history sniffing to guess the gender of a website visitor.

http://www.mikeonads.com/2008/07/13/using-your-browser-url-h...

Heh; funnily enough, that scanner thinks I'm female...

People have been using this technique in this way since at least 2006: http://int2e.com/blog/improved-digg-integration-script/ http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-yo...

Since changing browsers to prevent this will not happen tomorrow, this can be partially worked around both server and client-side.

Server-side: If you have any sensitive URIs you don't want leaked or brute-forced, add an extra parameter containing a random value. URIs you might want to protect are those with XSRF tokens or session IDs. URIs can be brute-forced locally on the victim at a speed of approximately 40,000 URIs per second.

Client-side: Use incognito mode for sensitive surfing. Plugins such as noscript can partially defend against this, however it's possible to do history detection using pure CSS which I believe will work even if you're using noscript. Update: Fixnum posted another client-side solution "in Firefox, go to about:config and turn off layout.css.visited_links_enabled"

It was just a matter of time before the CSS history trick was put to use. I can see the benefits, though I don't like the privacy implications.

History trick here (JS, no cookies, can poll user's web history): http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-yo...

Niall wrote about this in 2008 (see post/url of post), and there have been several interesting write ups about this across the various outlets.

I'm pretty sure it's beeing used in loads of places by now - there's probably (/should be) a jQuery plugin for it, even.

I'm wondering why this is making it to HN now, 2 years later?

there's probably (/should be) a jQuery plugin for it, even

No, there shouldn't. Taking advantage of this design flaw is no better than trying to send a Javascript exploit to read my history file directly. I'm surprised that supposedly legitimate sites think using it is an acceptable practice, but I guess I shouldn't be.

Please, don't do that.

Reply on news.ycombinator.com