Question: why don't you suggest to enable the stealth preset for CanvasBlocker?

[lucatrv]

@Thorin-Oakenpants, this article explains why submitting different fingerprints for every request can be counterproductive for fingerprinting protection, as it will make you stand out among others.

I am sure you are aware of that so I wonder why you do not suggest to enable the stealth preset for CanvasBlocker in the extension section of the wiki.

Thanks

[Thorin-Oakenpants]

update: after typing that original reply but before posting

Wiki: Anti-Fingerprinting Extensions... F&%K NO!

Note the parts that say

If you don't use RFP, then you're on your own

and the last tiny bit after explaining entropy

Don't believe the BS.

No-one knows (or shares) any real or accurate/controlled entropy data. So any claim that any particular type of FPing method for canvas is better is a complete guess.

---

original reply

The article is over 4 yrs old, just keep that in mind, and I'm not going to read it (seen it before from memory, years ago) - a lot has changed in that time: including what extensions are able to do, what RFP does, the changes in FP scripts in the wild, etc.

First of all, no-one actually knows (or shares) the entropy of various canvas anti-FPing techniques. To get the real entropy you need a large controlled real world study of users, one result per user. Even then, that study should be looked at per browser - because you can't hide your browser (i.e FF, TB, Chrome, Safari).

Outside of Tor Browser (as far as we know it's bucketized tighter than a nun's ass), if scripts wanted to, you're going to be unique. So the best defense is to tackle FPing scripts: if they can't run, they can't FP you. You have enhanced tracking protection, you have uBlock and uMatrix (I don't tell people how to configure them: as every one's threat model or tolerance is different). Then we fall back to prefs and APIs: e.g disabling web audio, disabling webgl, etc. One of those prefs is RFP

We already flip a bunch of prefs for anti-FPing, and we encourage users to use uBO etc. We also turn on RFP, and we have a bunch of prefs commented out by default in the user js, because they change how RFP works with some FPing metrics. Additionally, as an aside, FPI is enabled, which hampers the ability of third party data brokers being able to link traffic: from a purely FPing PoV, that's immaterial, but in reality, it's how data brokers work - i.e they still almost exclusively rely on persistent web storage: they haven't evolved to large scale FPing, certainly not in-depth sophisticated ones: but it needs constant watching). People are overthinking FPing: sure the threat exists, but not many sites do it (but growing), and a lot of it is already covered

We also encourage users to not raise entropy (on the extensions wiki) - but given the recent change to RFP canvas (see next paragraph), I'm going to change that : [EDIT: see the new wiki /end edit]. The saving grace for CB is that RFP doesn't let extensions meddle with canvas until you allow a site exception. CB has morphed a little: but CB defaults for everything else don't interfere (AFAICanRemember) - i.e you have to enable the other APIs like screen, navigator, and APIs like web audio, domrect, webgl cover things RFP doesn't.

RFP (FF78+) now randomizes canvas for toDataURL, toBlob and getImageData - on every request. It still returns white canvas for isPoint* - so it's super easily detectable as an RFP canvas defense. The randomness also has telltale characteristics of being 8 colors and a size around 250bytes. And if you have RFP on, it's trivial to detect (takes less than 1ms). So when your canvas FP is so radically different to RFP's, now you lose all herd immunity and ARE unique.

---

tl:dr: on FPing extensions/configs

• If users don't want to use RFP, that's on them
• If users bypass RFP, that's on them
  • I'm certainly not going to add config settings for FPing configs for users who bypass RFP protections: certainly not on the wiki, and TBH, I don't even want to waste my time discussing them in issues

[lucatrv]

Thank you for your answer and insight, but sorry I would like to ask a clarification on what you wrote. I always keep FPI and RFP enabled, as I think they provide the best base protection for privacy (of course, since they come from Tor). When you say that "when your canvas FP is so radically different to RFP's, now you lose all herd immunity and ARE unique" do you mean that, since I already have RFP enabled, I should not enable also CB?

[Thorin-Oakenpants]

you

do you mean that, since I already have RFP enabled, I should not enable also CB?

me

The saving grace for CB is that RFP doesn't let extensions meddle with canvas until you allow a site exception

Example: CB is enabled with canvas

• Site requests canvas - RFP says here's a random(78) or white(<78) canvas - herd immunity
• Site requests canvas - RFP notes a site exception, does nothing - CB sees the canvas request and does it's thing - lose herd immunity

Example: CB is enabled with canvas navigator spoofing

