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

[mTor]

Exactly. That's why I use NoScript... and everyone else should too! Get it and you'll eliminate all kinds of attacks.

Re:Pretty clever..

[TheLink]

It'll be useless.

But do a search on "Timing attacks on Web privacy".

ALSO, I don't think you even need to use timing attacks because a browser that caches that has stuff cached will behave differently from a browser that caches but doesn't have stuff cached. Pretty obvious isn't it?

There is no way around that except to use a browser that doesn't cache at all - which will affect browsing performance. For slightly less privacy you can use a browser that always starts in the same state for each browsing session.

AND even if you use such a browser, if you have a distinctive browsing pattern and fingerprint, people could still identify you.

e.g. you use a noncaching, no-js browser, with a fake User-Agent (says it's IE but behaves like Firefox), and you start browsing with a particular site first at a certain time followed by another site etc - or you load a particular bunch of sites in the morning (opened in tabs). Could get quite distinctive ;).

But there are far more important things that people should be worried about. What their government is doing for instance.

Re:Pretty clever..

[baadger]

Another approach to try and prevent this might be to get the browser not to send conditional GET requests *at all* and to just reload silently from cache.

This however would of course mean that everyone has to make sure their webpages are properly cache able with reasonable (perhaps dynamically generated) expiry dates.

The nature of HTTP and the web make it very difficult to remain totally untrackable all you can really do is prevent the worst of it.

Seems a bit paranoid

[Anonymous Coward]

Regarding Sourceforge/Google. Did he consider that Google's automated email may have gone to sourceforge alias which was then forwarded to his email address?

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: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: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

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

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:An interesting idea

[shird]

Except IE6+ has a default setup to block cookies from being set by sites other than the one you are on, cross domain cookies or whatever theyre called. ie. banner ads that set cookies etc.

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.

This would help (Firefox users)

[Wartburg]

Stealther is a Firefox extension which temporarily blocks history, cookies as well as referrer header.