fingerprintjs still seems to get a constant fingerprint

[ilikenwf]

I'm using canvasblocker, resistFingerprinting, and some other even more paranoid settings from the ghacks user.js file...

Despite this, fingerprintjs seems to be able to get a constant or near constant fingerprint from my browser.

https://fingerprintjs.com/demo

I'm not entirely sure if it is the canvas, but I would expect that with various configurations this hash should change every page load if I've not got "constant" set, correct?

[kkapsner]

If you use resistFingerprinting the canvas fingerprint will not change. But it will be the same to all TOR users and all other users that enabled it. See #158 and arkenfox/user.js#767 for further reading.

But I'm quite sure this page uses some sort of persistent storage to keep the ID. It does not change for me upon reload but if I use a private window it does (closing the private window and opening another one also changes it).

What do you get when you open the page in a private window?

[ilikenwf]

I get the same result all around... I'm using some other addons but none of them should be affecting the canvas.

…

On 11/29/19 4:31 PM, kkapsner wrote: If you use resistFingerprinting the canvas fingerprint will not change. But it will be the same to all TOR users and all other users that enabled it. See #158 <#158> and arkenfox/user.js#767 <arkenfox/user.js#767> for further reading. But I'm quite sure this page uses some sort of persistent storage to keep the ID. It does not change for me upon reload but if I use a private window it does (closing the private window and opening another one also changes it). What do you get when you open the page in a private window? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#410?email_source=notifications&email_token=AADFIOXLMW2PFCKD3ZHEPEDQWGJ4BA5CNFSM4JSZVWJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFPTWVA#issuecomment-559889236>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFIOWK3MSBRK5QPIS4PB3QWGJ4BANCNFSM4JSZVWJQ>.

[ilikenwf]

...disabling resistFingerprinting has fixed the randomnness.

On the upshot I have most of the bases that resistFingerprinting covered between my user.js and other addons, as well as canvasblocker.

[ilikenwf]

Having the master switch disabled seems to only affect a handful of options not otherwise exposed to granular control - the script timing mitigations are broken out in their own options it seems. privacy.resistFingerprinting.reduceTimerPrecision.jitter privacy.resistFingerprinting.reduceTimerPrecision.microseconds I would argue the proof is in the pudding - having the option on, I have a consistent fingerprint. Off with canvasblocker and my options, and addons as they are, they can't get a consistent hash on me.

…

On 11/30/19 12:51 AM, Thorin-Oakenpants wrote: I have most of the bases that resistFingerprinting covered Not true :) Firefox core code can (bugs aside) properly protect you, whereas extensions are limited. For example, you can bypass script injection via timing — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#410?email_source=notifications&email_token=AADFIOUTMMLY7J2POZYABLLQWIEQ3A5CNFSM4JSZVWJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFP2Z7Q#issuecomment-559918334>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFIOUR2E23IT5QMGIKNHTQWIEQ3ANCNFSM4JSZVWJQ>.

[ilikenwf]

I'm not playing with them, but they're on and have default values despite the main resistFingerprinting option being turned off...unless it disables the entire class of mitigations I'd argue there's little to worry about.

Considering that most fingerprinting is done using something like fingerprint.js, I would argue it is more important to avoid a consistent fingerprint than it is to do things the correct way until this issue is worked around and canvasblocker can randomize and coeexist with the resistFingerprinting option.

Most of what you see here is me spoofing, and I have RFP off... the canvas fingerprint is as it is because I'm spoofing it randomly instead of using an all white alpha channel, which if I recall is what the tor project does?

[kkapsner]

@ilikenwf great - then we found the source of the constant fingerprint. In that case all users of RFP should share the same fingerprint as you and you are harder to track within that crowd. My point in that discussion is that both approaches (having the fingerprint change all the time and sharing a fingerprint with a lot of other people - an analogy for the first would be to identify real people by the number of mouths they have and for the second one to do that by the number of seconds they are alive) are valid and will both protect you. I decided to go in CB with the "change always" way as it's easier to do and maintain.

You two can continue to discuss but as CB is out of the picture I will close the issue.

@Thorin-Oakenpants the UA test page reports exactly the same result for all methods for me (I have the UA changed via CB). As far as I know the methods are similar to the ones in https://canvasblocker.kkapsner.de/test/test.html - just something else was read.

A sandboxed iFrame is kind of protected agains changes: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox

[ilikenwf]

Most of my fingerprinting mitigations revolve around emulating tor browser, including the spoofed UA.

As such I can at best suggest that using "none - completely white" for the canvas with RFP enabled and spoofing a common resolution is the best option. Despite the results I'm still unique within 51,000 visitors, so I wonder if any of this is worth it or if some of my settings need to be further tuned.

Suggestions welcome: