Tracking Users Via the Browser's Cache

Mukund writes to point us to an article he has written about a method of tracking using the browser cache instead of cookies. A demonstration shows that tracking can remain continuous if you clear only cookies or only the cache, but not both. (Firefox's Clear Private Data tool can be set to clear both when closing the browser.)

Comments

Pretty clever..

[CTho9305]

For those of you who aren't going to RTFA, basically you send a JS file with a unique ID and tell the browser to cache it... then any page that includes that JS script gets your unique ID... even if you disallow all cookies.

Re:Pretty clever..

[MarkRose]

Well if anyone tosses their cookies in my java, I, for one, am sure not going to drink it!

Re:Pretty clever..

[Breakfast Pants]

Sure, but they could just put a small iframe to foo.html and mark that page as cacheable, on that page have a small image, dynamically generated, to [unique_id].gif and mark the image uncacheable on your server. Now when you visit, your cached copy of foo.html tries to download [unique_id].gif every visit.

NoScript Extension

[rdwald]

Saved by NoScript again. If you're not using it, you really should; it can block exploits before anyone knows they exist! (Since they may require JavaScript, and this would block them. My statement is strictly true.)

Re:Seems a bit paranoid

[chrisd]

That is indeed what we do, send the confirmation email to the blah@sourceforge.net alias. We do -not- have the translated email addresses and thus the only information we are using is that which is displayed on the project home on SF.

Re:Serious question

[Feyr]

a couple of days, then it usually crash/get so slow it's unuseable and i have to restart it

Old news

[christo]

Move on folks, there's nothing to see here.

This was done last year, by these guys: Browser Recon @ Indiana University

Defenses against this, and other attacks have been created and deployed through two firefox extensions
put out by Stanford University: Safe History and Safe Cache

This stuff ain't new.

Re:Old news

[The MAZZTer]

Wow that's even scarier than this one in the story. Yours only needs CSS.

It stems from the whole idea of marking links "visited". CSS attributes can be applied to visited links to set them apart from unvisited ones. The page in your example uses CSS to tell the browser to request a page from the server if a link is visited. This page, when loaded, knows that the load means you visited the website in the link.

The worst thing is that this is a perfectly legitimate use of CSS by current w3 standards. A preventive measure for browser vendors may be to not allow any external resources to be used in :visited CSS.

Re:Seems a bit paranoid

[mukund]

Hi Chris

I did receive the email on my sourceforge.net address. My problem was not with which email address I received the mail at. I don't see why I have to be contacted for a Google service, when my subscription is with Sourceforge.net.

Don't take this the wrong way. I have used Google services for a very long time, but I think this is a bad precedent. Picking up an email address in an automated way from a website and mailing me about your services, when I haven't asked for it is as good as what a spammer would do. And the email suggested you had a table of projects, which made me assume Sourceforge shared this with you. If Sourceforge.net didn't and you can attest that I'll edit out that part of my article (I would not want to blame Sourceforge for something that they didn't do).

To the parent poster: This may seem paranoid.. some other poster suggested the same to the other Canonical-Debian issue too (on the other blog). When something is not right, it simply needs to be questioned. That's all.

Kind regards,
Mukund

Re:Requires Javascript to work.

[misleb]

That's OK because the browsing habits of the type of people who turn off Javascript are not particularly interesting anyway. So it all works out.

-matthew

Re:Um, no

[eurleif]

That's all well and good if you your goal is for the user to track himself, but how is the server going to get an image out of the cache?

Re:Um, no

[_xeno_]

Doesn't have to. Just have them cache the image using a unique timestamp for Last-Modified (so that you should get a unique If-Modified-Since header) or using a unique ETag. Both should theoretically work to uniquely identify the user, and both can easily be embedded using an image. Combined with Cache-Control: private, this should even work through firewalls.

Re:Seems a bit paranoid

[rossturk]

Mukund:

We provided Google with a list of registered project names on SourceForge.net to allow future integration between the open-source repositories with minimized namespace conflicts.

The email you saw, if I am not mistaken, was generated when someone tried to create a project at Google with the same name as a SF.net project you belong to.

Unless I am very mistaken about Google's intentions (and I don't think I am), your email address was not picked in an automated way. It was a direct result of an action that was relevent to you, specifically. That may or may not make it seem any better to you, but I don't find it particularly nefarious. Rather, I think it's good that Google and SourceForge are working together to protect your interests..

Ross Turk
SourceForge.net