Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Facebook

GameboyRMH's Journal: Facebook's pure HTML tracking system 22

Journal by GameboyRMH

So, thought you were safe from all the tracking systems out there with your browser locked down like Fort Knox? You've got your scripts, cookies, Flash objects & storage all working on a whitelist system, your browser's geolocation API disabled, and maybe even more. And all the tracking & analytics systems out there rely on Javascript and those other "higher functions," right?

Not really. Facebook's doing it old school. It's a long story you can read here, but a peculiar effect caused by my menagerie of security plugins brought my attention to a new form of tracking that Facebook's been using over (at least) roughly the last week. In a Wired.com page, I found that Facebook is using a small iframe that fetches a page with a URL such as:

http://www.facebook.com/widgets/like.php?href=http://www.wired.com/autopia/2011/08/no-public-transit-no-job/&layout=button_count&show_faces=false

In this case the basic URL of the page this was found on being http://www.wired.com/autopia/2011/08/no-public-transit-no-job/

This iframe actually renders the Like button.

This form of tracking will work with the most basic of browsers with all client-side scripting/application systems and web-facing APIs disabled. Upon doing more research I found that Lynx is actually safe as it doesn't display frame contents, but rather converts them into hyperlinks.

From this tracking iframe Facebook can get, at a bare minimum, the following info:

- The page you've just viewed
- Your IP address
- Your browser agent info (which, by default, contains far more detail than you might think - right down to your machine's CPU architecture).

It should also be possible, on a permissive browser, to use cookies, run Javascript from this iframe (which it does include) to get access to much of the info shown in the Panopticlick project, access HTML5 storage, Flash storage, and the geolocation API.

The only surefire way to block it would be to blacklist all connections to any Facebook domains - and the domains of any other tracking services that deploy similar systems in the future.

I was considering posting this to Slashdot's firehose but some more research has shown that Facebook has been offering at least some sort of iframe method for inserting Like buttons since at least April 2010, so I'll just post to my journal for now rather than potentially making a fool of myself.

This discussion has been archived. No new comments can be posted.

Facebook's pure HTML tracking system

Comments Filter:
  • Note that disabling frames will not fix this; such a widget can gather information just as easily when loaded as an image or other resource - even inside a CSS property ("background-image:url(http://evil/tracker")) which will be evaluated even with the browser in full-on no-scripting mode. The browser is designed to automatically fetch resources when told to do so by a website, regardless of where that resource might be or what information you will transmit simply by requesting it.

    Using something like AdBlo

    • It should also be possible to block all cross-site requests (loading resources from domain A while on a page from domain B), but that will make all large websites that use CDN basically unusable.

      A plugin called RequestPolicy allows cross-site requests to be put under a whitelist policy, but as you said that will break any sites that use CDNs.

      • No, it will not break them. It will only require that you explicitly enable the site to access the cdn address. Since the cdn URLs are easy to identify (and you'll immediately notice that something is not working without them), it's easy to enable them.

        • True, but that's a pretty big inconvenience to block a handful of tracking services. That's just my opinion on the security/convenience tradeoff, from a purely technical standpoint RequestPolicy is actually the best solution.

          Still, if half the sites out there worked like the Gawker sites, and there were only a few malicious/anti-privacy uses of JS in the wild, I probably wouldn't have my JS on a whitelist system.

    • Here's a filter subscription for AdBlock [techairlines.com] to filter out some social media sharing buttons. Just found it via a quick google search. Seems to work for the most part so far. The main Facebook (etc.) sites work, but just the individual cross-site trackers are blocked.

  • NoScript can block iframes, if you tell it so ;-)

    iframes that were blocked appear as dim-yellow areas. You then need to click the blocked iframe to enable it.

    • Ah yes I see it under the Embeddings options. Interesting feature!

      It looks like the best solution will be RequestPolicy with its new blacklist mode which is due to be released in the next few months. Or you could use it right now in whitelist mode, if you're up to the extra effort.

Stinginess with privileges is kindness in disguise. -- Guide to VAX/VMS Security, Sep. 1984

Working...