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.

[gwarser]

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)

[asheroto]

I'd like to cast my vote for this too.

In researching some of the methods used by implementors of browser fingerprinting, I found that nearly all of them use the same or similar techniques.

This extension, for example, has proven to be effective in every single fingerprint software I've come across.

https://chrome.google.com/webstore/detail/fingerprint-spoofing/ljdekjlhpjggcjblfgpijbkmpihjfkni

I checked all of the boxes to turn everything on.

The only fingerprinting website I couldn't get around was Fingerprint.com (makers of Fingerprint.js). Their open source version, this extension was able to trick. But their paid version, on the demo on their site, it still produced the same visitor ID. They're an outlier though - they use some advanced techniques in addition to employing AI and determining a statistical probability of you being you.

Anyway, I think if uBlock Origin could provide the option to either block, or preferably randomize, some of the same data that this extension handles, it would suffice for most users. :-)

I tested 6 different fingerprint demos and only one was untrickable. 😊

Brave Browser blocks fingerprints, but that stupid WebGL, Canvas, and Font data seem to be the sneakiest methods, which Brave hasn't successfully stopped yet, probably because as you mentioned, if you simply block those settings then that still makes you unique.

[MasterKia]

@asheroto uBO has a shim for FingerprintJS.
https://github.com/gorhill/uBlock/wiki/Resources-Library#fingerprint2js-
https://github.com/gorhill/uBlock/wiki/Resources-Library#fingerprint3js-

[asheroto]

Cool, thanks!😊

I meant to also say, it might be somewhat easy block a lot of their stuff simply by blocking the URL where their JS file resizes...

https://fpcdn.io

    // Initialize the agent at application startup.
    const fpPromise = import('https://fpcdn.io/v3/user-random-id-string')
      .then(FingerprintJS => FingerprintJS.load())

    // Get the visitor identifier when you need it.
    fpPromise
      .then(fp => fp.get())
      .then(result => {
        // This is the visitor identifier:
        const visitorId = result.visitorId
        console.log(visitorId)
      })

[asheroto]

@asheroto uBO has a shim for FingerprintJS. https://github.com/gorhill/uBlock/wiki/Resources-Library#fingerprint2js- https://github.com/gorhill/uBlock/wiki/Resources-Library#fingerprint3js-

This is probably the best choice, since the URL where the JS is loading from could be locally hosted or ran through a different filename.

[MasterKia]

@asheroto I don't know if you're interested in ETag but for your info, this is possible:

*$script,strict1p,header=etag:"a7a61709860c0c57ec0c92584ae4f1bc214dfc71043ea43843572e55d14841f6"
*$script,strict1p,header=ETag:"a7a61709860c0c57ec0c92584ae4f1bc214dfc71043ea43843572e55d14841f6"

Source: Yuki2718/adblock#45 (comment)

[cbarrick]

I came here looking for such an ETag blocking solution, but gorhill commented above why uBO will not implement this. I now understand why uBO should not implement this, but I think it's worth re-stating the argument more succinctly for people who find their way here from Google.

1. If a third party site is using ETags to track you, then uBO already protects you by blocking the request.

2. If a first party site is using ETags to track you, that's effectively the same as a cookie. uBO is not a cookie blocker.

So if you have concerns about first-party cookies and ETags, you will need a separate cookie blocker.

[stephenhawk8054]

@cbarrick It's not about implementing or not. It's about providing real-world cases where issue occurs and what is its characteristics in real websites. Because only that can we recognize and craft the pattern to find how to resolve most efficiently, and how much the resolution would affect in reality.

For example, the thread @MasterKia referenced above describes the issue and proposes a solution (via header) quite well, so you can do the same:

• Provide the (real, not POC) websites that have issues,
• Describe in details what are happening,
• Explain why current methods cannot solve the issue
  ...