Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Privacy

Sniffing Browser History Without Javascript 216

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)."
This discussion has been archived. No new comments can be posted.

Sniffing Browser History Without Javascript

Comments Filter:
  • by slarrg ( 931336 ) on Saturday June 13, 2009 @07:36PM (#28323667)
    You can't tell what sites I've been to if it's Slashdotted!
  • Old stuff (Score:5, Informative)

    by kasot ( 1274250 ) on Saturday June 13, 2009 @07:37PM (#28323679)
    The CSS history hack has been known since (at least) August 2006: http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html [blogspot.com]
    • Re:Old stuff (Score:4, Informative)

      by Anonymous Coward on Saturday June 13, 2009 @08:20PM (#28323873)

      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.)

    • Re:Old stuff (Score:5, Informative)

      by zmooc ( 33175 ) <zmooc@zmooc.DEGASnet minus painter> on Saturday June 13, 2009 @08:33PM (#28323947) Homepage

      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

      • Re:Old stuff (Score:5, Informative)

        by glodime ( 1015179 ) <eric@glodime.com> on Saturday June 13, 2009 @10:21PM (#28324335) Homepage

        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.

        • Re:Old stuff (Score:5, Insightful)

          by eiMichael ( 1526385 ) on Sunday June 14, 2009 @02:37AM (#28325181)
          Just make "visited" only apply within that domain, like a bastardized cookie. I don't care that us.gov knows which other us.gov links I've been to, but I don't want my browser reporting that I've also been to al-quada.org.
          • Re:Old stuff (Score:5, Interesting)

            by Philip_the_physicist ( 1536015 ) on Sunday June 14, 2009 @05:28AM (#28325613)
            Alternatively, make browsers download all the pseudoclasses for links, so that it is impossible for sites to use this to track users, but without removing the utility of having marked "visited" links. This could be done by browsers without needing any change to the standards, AFAICT.
            • Re: (Score:3, Interesting)

              by drinkypoo ( 153816 )

              This could be done by browsers without needing any change to the standards, AFAICT.

              It can't be done without generating a lot of unnecessary bandwidth, though, and harshing major on dialup users (who are already getting their asses kicked hard enough.)

              • Re:Old stuff (Score:4, Informative)

                by pavon ( 30274 ) on Sunday June 14, 2009 @11:48AM (#28327221)

                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.

          • That's ok. We don't need that hack anymore. This little social engineering of an article worked perfectly.

            Prepare for the party-van to arrive.

        • by zmooc ( 33175 )

          Gotta love the practice of marking older bugs as duplicates of newer ones...

    • Re: (Score:3, Interesting)

      by Blakey Rat ( 99501 )

      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)

        by Blakey Rat ( 99501 )

        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

  • by bcrowell ( 177657 ) on Saturday June 13, 2009 @07:40PM (#28323691) Homepage
    I'd care a lot more about this if NoScript was still a viable option. NoScript has become malware at this point. [wikipedia.org] The real issue is the need for someone more trustworthy to make a simpler, and more trustworthy replacement for NoScript. Please? Pretty please?
    • by Anonymous Coward on Saturday June 13, 2009 @08:03PM (#28323799)

      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!

      • Re: (Score:3, Informative)

        by mrmeval ( 662166 )

        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.

        • by Korin43 ( 881732 ) on Saturday June 13, 2009 @11:11PM (#28324541) Homepage
          Easylist blocks ads. Easylist blocked an ad on his site. How is this their fault? They are doing exactly what they say they do.
          • Basically from what I read easylist went above and beyond blocking ads on his website by actually changing the way html on his page was rendered in order to disable all forms of advertisement.

            They disabled everything but css and html basically putting his pages back to the early 90s in terms of functionality.

            The restrictions were so sever that it became actually impossible to download noscript if you were using easylist because it would remove the download links. This caused the author to have a HOLY CRAP T

            • Re: (Score:3, Insightful)

              by arose ( 644256 )

              Half apology, half counterattack.

              Most of his users want stuff blocked not look at his ads, they don't consider him or google special, why not white list all advertisers, not only his own? Not to mention the update mill and resulting page visits. If he could manage to not realize what the hell he was doing once (and I'm not sure I believe that, the default white list and updates had made me iffy even before the incident), he can do it again. I don't want to be there when that happens, not after opening adblo

    • It seems like it's been fixed [noscript.net].

      • by bcrowell ( 177657 ) on Saturday June 13, 2009 @08:33PM (#28323943) Homepage

        It seems like it's been fixed.

        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.

        • Re: (Score:3, Insightful)

          by Blue Stone ( 582566 )

          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

          • by VGPowerlord ( 621254 ) on Saturday June 13, 2009 @11:46PM (#28324703)

            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.

            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.

            • From what I hear, he only "apologized" and fixed the problem for several reasons: ...

              So what if he only fixed it because of public pressure? He fixed it, right? The public pressure is going to be around for as long as people use it, right? At least he's being held accountable to the users.

          • by supernova_hq ( 1014429 ) on Sunday June 14, 2009 @01:24AM (#28324959)
            Don't confuse forgiveness with trust.

            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..?
    • Comment removed (Score:5, Interesting)

      by account_deleted ( 4530225 ) on Saturday June 13, 2009 @09:51PM (#28324229)
      Comment removed based on user account deletion
    • by NimbleSquirrel ( 587564 ) on Saturday June 13, 2009 @11:20PM (#28324579)

      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.

      • Re: (Score:3, Interesting)

        by Barny ( 103770 )

        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).

      • Another privoxy user. =:^)

        FWIW, neither konqueror nor iceweasel/firefox responded to the detection page here. First, I had meta-refresh turned off on konqueror so I had to turn it back on, but when neither it nor iceweasel responded, I put two and two together...

        My strong preference is light text on a dark background, about opposite the scheme most of the web uses by default. What's worse, it's all too common for a site author to simply assume either a white background or black text, and set one without s

    • by arose ( 644256 )
      I've been happy with RequestPolicy [mozilla.org] so far. It's not a drop in replacement however. On the upside it blocks all cross site requests, not just javascript (was that an invisible 1x1 gif?), on the downside if you want a third party image to load you will also enable javascript from that party. You also can't block javascript from the site you are on, but that's what YesScript [mozilla.org]is for.
  • by noidentity ( 188756 ) on Saturday June 13, 2009 @07:44PM (#28323709)
    If the server responds

    Service Temporarily Unavailable

    The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

    then it means you've come from Slashdot.

  • Doesn't work on me (Score:3, Informative)

    by MrMista_B ( 891430 ) on Saturday June 13, 2009 @08:02PM (#28323793)

    Doesn't work on me - Firefox, with adblock plus, element hiding helper, and flashblock, running whatever the latest Ubuntu is.

  • Old, sure... (Score:4, Interesting)

    by sootman ( 158191 ) on Saturday June 13, 2009 @08:02PM (#28323795) Homepage Journal

    ... 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)

    by actionbastard ( 1206160 ) on Saturday June 13, 2009 @08:50PM (#28324015)
    From an exploit standpoint, no. From an editorial standpoint, yes.
  • Normally the browser won't load a CSS-defined external resource if it's not required, but in this case, for links it should load resources under :visited for any link, visited or not. This way this PoC would return visited for any random site, they really wouldn't get any useful data. However 1) it uses a bit more bandwidth fetching images that may not be used, although they are precached in the event the links do end up being clicked and 2) false positives on sites which use this for targeted ads etc mig

    • Re: (Score:3, Interesting)

      by Skapare ( 16644 )

      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).

      • The GP's solution doesn't break any functionality while at the same time making this exploit useless. If background images can be used to detect visit status, then just load them all regardless of visit status but still display them correctly to the user. The current implementation selectively loads only the ones that will get displayed, which is what makes this exploit possible. If queried via javascript (the other attack vector) always return the unvisited state.

        Everything still works 100% in that the

        • Trouble is, that would only protect against this particular exploit. All the while the :visited property can be probed by a site's CSS or javascript the possibility of new exploits remains. See my comment above [slashdot.org] for another solution.

      • 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).

        Or disallow transmission to webservers of data derived from browser-rendering?

      • You think a pop-up giving a warning difficult to understand by most users is good security practice? *Really*?

  • by Skapare ( 16644 ) on Saturday June 13, 2009 @09:18PM (#28324117) Homepage

    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:2, Insightful)

      by Anonymous Coward

      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.

      Script plz?

      This has been a pet peeve of mine for ages. I've got a bunch of users in a Windows environment without Cygwin, but I'd translate the shell script into D

      • by Skapare ( 16644 )

        The script is rather large because it has a lot of other customization in it.

        • The script is rather large because it has a lot of other customization in it.

          All the more reason to share it. I bet you find that there is a sizable audience for a tool like that, including all the extra customizations that sound like they fall under the same general principle of better user control over their own security.

    • by Minwee ( 522556 )

      Canadian zip code humor: http://tinyurl.com/V4G1N4 [tinyurl.com]

      That would be a lot funnier if Canada actually used zip codes. Or "humor". But at least you spelled the first word right.

    • That was supposed to be funny, right? I can't imagine anyone going to that much effort. Are you also running it in a virtual machine?

      Anyway... I scanned with it, and it found nothing. But since my browser has no history, maybe that's affecting it.

      • by Skapare ( 16644 )

        I wrote the script for many reasons. It customizes the browser on the fly, too. For example, it codes the process ID of the shell that parents it into the localnet IP address configured to connect to the proxy server with. That way I can track connections back to specific browser instances. It also puts the process ID into the default home page after "#". There are some other customizations, some controlled by environment variables. And it is not yet converted to FF 3 (error: out of space on todo plat

    • Re: (Score:3, Informative)

      by Blakey Rat ( 99501 )

      So... you posted just to brag about the extreme efforts you go to to support your irrational paranoia?

      Thanks, I guess?

  • There are several firefox plugins which limit and reduce your history.

    I don't think the NoScript fellows are specifically targeting anonymity, but rather simply choosing what actions (in a volatile world) can be executed.

    There exist a world of many more precautions to take for those who are worried about keeping their privacy.

  • For site that allowed user to post CSS content, and that's there is interest to steal the cookie, it could be done in the same way.
    For example, xanga.com (cookie to steal your login info), or Forum/BBS site that allows poisting CSS.

    The cookies will be sent along with the CSS background request.

    Blogger/Blogspot is a good example how this should be handled...just put it in two different domains.

  • I can disable JavaScript, Java, cookies, and password memorization. That's great. Now, please let me disable the most useless feature of all: iframes.

    Oh, wait... then web developers will inject 3rd party web code directly into the main document with AJAX, which is even worse.

  • Maybe one can use this site to their advantage. Obviously, the owners know something we know not - popularity of websites. If you can 'play' the browser at the user end, you can have a look into their database. See what they're searching for and how. It cuts both ways.

  • simple block (Score:3, Informative)

    by Anonymous Coward on Sunday June 14, 2009 @03:27AM (#28325303)

    putting the rule
    a:visited {
              background:none !important;
    in userContent.css seems to stop this particular scan.

I've noticed several design suggestions in your code.

Working...