What is Digg?49 Comments
- mcherm, on 10/12/2007, -0/+18This is VERY good (well, very evil). The trick (for those too lazy to read the article) is to use javascript to look for the the effect of applying :visited pseudoclass to links (turning them a different color or changing the height/computedHeight ratio) thus allowing one site to spy on whether you have visited other sites.
In an interesting take on "all bugs are shallow for open source code", "Chris Wood" comments in the blog that this was reported as a potential bug in Firefox as early as 2002 (http://forums.mozillazine.org/viewtopic.php?t=300080). The moral, I suppose, is that just because a bug is visible doesn't mean it gets fixed.
Expect this to be abused by unscrupulous sites. I, for instance, can think of an immediate application in the field of porn (not that I'd know anything about it) where sites have no need to worry about damaging their reputation and they OFTEN want to know where a visitor has been recently (and it's often from a fairly well-known list of likely referrers).
To avoid being spied on, consider disabling labels:
in Firefox: Tools > Options > Privacy > History > set to 0 days
in IE: Tools > Options > General > set days to keep to 0
...and I'm not sure what other browsers this may affect. - digggroupie, on 10/12/2007, -0/+10This website says they have it working. http://gemal.dk/browserspy/css.html
View source to see the javascript! - merreborn, on 10/12/2007, -1/+9I think it's the fact that the link is :visited, not that it's changed color.
- merreborn, on 10/12/2007, -1/+7That's easier said than done. There's a reason popup blocking *still* hasn't been perfected. For every piece of javascript you add to the list of "bad JS", someone can just code the exact same thing in a slightly different way.
- FlaG8r, on 10/12/2007, -3/+9You can say that again.
- phatvolvo, on 10/12/2007, -3/+9http://digg.com/gadgets/Schools_Banning_Cell_phones
wrong story, pal. move along. - merreborn, on 10/12/2007, -1/+6It'd make a hell of a lot more sense to do that on the server side. (and people have been, for years)
- UrlorJkron, on 10/12/2007, -0/+5I just use the NoScript extension. I pick and choose what sites I'll let run any javascript. IE users can do the same using the built in "zones."
- arkmtech, on 10/12/2007, -0/+5The concept is fun - but with no data to log, and the fact that it only works with modern standards-compliant browsers (IE6 simply gives up - http://www.buttebass.org/k_pryde/suckage.png ) it's unfortunately not practical.
Reminiscent of the days when setting an IFRAME or DIV's source to "c:" made users panic about the contents of their hard drives being available to the web, this will likely become a new way to propagate spyware by conning users in believing their systems are insecure. :(
And maybe I've just got an evil mind... - Skeuomorph, on 10/12/2007, -0/+4Yeah, following "mcherm" link eventually you find the first bug report seems to be on 19th Oct 2000:
https://bugzilla.mozilla.org/show_bug.cgi?id=57351
Best discussion at https://bugzilla.mozilla.org/show_bug.cgi?id=147777 which goes into why trying to block accessing the property is a losing battle. As some suggest in this discussion, just don't set visited property in the first place. Others suggest disable history or set to 0, but a Prefs GUI checkbox disabling history based styling seems less drastic while equally effective.
But as long as XMLHTTP (oooo, AJAX keyword, oh noes!) is with us [or even image loads], and as long as browsers cache things, and as long as we can time loading URLs, you can check if competitor web object is in visitor browser cache.
Don't need CSS if you've got Javascript, and don't need Javascript if you've got CSS. - delta013, on 10/12/2007, -2/+6Someone needs to write a firefox extension that can detect this code in web pages and alert the user.
- astatine, on 10/12/2007, -1/+5Would a Greasemonkey script that sets all :visited links to the default link colour cover this security hole?
- FlaG8r, on 10/12/2007, -1/+4You guys are wrong. Re-read the article. They use the style assigned to visited links to determine which ones have been visited. It's the style that matters.
- seventoes, on 10/12/2007, -1/+4No, The script looks for links with the :visited class. Changing the color of the link wont remove that class, it would just make it a different color.
- TheReport, on 10/12/2007, -1/+4for all you safari users, Private browsing is a simple yet effective tool that helps reduce your chances of being tracked.
- bilbus, on 10/12/2007, -1/+3All it did for my IE was popup an error and close page :P
- inactive, on 10/12/2007, -0/+2Link to the original blog post
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html - chewbaka, on 10/12/2007, -0/+2For the paranoid: a firefox extension that not only prevents this exploit, but fixes the underlying problem (lax "same-origin" policy).
http://crypto.stanford.edu/sameorigin/
I *believe* this exploit doesn't work in Opera
IE users, u're on ur own. - gambl0r, on 10/12/2007, -1/+3You're missing the point. With this you can see if a user has been to a page that you specify without tracking outgoing links from your site. What you said is commonly used all over the web, but for a different purpose.
This "new" way is not very useful - just an example of a cool CSS/Javascript 'hack'. - Skeuomorph, on 10/12/2007, -0/+1Btw, the GUI link to disable styling of visible links should go in the same section of prefs as Cookies's "[_] For the original site only". This should say "History privacy": "[X] Show visited links as styled", "[_] For the original site only", then the web can go on working for most people, but safe for those who have concerns.
A lot of these (off-site cookies, third party images, gifs in emails) can be used for evil and caused uproars, but now are right there in the browser as prefs. In reality, the spammers and evildoers generally don't use them. It costs a ton of money to crunch data for high volume sites, so any of these types of information tend to only used by sites trying to figure out how to make themselves or their marketing more appealing to you. - krinthekuz, on 09/16/2008, -0/+1bleh no idea why it double posted.
@gambl0r: i totally understand what you're saying.. that it SHOULD check the ::visited tag, but as i demonstrated with my examples, it doesnt work on my default installation of firefox. the effect that it did apparently create on my default installation was exactly what my PoC outlined. unless i click on the link from their site, it doesn't register as me having visited there, and if im clicking on the link on their site, they might as well use a method similar to mine
and yes i'm full aware that my method is the basic concept of most ad referrer systems. i have nothing against the author... except this bug is not present/exploitable on my machine - Rolleyes, on 10/12/2007, -0/+1Just another way for websites to track you more, but can easily be avoided with some common sense.
- stormwater, on 10/12/2007, -0/+1@FlaG8r: Aaaaaaah. You don't need AJAX for that you moron.
- inactive, on 10/12/2007, -2/+3Interesting!
- Tijmen, on 10/12/2007, -1/+2Well, who'll be the first one to combine this thing with the AOL dataset? :) (That would be a crazy large JS btw)
- reverb, on 10/12/2007, -0/+1My Safari is up to date -- version 2.0.4 (419.3) -- and it doesn't seem to work in mine.
- keesj, on 10/12/2007, -0/+1Works in Safari 2.0
- Skeuomorph, on 10/12/2007, -0/+1We have used a very similar technique since 2003 to help clients know which of their competitors' sites are in a visitor's history. Yes, since 2003.
This has worked since then, and longer. There have been occasional papers and occasional examples posted every year, but it seems to be one of those things that is "by design". We've been amazed it (a) wasn't widely reported and (b) wasn't addressed with a GUI privacy option to disable history-styled links [trying to prevent disclosure through blocking the reading of styled side effects is a no-win battle].
(We independently discovered the technique while trying to determine alternative methods for storing/retrieving information to/from a browser without using cookies. This method works for that as well. Once we discovered it, we knew what to search for, and found that it was known.)
// just noticed mcherm confirms 2002 - rprins, on 10/12/2007, -0/+1Well, there's a reason people use JavaScript. It is way more robust than server side logs. Will server side logs tell you where a user clicked on a page (even if it wasn't a link)? Will it tell you where they hover their mouse? Will it tell you how far a user scrolls down a page?
E-Commerce sites have been using this JavaScript technique (albeit much more robust) for several years. Some comapnies that do this are Avenuea|Razorfish and Atlas. Companies loose millions of dollars to bad form design and site design and this javascript can help them see where users are abandonding a page. If they can see where they can fix it and hopefully that will lead to more conversions and more revenue.
So, really, this is nothing new, it's just becoming more publically available as it never has before. Whether you like it or not, some of the sites you visit probably already track you without you knowing. - samuella, on 09/08/2008, -0/+0JS gives you chance to make your website much more powerful.
http://www.shannonbrookeimagery.com
http://www.wmpowered.com
http://sooslic.com/?id=523
http://search.ashtech.info/programming
http://www.mkzine.com - FlaG8r, on 10/12/2007, -2/+2As noted in the article, the limitation is that you can only look for sites that you have in a list. You can't find every site a user has visited.
- yenta4shop, on 09/07/2008, -0/+0http://www.yenta4shop.co.uk/
http://astore.amazon.com/12.volt.battery.charger-2 ...
http://astore.amazon.com/5.gallon.water.bottle-20
http://astore.amazon.com/aerobed.raised-20
http://astore.amazon.com/bug.zapper-20
http://astore.amazon.com/flowtron.insect.killer-20
http://astore.amazon.com/furniture.chaise.lounge-2 ...
http://astore.amazon.com/inflatable.bed-20
http://astore.amazon.com/steam.cleaner.mop-20 - diggwebq, on 03/17/2009, -0/+0Not that Javascript and this exploit are particularily suited for this, but I was thinking about tracking key portions of the site you would like the user to eventually find their way to. If the user has been coming for a bit and hasn't visited a mentionable area, generate a little, "Hey, we have other cool stuff, too!" content and link them to it. Or use server-side ***** I guess. I can't tell if this is a good idea or not :|
http://www.zestrx.com/product/viagra-professional. ... - Robotsu, on 10/12/2007, -6/+6I guess I'm the only one who thought of a totally none-evil way to use it :(
Not that Javascript and this exploit are particularily suited for this, but I was thinking about tracking key portions of the site you would like the user to eventually find their way to. If the user has been coming for a bit and hasn't visited a mentionable area, generate a little, "Hey, we have other cool stuff, too!" content and link them to it. Or use server-side ***** I guess. I can't tell if this is a good idea or not :| - drater2, on 10/12/2007, -0/+0No Javascript is required to make this work. CSS by using background: url() with the URL of some tracking script is enough.
- kevgig, on 10/12/2007, -1/+1This is kick azz, even if it is a repost. It is the first time I have seen this.
Thanks for the post!
So many ideas, so little time :) - Toiling, on 10/12/2007, -2/+1neat yet unpractical in actual real world applications. It's more like a 'wow cool dude' type thing. digg nonetheless for creative use of looking at the style of links.
- geocar, on 10/12/2007, -2/+1No, your example can detect whether they clicked a link off your site to another page.
The target tell if your browser would display that link differently (by honoring the :visited css). - mike503, on 10/12/2007, -2/+1i didn't think of this as an "evil" way to capture where people have been when i thought of it at first. it can also be useful for reporting/analytics. it could almost create a "clickmap" or "hotspots" or whatever it's called to determine what links people actually click on your site. it can be used for good, too...
(obviously if it worked in all browsers, blahblah - standard disclaimer) - FlaG8r, on 10/12/2007, -3/+2Yeah, unless they bring Javascript in via AJAX and exec it to change the style to what they want.
- Robotsu, on 10/12/2007, -4/+2You're right, server side makes more sense.
"(and people have been, for years)", like? Cite that *****. - Bladerunnerx, on 10/12/2007, -3/+1Hmm I'm using firefox and www.google.com (my homepage) was the only link shown. I surfed at least 10 sites prior to arriving at his blog page.
- spectrox, on 10/12/2007, -4/+2after going to sensitive sites, just purge your cache/histry and restart your browser.. Why is the new news?
- looksliketrent, on 10/12/2007, -5/+2Excuse me?
- krinthekuz, on 09/16/2008, -5/+1this exploit is kinda silly. from testing on the site that has the "working" version, it could only detect when i clicked directly on their link to the site.
-- it did not see that i had been to google lately (i was there a few min before reading this on digg)
-- it did not detect when i went to their site, typed ebay.com in my address bar. then pasted their link back in the address bar, and ctrl F5 (to force an uncached refresh)
-- it did detect when i clicked the link on their site directly to ebay.com
and i have the default privacy settings in ff1.5, no special js blockers or anything. duplicating this behavior with php would be real easy, and there's nothing the visitor could do about it (they could mitigate by blocking cookies, but not block it). here's a rough proof of concept
-- all external links on a site go to e.php?l=whateversite.com/somepage.html
-- the e.php site sets an identifier cookie. the identifier is stored in a db, and $_GET[l] is stored also. this is where the visitor could mitigate. a visitor could block the cookie, and then the site could go off IP. even though the IP wouldnt be as accurate, it's still better than nothing.
-- after storing the identifier and the link, the e.php file does a header("Location: $_GET[l]"); obviously, you'd want to make sure that $_GET[l] doesnt have .. in it so they cant try and break out of webroot.
-- if you wanted to conceal the http://www.yoursite.com/e.php?l= in the status bar, you could use js to change the bar to the address on mouseover (but this would be removable by turning js off).
either way, this is not that impressive if u ask me, and my implementation probably takes a LOT less code. - Muzztein, on 10/12/2007, -8/+3this is old ...clever... but old... like the wheel.
- ipodchicken, on 10/12/2007, -11/+1Who is a 15 year old going to call during school hours anyway? There friends...thats smart.
- krinthekuz, on 09/16/2008, -11/+1this exploit is kinda silly. from testing on the site that has the "working" version, it could only detect when i clicked directly on their link to the site.
-- it did not see that i had been to google lately (i was there a few min before reading this on digg)
-- it did not detect when i went to their site, typed ebay.com in my address bar. then pasted their link back in the address bar, and ctrl F5 (to force an uncached refresh)
-- it did detect when i clicked the link on their site directly to ebay.com
and i have the default privacy settings in ff1.5, no special js blockers or anything. duplicating this behavior with php would be real easy, and there's nothing the visitor could do about it (they could mitigate by blocking cookies, but not block it). here's a rough proof of concept
-- all external links on a site go to e.php?l=whateversite.com/somepage.html
-- the e.php site sets an identifier cookie. the identifier is stored in a db, and $_GET[l] is stored also. this is where the visitor could mitigate. a visitor could block the cookie, and then the site could go off IP. even though the IP wouldnt be as accurate, it's still better than nothing.
-- after storing the identifier and the link, the e.php file does a header("Location: $_GET[l]"); obviously, you'd want to make sure that $_GET[l] doesnt have .. in it so they cant try and break out of webroot.
-- if you wanted to conceal the http://www.yoursite.com/e.php?l= in the status bar, you could use js to change the bar to the address on mouseover (but this would be removable by turning js off).
either way, this is not that impressive if u ask me, and my implementation probably takes a LOT less code.
© Digg Inc. 2009
— Content created and posted by Digg users is 