Tracking Menaces for Your Privacy

Avatar von Martin Brotzeller

A lot of people are talking about a particular research paper featured by Wired of late. That paper describes, how users can be, and are, tracked against their express wish. Even deleting cookies does not solve the tracking problem. A lot of folks talk about how unethical, probably unlawful and unfair it is.

So far, although, I have not seen a site that gives more than hints how to prevent being tracked. Firefox users have a couple of tools at hand that can easily circumvent most, if not all, attack vectors. Using these measures comes at the cost of comfort, though.

The paper describes tracking through persistent cookies, that store the user identification in various places on your computer to recreate that information everywhere you have deleted it by clearing your cache, deleting your cookies, etc. The tracking, KISSmetrics, has been found on large sites like Amazon or Hulu. One of the researchers emphasized, according to Wired, that not even private-browsing in Firefox prevents you from being watched. This is not surprising, as you will see.

First of all, let’s have a look at the various methods of identifying a user incorporated by Evercookie, a very persistent cookie – KISSmetrics admitted publicly to use these methods:

HTTP cookies
This is a basic measure, everyone on the web should have heard of them. They store up to 4 kB of data, and can rather easily be seen and deleted, even modified. One usually can’t go without, else shopping online could be tedious or plain impossible
Flash cookies a.k.a. LSO (local shared objects)
This is the flash pendant to HTTP cookies, storing from 100 kB up to 10 MB if the user agrees. Adobe recommends them for comfortable storage, and discourages use of them for tracking purposes (although apparently it’s just a plea). Most important, these are shared between all browsers using the flash plugin
Silverlight cookies, or Isolated Storage
Microsofts answer to flash cookies. These can not only store key/value pairs, but offer support for a file system.
Internet Explorer userData storage
IE scripts have another mechanism for storing of objects. The userData storage can be filled by XML elements, HTML tags or scripting. Storage depends on the security zone. Retrieval is done via scripting. Is no longer supported, starting with IE 9
HTML 5 Storage
HTML 5 offers a couple of storage mechanisms (session, local, global, database), all are filled and retrieved via scripting.
Window.name caching
Modern browsers offer up to 32 MB of space in the window.name property. This can be used across domains, although there are some problems with tabbed browsing.
Web cache storage
When a server-side script generates a client-side script using data from e.g. a cookie, by forcing the browser to cache that script, the server can later recreate a deleted cookie by running a script with user-specific data from the browser’s cache.
Web history caching
It gets even more complicated. Scripts can insert URLs into the browser history. By storing all prefixes of a string into the browser history, a script can retrieve a piece of data via CSS history knocking. This is faster than it sounds, because no actual web requests are neccessary for that.
Storing information in autogenerated images
This is clearly an indication that a website tries to hide information from you. Information can be encoded into RGB values of an autogenerated image and be retrieved by reading the data from a HTML canvas later.
Storing information in Etags
An Etag is normally a way to ensure ressources are only retrieved if they are not up-to-date when the creator could not tell the expiration date beforehand. A browser sees that a web page needs a script, looks up if it has a cache hit. The browser then sends the request for the script along with the Etag from the cache. If the script is still up-to-date, the server sends back a 304 Not Modified, else it sends the latest version of the file. Trackers use this mechanism to get an Etag from the browser cache that they put there before by generating an individual Etag for each user.

 

So this leaves us with a couple of means by which we users are tracked:

  • Cookies
  • Stored objects by Flash and Silverlight
  • Images
  • Scripting
  • Cached Files

 

Bruce Schneier already ignited a discussion on counter-measures in 2010.
To be completely on the safe side would require a lot of work. You would need to deny all cookies except those you knew you needed and trusted. The same would apply to Flash and Silverlight. Since autogenerated images can’t be discerned from normal ones, and no automatic way for deciding which files to cache is possible, you’d need to disable caching altogether, plus you’d need to turn javascript off. Since that is not really the web experience we’re used to, that is a bit unrealistic – especially when you’re a web developer and need to see sites the way your customer sees them. So what can you do to at least reduce the amount of tracking without losing the usual web experience?

Ghostery
This is a easy to use, unobstrusive addon that keeps a list of tracking services. It offers to block Images, Flash, Silverlight and scripts from the known domains. You can choose which trackers to block and which to allow. You can have a bubble after loading a webpage that shows you the trackers it found. Apart from that, it does not bother you in any way.
NoScript
This is a more sophisticated, but also less convenient way of protecting yourself. Each domain can be allowed, blocked or temporarily allowed. You can choose to block any of the above things plus some more like loading iframes or fonts. It even has a builtin mechanism to block cross site scripting attacks called application boundaries enforcer (ABE). Each blocked object on a webpage can be clicked on, so you can watch videos or play games, but dont have the flash ads that are shown on the webpage together with the content. If you block everything except the sites you trust, you can prevent all scripting attacks, although some sites may not work correctly. The downside is, it does not block images, and you can not decide to block scripts from a site on one page and allow the same scripts on another page (Facebook, for instance, watches you everywhere)
RequestPolicy
This addon fills the gap NoScript has. You can decide, which site is allowed to include ressources from which other sites. You can disallow images that have an origin other than that of the domain in your location bar. The downside, of course, is that it’s a lot of work until you have configured the plugin to completely show the pages you frequently visit.

Finally, there is a completely different approach to user identification from the EFF, called Panopticlick. It determines a browser via it’s detectable attributes like User Agent, HTTP_ACCEPT headers, installed plugins, cookie, font and scripting settings, timezone etc. Just activating NoScript yielded 13.22 bits of identifying information, letting the EFF know I share the same fingerprint with every 9527th browser user. ALlowing the site to run a javascript provides 20.69 bits of information instead, rendering my fingerprint unique among the almost 1.7 million configurations the database consists so far. EFF mentions NoScript along with TorButton as the two working privacy enhancing mechanisms they could detect.

 

The only thing that i have not found a decent addon so far, is the caching stuff. I guess this cannot reliably work without a service that keeps an up-to-date list of malicious sites/ressources/urls. Apart from that you wouldd probably have to stop caching everything that comes from a request that can be associated with your session, like when you sent a cookie. If anyone has hints or recommendations, i would be glad to have them here in the comments. Also, solution packages for other browsers would be nice to know.

Avatar von Martin Brotzeller

Kommentare

Eine Antwort zu „Tracking Menaces for Your Privacy“

  1. Slashdot reports, that CSS History Sniffing is back – this time utilizing the latency that your browser shows when you have visited a site already. The time a browser takes to respond differs when the resource that is linked in a page is already in the br

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.