https://fingerprintjs.com/demo/ gives me the same fingerprint value across browser restarts and regardless of incognito or not. I have fingerprinting set to strict. I imagine fingerprint blocking is a game of cat and mouse. Does brave have an update coming to address this?
It also detects that my browser is brave and whether or not I’m using incognito mode, fwiw.
By the way, at some point that page didn’t manage to detect incognito mode anymore; it looks like it’s working again though. For the record, https://chrome.google.com/webstore/category/extensions has always detected incognito mode (and stops you from using the website).
The primary issue I reported isn’t the same as those linked. The primary issue is that it’s able to fingerprint consistently.
That said, as old as those other issues are, why isn’t this being addressed? Seems to me that this is one of the most important distinguishing features of Brave.
In theory you’re absolutely right, but in practice it’s the other way around: that website often manages to address the issues instead. I don’t think they will ever give up, because they even sell a software product to bypass anti-fingerprinting mechanisms etc.
You know what, I just realized this JavaScript library now manages to track us even ignoring a private Tor window
This is a serious issue. Could Brave staff comment on this? Maybe @fmarier? Thank you.
FingerprintingJS is used by some of the major sites such as Yahoo, ebay, Target, Western Union amongst many other big enterprises.
I use different fingerprinting blocking addons from Chrome store to resist fingerprinting and it seems to work well with FingerprintingJS as well.
Even the “strict” mode to resist fingerprinting in Brave browser does not seem to work accurately, (presumably) because fingerprintjs is quite easily able to revert the “farbling”: https://fingerprintjs.com/blog/audio-fingerprinting/
The farbling modifies the original Blink AudioBuffer by transforming the original audio values.
Reverting Brave standard farbling
To revert the farbling, we need to obtain the fudge factor first. Then we can get back the original buffer by dividing the farbled values by the fudge factor
It seems that fingerprinting blocking will probably continue to be a game of cat and mouse for quite some time.
Just as an example, we haven’t even talked about external protocol flooding (schemeflooding) vulnerability that creates a unique fingerprint across multiple browsers. Perhaps, many people take for granted that cross-browser tracking is not possible; at the time of writing this post, this vulnerability seems to be able to generate a unique fingerprint across browsers. I did a quick test in Firefox and Brave and my fingerprint was unique across both browsers. On the surface it does look like an easy (relatively speaking) vulnerability to fix, I am not a developer per se so don’t quote me on that!
The point I am trying to make is that fingerprinting blocking will be quite a difficult job for browsers at least for the foreseeable future.
I think it’s useless to block it, they probably went from a.fingerprintjs.com to b, c, d, e, and now on f, so blocking will just make them change that again.