• Site requests user agent - RFP says "spoofed as ESR68/78" - CB sees the spoofed value and changes it <-- lose herd immunity

Canvas is about the only thing that RFP locks down from extensions, since it's so damaging

CB is fine

• canvas when used (i.e when you use a RFP site exception), is good, because you're still faking, and then if need be, you can allow a CB whitelist entry to get a site to work correctly (e.g. it might be google docs and you're logged into google, so it's not really an issue: your call). The main thing is you have levels of protection
• domrect, textmetrics, audio, history, window all seem fine: because RFP doesn't cover those
• I just wouldn't go using the navigator or screen parts

---

the screen part of CB is interesting: I outlined the approach it uses to kkapsner to add as a PoC (for Tor Browser): I want RFP to change spoofing screen metrics as inner, and instead use a sliding scale of 6 or 7 common resolutions: but only for desktop, not android

• under a certain width/height threshold: spoof as inner which is what RFP currently does (CB doesn't use this step, but it might make sense for RFP)
• over that minimum threshold bucketize: as long as the inner dimensions fit in that bucket
  • e.g. CB reports as 1366x768, 1440x900, 1600x900, 1920x1080, 2560x1440, 4096x2160, 8k
• the last one is 8k and is the upper limit

Most scripts only grab screen measurements (inner window is just not stable enough for tracking). Currently, if you use letterboxing, the combinations possible total something like 50 combos (the sizes snap in different step sizes as you go smaller to bigger). That's all good for inner window.

If people don't use letterboxing, this screen sliding scale still protects their screen metric. Tor Browser are going to add a UI option to enable/disable LBing. If you use LBing that's still good for inner windows, but even then, it still reduces the possible screen buckets down from 50 to 7 or 8.

There are added benefits as well, as each person changes their screen bucket (as they maximize, or drag bigger) this creates instability in the FP, and it also allows websites to deliver appropriate content: e.g. video size. So users could maximize to load and watch a video, drag bigger for other sites, or just use the default size for browsing most sites. They can if they wish open a new window for anything they resize. There's no downsides AFAICT.

Another thing I want RFP to do is to increase the default width on new windows. Increasing default width to say 1200 wouldn't even change any of the current buckets. And at 1000, even internal about:pages can end up horizontal scrollbars. I haven't totally worked out all the possible combos, but I think even 1400 doesn't create any new buckets. Add the screen sliding scale and it all just makes Tor Browser more usable

soz for the ramble

[lucatrv]

Thanks, now it's clear to me, also this and this threads helped out.

[Thorin-Oakenpants]

^^ or #350 first post, scroll down to Canvas

[hkaancaliskan]

@Thorin-Oakenpants after 2 years, is this still applies?

domrect, textmetrics, audio, history, window all seem fine: because RFP doesn't cover those

[Thorin-Oakenpants]

history isn't even a thing. it's scoped to eTLD+1 + scheme. There is something about possible XSS, but TBH, forget about it.

---

audio doesn't have entropy in FF really - see #1194 - it's mainly at most two results per platform (that's the audio sum non-user gesture one), and RFP covers audioContent keys. I'm not 100% sure on the other user gesture audio FPing - there's a paper that shows advanced different audio wave forms generated more entropy (to about 4 or 5 at most per platform), but these rely on some keys being variable between users, such as sample rate (which RFP hardcodes) - edit: and the test is a fucking perf monster not fit for FPing

anyway, audio will be covered by RFP - it's next on the bucket list

---

textmetrics, domrect are a waste of time IMO. First, like the others, they can be detected when extensions meddle with them (from prototype /proxy lies)

If you use CB, instead of RFP, then all you need is canvas and perhaps a second random value (two randoms might fool an extra script)

the best you can do in FF is fool naive scripts: almost all scripts have canvas, and most don't check for lies: if it can detect a lie then the randomness is now static, e.g. "you lied" instead of a unique canvas hash - and the script is no longer naive. But it's not hard to check a known canvas value to detect lies - takes about 3-5ms, so audio seems like a good bet for secondary one

read: that entire wiki link i just gave you

---

edit: sorry, sounds like you want to use an extension WITH rfp .. fuck no, don't bro

because RFP doesn't cover those

If you use RFP then that is all you need, because ... read the wiki

[hkaancaliskan]

Yep i was thinking about combining RFP and CanvasBlocker.

If you use RFP then that is all you need

Thank you so much for all these informations and your time :)