231852 - ETag: filtering to counter web tracking

Status: NEW

Description

[Marc Bejarano]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

a recent post to bugtraq (
http://cert.uni-stuttgart.de/archive/bugtraq/2004/01/msg00166.html ) has revived
the discussion about a long-standing privacy issue with mozilla and other web
browsers.  martin pool discovered this problem and first publicized his findings
in march of 2000 (
http://cert.uni-stuttgart.de/archive/bugtraq/2000/03/msg00365.html ).  his POC
code, meantime, now lives at http://sourcefrog.net/projects/meantime/

mozilla needs some sort of defense against this.  perhaps whitelist/blacklist
support for enable cache-related features?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[benc]

How is Etag linked to other HTTP functions? Can we simply block this header?

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Confirming, not sure what the solution should be though.

Comment 3

[Darin Fisher]

-> default owner

Comment 4

[Ilie Pandia]

Hello,

Could it be that in the private browsing the Etags should be ingored EVEN IF this would impact caching? To prevent that Etag ID to be use for persistent tracking?

Here is the WikiPedia page about that Tag: http://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags

Comment 5

[David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7]

Given that there are plenty of other ways to do tracking with cached resources, it doesn't seem productive to do this unless we have something that will address other such problems as well.  That said, I'm not optimistic that there's a reasonable way to solve them (where "reasonable" means something other than disabling all caching).

Comment 6

[Ilie Pandia]

(In reply to comment #5)
> (where "reasonable"
> means something other than disabling all caching).

When privacy is a concern I don't mind disabling all caching or at least destroying the cache every 5 minutes...

Comment 7

[al_9x]

(In reply to comment #5)
> Given that there are plenty of other ways to do tracking with cached
> resources, it doesn't seem productive to do this unless we have something
> that will address other such problems as well. 

What other ways?  If you turn off scripting and cookies how can the server receive back some previously set unique id (other than an etag)?

> That said, I'm not
> optimistic that there's a reasonable way to solve them (where "reasonable"
> means something other than disabling all caching).

Should it not be possible to disable/blacklist/whitelist just etag support?  The cache would not send etags and fall back to dates.

Comment 8

[Camilo Viecco (:cviecco)]

Attachment: Proposed patch to fix this (validation headers pref)

I think the way to solve this is to have a pref (off by default) that prevents validation headers from being sent. So when a user has changed this pref, the cache still works for resources that have expiration time set up. It does not prevent all fingerprinting but significantly reduces the entropy you can put in the cache.

Comment 9

[Ben Bucksch (:BenB)]

Even the old evercookie http://samy.pl/evercookie/ , which made major headlines some time ago, uses ETags. (forevercookie tracking bug is already added here).
Another demo site demonstrates how to use ETag in the exact same way as ordinary cookies:
http://lucb1e.com/rp/cookielesscookies/
This problem is now hitting news sites [3].

And ETags are being used in the last years by major websites, e.g. Hulu [1], to track users. Also, commercial ad networks and trackers [2] and websites are already using this.
[1] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1898390
[2] http://pastebin.com/FhUYuRsb
[3] http://www.heise.de/newsticker/meldung/User-Tracking-im-Web-Forscher-warnt-vor-heimtueckischer-Tracking-Technik-2048507.html
http://www.heise.de/newsticker/meldung/Websites-hebeln-Anti-Cookie-Massnahmen-aus-1288914.html

As long as we have bugs like this, we can't offer features like "Private Window" or cookie prefs.
Unlike cookies, the browser sends ETags despite all privacy settings.

This isn't merely theoretical anymore, and this must be stopped now.

Comment 10

[Ben Bucksch (:BenB)]

Comment on attachment 612681 [details] [diff] [review]
Proposed patch to fix this (validation headers pref)

Thanks for the patch, Camilo Viecco.

However, I'm not sure that this is the right approach. If I read this correctly, this will disable the server trip entirely, meaning we will use the cached version of the document. This may be the right thing to do in some cases, but maybe not all. It would make the browser faster, and help privacy, but we might get stale documents. Whether or not depends on the other cache factors, which I don't know.

The alternative would be to make the server check, but not send the ETag (or not store it, or both), so that we always fetch the document once we decide to make the server roundtrip. This would increase traffic, but would not increase latency all that much. Correctness would be the same.

Both of these solutions would be all or nothing and completely remove ETag handling. This is fine for people who are aware of the ETag issue, but I'M hoping for something we can enable for all users by default.

Can somebody think of a good way to tell apart real cache ETags from tracking ETags? Something that is implementable?

Comment 11

[Ben Bucksch (:BenB)]

I wrote:
> Can somebody think of a good way to tell apart real cache ETags from tracking ETags?

Whatever the solution is, it cannot be a heuristic. Any heuristic would be workaround around in no time. The fact that ETags are used at all shows that there is a lot of energy to work around the browser, so we need something that *cannot* be worked around. But at the same time can be enabled for all Firefox users. Ideas?

comment 5:
> Given that there are plenty of other ways to do tracking with cached resources,
> it doesn't seem productive to do this unless we have something that will address other
> such problems as well.

Yes, we need to address them one after the other. But we can't ignore the problem, the implications are too big.

Comment 12

[Camilo Viecco (:cviecco)]

(In reply to Ben Bucksch (:BenB) from comment #10)
> Comment on attachment 612681 [details] [diff] [review]
> Proposed patch to fix this (validation headers pref)
> 
> Thanks for the patch, Camilo Viecco.
> 
> However, I'm not sure that this is the right approach. If I read this
> correctly, this will disable the server trip entirely, meaning we will use
> the cached version of the document. This may be the right thing to do in
> some cases, but maybe not all. It would make the browser faster, and help
> privacy, but we might get stale documents. Whether or not depends on the
> other cache factors, which I don't know.

Ben the way this patch works is that if gecko thinks it will need to make a request
for the document (cache is considered stale) then it will NOT include the validation
headers (etag or modified-since). Thus it will make the browser slower for content that
does NOT use expiration information for the cache. There is no use of stale content.

IE does what you describe below. 

> 
> The alternative would be to make the server check, but not send the ETag (or
> not store it, or both), so that we always fetch the document once we decide
> to make the server roundtrip. This would increase traffic, but would not
> increase latency all that much. Correctness would be the same.
> 
> Both of these solutions would be all or nothing and completely remove ETag
> handling. This is fine for people who are aware of the ETag issue, but I'M
> hoping for something we can enable for all users by default.
> 
> Can somebody think of a good way to tell apart real cache ETags from
> tracking ETags? Something that is implementable?

Comment 13

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 14

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 15

[aeffioccau]

I just want to point out that clearing the cache clears the ETags, contrary to some articles (e.g. https://www.ghacks.net/2017/12/09/a-solution-to-etag-tracking-in-firefox/) which point to the "Cookieless cookies" PoC and claim that Firefox keeps the ETags even when the cache is cleared.

The "Cookieless cookies" PoC actually cheats and is basing it on IP address rather than ETag anyway, as demonstrated in the following comments:
https://www.ghacks.net/2017/12/09/a-solution-to-etag-tracking-in-firefox/#comment-4305249
https://www.ghacks.net/2017/12/09/a-solution-to-etag-tracking-in-firefox/#comment-4306403

Comment 17

[sg.steven13]

In the latest nightlies a lot of work has been done to allow users to prevent tracking through a new privacy settings page.
about:config properties have been created to block third party cookies, prevent fingerprinting and control what is sent in the referer header. Maybe it is time to revisit this issue? It sounds like a logical next step to prevent tracking.