Option to block ETag tracking

[emanruse]

https://lucb1e.com/rp/cookielesscookies/ demonstrates a technique of tracking users without JS and cookies, through ETag header.

Please if possible provide an option to block this.

[uBlock-user]

That's a POC, post a use-case to demonstrate where it's being used currently.

[emanruse]

I don't have a list of use cases. According to wikipedia Hulu.com and KISSmetrics have been using ETags for tracking. Visiting Hulu.com still shows ETag in headers (and none of us could be sure how exactly that is used by the backend).

Why isn't the PoC a valid reason to consider the seriousness of the problem?

[gorhill]

Why isn't the PoC a valid reason to consider the seriousness of the problem?

Because only code which is known to have tangible benefits for majority of users with no negative side effects will go into uBO. No actual cases means no way to assess anything.

[emanruse]

Because only code which is known to have tangible benefits for majority of users with no negative side effects will go into uBO. No actual cases means no way to assess anything.

Well, I am not looking for an argument but if that was the right logic - Spectre and Meltdown mitigations would not be implemented at all because all that the researchers showed was a PoC. (and this just one of hundreds of examples)

[uBlock-user]

Why isn't the PoC a valid reason to consider the seriousness of the problem?

With that logic, every POC that appears, uBO must start adding functionality to counter that and that would turn uBO into Feature Creep extension.

POC only shows possibility, not the actual proof of it getting ever used. This is why I asked you to post a use-case.

but if that was the right logic - Spectre and Meltdown mitigations would not be implemented at all because all that the researchers showed was a PoC

Those are exploits, exploits get patched. ETag tracking isn't an exploit, hence that comparison is invalid.

POCs are not to be countered just because they exist.

[gorhill]

Well, I am not looking for an argument but if that was the right logic

It is the right logic. uBO already blocks a whole lot of network requests from 3rd parties, which means ETag are of no concern for these blocked 3rd parties. What is left which is of concern? This is what you need to argue. And for whatever actual cases you put forth, you will have to further argue why current filtering capabilities are not sufficient.

I am just going to be straightforward here. I don't want the issue tracker to be a place to dump thinly researched feature requests. Meaningfully contributing means more than dumping a one-sentence idea in an issue tracker.

Your other issue was pretty much nonsense. When I asked you to provide actual cases, you sidestepped the question and gave me a link to Google Analytics reference API.

When I pointed out that data: URI are not resulting in network requests, you answered something about base64 -- which also means nothing.

When you focus solely on image size, you miss the point that image resources for tracking purpose can be of any size, just small enough to not be a burden, that small image sizes are not a sure sign of tracking, and there are other resource types which could be used for this, stylesheets for example. In the end, nothing that is out of reach of existing filtering capabilities.

[emanruse]

Those are exploits, exploits get patched.

No, they are vulnerabilities with demonstrated PoC. Nobody has provided any actual use cases demonstrating that there is a particular software exploit taking advantage of the vulnerabilities.

POCs are not to be countered just because they exist.

Patches for Meltdown and Spectre were created asap and the PoCs were (and still are) considered seriously. They were not ignored just because no software was known to exploit them. A PoC is exactly that: a small (not always complete) practical example demonstrating that certain idea is feasible. And that usually serves very well to improve the security of a system before an actual exploit. Everyone who understands security would confirm that it is all about prevention.

Otherwise we can say "Since we haven't seen the backend code of the website, let's assume there is no danger, let's be tracked, we don't even have a proof (POC) that it is bad for us". But for this one we do have a valid proof. Not sure why you are trying to diminish its significance.

uBO already blocks a whole lot of network requests from 3rd parties, which means ETag are of no concern for these blocked 3rd parties. What is left which is of concern?

What have 3rd parties to do with all this? The ETag can be delivered as first party header and the supplied link demonstrates exactly that. Consider also the additional info I found for you from Wikipedia.

This is what you need to argue. And for whatever actual cases you put forth, you will have to further argue why current filtering capabilities are not sufficient.

I haven't seen a feature in uBO which allows to block ETag-related communication. If you can demonstrate there is such feature - then this issue is invalid.

I don't need to argue since I have shown you the vulnerability. There are 2 things you can do:

• ignore the suggestion (easy)
• implement a feature and make uBO even better

You don't have any obligation to implement it. It is a polite request/suggestion, not an order.

I am just going to be straightforward here. I don't want the issue tracker to be a place to dump thinly researched feature requests. Meaningfully contributing means more than dumping a one-sentence idea in an issue tracker.

To someone like you who surely knows how HTTP works I don't think a lot of words are necessary. You want to be straightforward - that's fine. The provided example is also straightforward. Tracking through ETags is possible and that's all that matters. The rest is up to you.

Your other issue was pretty much nonsense. When I asked you to provide actual cases, you sidestepped the question and gave me a link to Google Analytics reference API.

I explained exactly how it works from the very beginning. If you feel I have not clarified - please ask for specifics in the other issue and I will.

I think this is your answer for this feature request

Anti-fingerprinting features are best left to a dedicated separate extension -- which would require constant work.

When I said "require constant work", I refer to creating and maintaining a multi-platform extension, not the just the js code to counter one specific fingerprinting technique. There is no point cramming one specific anti-fingerprinting scheme in uBO without cramming all of them, and this assuming I would agree with such feature creep at all. Anti-fingerprinting is best solved by a dedicated extension, and this requires constant work.

gorhill/uBlock#1696 (comment)

Browser fingerprinting is a vast undertaking, more than just foiling the specific mechanism you mention. If I accept to address that specific mechanism, this means I would accept to deal with all fingerprinting mechanisms, and this can go very far from uBO's primary purpose: an efficient blocker for network requests and DOM elements.

gorhill/uBlock#1037 (comment)