/Tracking/Fingerprinting/passive/etag/

• $ fingerprint@info:~ echo $ETAG-FINGERPRINTING

• Name:

  ETag Fingerprinting
  

  Original feature purpose:

  The ETag HTTP response header is an identifier for a specific version of a resource. It allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. For more details see, e.g., MDN web docs

  
  

  FP-Explanation:

  The client sends a request to the server to receive a specific resource. The server sends back the requested resource together with the ETag, an arbitrarily choosen string by the server and - in case of tracking - a unique tracking ID. As specified in RFC 7232, the client, i.e. the browser, saves the resource together with the received ETag in the browser cache. As long as this data exists in the cache, each time a request for this resource is made, the client sends the corresponding, cached ETag to the server to ask for content changes.
  
  The difference between ETag tracking and the regular use-case of an ETag is the following:
  The server sends each client a different ETag, although the clients requested the same resource. In addition, the server may not inform the client, whether the content of a resource changed. For ETag tracking it is only important that the client automatically sends the ETag (tracking id) to the server.
  
  ETag Tracking, as a passive fingerprinting technique, only relies on a server-side scripting language and thus does not need any additional methods. This means tracking works notably without:
  

  • Cookies (Cookie deletion has no effect),
  • JavaScript (Works if JS is turned off),
  • Browser Storage (Without use of SessionStorage/LocalStorage/GlobalStorage),
  • User Agent and other identifier strings,
  • or any plugins.

  In this demo implementation, ETag tracking is realized without any additional files (pixel, regular images, ... ). The ETag is set for this website itself.

  
  

  FP-Type:

  passive
  

  FP-Categories:

  unchanged-consistent
  

  Counter-measures:

  
  

  ETag fingerpinting relies on the browser cache, which is for a default browser configuration persistent between browser restarts.

  • Automatically clear cache upon browser shutdown
    Problem: Tracking is still possible during the entire browser session
  
  
  • Disable cache at all time
    Problem: Caching advantages are discarded
    Info: Not only disk-cache, but also memory-cache must be disabled
  
  
  • Manually force website reload with cleared cache at will
    Info: Firefox-Shortcut ctrl+shift+r instead of ctrl+r for 'page reload'
    Problem: Limited effectivness, user-driven efficiency
  
  
  • Header Modification along with cache enabled
    Info: Remove all ETags from the response headers or remove all If-None-Match headers from the request headers.
    Problem: Requires the use of an additional addon, since it is, in general, not possible to modify the headers in the browser settings.
  
  

  Publications/References:

  • Martin Pool – Privacy problems with http cache-control (2000) (http://cert.uni-stuttgart.de)
  • Dean Gaudet - Tracking without cookies (2003) (http://www.arctic.org/~dean/)
  • M Ayenson, D Wambach, A Soltani - Flash Cookies and Privacy II: Now with HTML5 and ETag Respawning (2011)
  • Samy Kamkar - Evercookie (2010) (https://samy.pl)
  • Cookieless cookies (2013) (http://lucb1e.com)
  
  
• $ fingerprint@info:~ run ETag-fingerprinting

Demo:

>> Jump to ETag Fingerprinting Demo <<