ETag: filtering to counter web tracking
Categories
(Core :: Networking: Cache, defect, P3)
Tracking
()
People
(Reporter: bmo, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: privacy, Whiteboard: [necko-backlog])
Attachments
(1 file)
4.63 KB,
patch
|
Details | Diff | Splinter Review |
Updated•22 years ago
|
Comment 4•14 years ago
|
||
Comment 6•14 years ago
|
||
Comment 8•13 years ago
|
||
Comment 9•12 years ago
|
||
Updated•12 years ago
|
Comment 10•12 years ago
|
||
Comment 11•12 years ago
|
||
Comment 12•12 years ago
|
||
Updated•10 years ago
|
Comment 13•8 years ago
|
||
Comment 14•8 years ago
|
||
Comment 15•8 years ago
|
||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 17•6 years ago
|
||
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.
Comment 18•6 years ago
|
||
Here are two separate ideas how to handle this problem:
- Ignore the ETag and store the HTTP response's retrieval timestamp instead. Then for the subsequent requests use If-Modified-Since with that stored timestamp. While it's not semantically identical to ETag, seems close enough for the common real-life use cases.
- Replacing a relevant GET request (those containing ETag) with a HEAD request (not containing ETag) and then locally comparing the received ETag with the stored one to decide whenever subsequently issue a GET (again not containing ETag) to retrieve the requested resource, or use the cached instead.
Also, it might be useful to create a new switch on the privacy settings page, giving the user choice between one of the above options and the unmodified cache handling behavior (means sending the ETag), with a brief warning about the risk of cookieless/ETag tracking.
Updated•6 years ago
|
Reporter | ||
Comment 20•6 years ago
|
||
ehsan: did you mean to mark this bug as depending on bug 1590107 instead of being a duplicate of it?
Comment 21•6 years ago
|
||
(In reply to Marc Bejarano from comment #20)
ehsan: did you mean to mark this bug as depending on bug 1590107 instead of being a duplicate of it?
I did mean to resolve it as a duplicate: not in the sense that the bug report is a duplicate report (which it obviously isn't), but in the sense that the cross-site tracking vector that this bug discusses will be fixed once the HTTP cache partitioning solution being tracked in bug 1590107 is deployed. In that sense the cross-site tracking aspect of this bug will be "fixed by" that bug. We usually use the duplicate status to capture this in Bugzilla, but that's just a convention, and one could argue a dependency could capture the same meaning -- I'm generally ambivalent to the distinction; my main goal here was to communicate to you and others on this very old bug that finally something is happening in this space. :-)
Of course the same-site tracking vector that this bug discusses won't be fixed by bug 1590107, as it will still be possible for a third-party subresource to store a unique identifier in the ETag of a cached response and use it to track the users' browsing activity across one top-level origin. Same-site tracking isn't currently part of Mozilla's anti-tracking policy, and the work to make it impossible will be much broader than just address ETag-based tracking.
Comment 22•6 years ago
|
||
But it seems to me that they had been a lot of effort to reduce even same-site tracking, and I don’t see why this shouldn’t be a goal and then why we should not keep this bug open. Indeed, this bug depends on the new one for cross-site tracking, but it needs more to be fully fixed.
Reporter | ||
Comment 23•6 years ago
|
||
(In reply to :ehsan akhgari from comment #21)
I did mean to resolve it as a duplicate: not in the sense that the bug report is a duplicate report (which it obviously isn't), but in the sense that the cross-site tracking vector that this bug discusses will be fixed once the HTTP cache partitioning solution being tracked in bug 1590107 is deployed.
Okay. Let's mark it like it is, then.
Updated•5 years ago
|
Comment 24•4 years ago
|
||
Is the request of this bug to protect against same-site tracking? I.e., a means to disable any stateful API? If that is the request it would be helpful if the summary and OP are updated to reflect that (and we should also remove some the Depends on and Blocks bugs).
(That's not currently a priority for Firefox, but I suppose we would accept patches and you might be able to get a long way through various preferences that are available.)
Updated•3 years ago
|
Description
•