Remove ETags

[ghost]

ETags are another threat to privacy which are used more and more often (also as a part of the famous Evercookie). Thus, it would be great if HTTPSB - beyond its cookie control - would also offer an option to block ETags.

Some interesting links:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19
https://en.wikipedia.org/wiki/HTTP_ETag
https://trac.webkit.org/wiki/Fingerprinting
http://lucb1e.com/rp/cookielesscookies/
https://grepular.com/Preventing_Web_Tracking_via_the_Browser_Cache

Proxomitron is said to be able to block Etags with a specific filter which seems to manipulate the respective response header, see http://prxbx.com/forums/showthread.php?tid=1816

For a Chrome extension, this site might be relevant: http://stackoverflow.com/questions/13700394/how-to-change-response-header-in-chrome

[gorhill]

Ok I will do some reading about this.

[gorhill]

Regarding ETag, two possible strategies:

• Overwrite ETag with random value -- so that random values are returned to server for each request.
• Give user option to clear cache at regular interval

[ghost]

Yes, I agree. I would prefer the first strategy for performance reasons as clearing the cache slows down internet browsing somewhat.

[gorhill]

I did more reading about all this -- clearly I am not up to date with all the tricks used to track users, but I am learning (thanks for the links).

Trashing the ETag header would work for ETag-based tracking, but wouldn't for other kind of tracking which depend on the cache. For some of these, there is no other way than clearing the cache (like number 3 here).

So at this point offering the user to clear the cache every x minutes seem the best option to me. If one clear the cache every 30 minutes, I don't think the performance hit of not finding stuff in the cache will even be noticeable. The writer in one of the article disabled completely caching, and the result was not that noticeable he said. I would offer to clear it after a set time, this will even mitigate further what is reportedly barely noticeable.

So I rather go with clearing the cache for these reasons:

• Does not introduce further extra overhead in the real time handling of requests.
• Take care of all cases of cache-based tracking enumerated here.
• Code to add is simpler (always a good thing), less likely to introduce new issues

[ghost]

So I rather go with clearing the cache for these reasons:

• Does not introduce further extra overhead in the real time handling
  of requests.
• Take care of all case of cache-based tracking enumerated here
  https://grepular.com/Preventing_Web_Tracking_via_the_Browser_Cache.
• Code to add is simpler (always a good thing), less likely to
  introduced new issues

That makes sense. Thanks a lot, Raymond!