Firefox RFP and Brave's Fingerprint randomization.

[Ja-ngolo]

After looking at pages like coveryourtracks by the EFF, they do mention that randomizing one's fingerprint each session, tab or window can thwart some of what arkenfox would call naive scripts. But i have also seen a lot of sites send me a "login from new device" mail when using brave, where it would NEVER happen when using Firefox. However, I have seen on a lot of discussions forums and threads that people are kind of wary of fingerprint randomization and that it makes you stand out more. I might agree on some level and obviously and if the threat model is high enough it wont make sense. Something like Tor exists for that. But I don't really see the advantage of something like RFP that breaks a lot of web usability and convenience over what brave offers. For most people with low threat models, or say like just wanting to escape from surveillance capitalism and adware networks, It could be a more convenient options. My question really is why should y'all recommend people to go and install arkenfox and all of that when maybe all it is doing is faking some info through the RFP, but from what i can tell brave does a better job at fooling naive scripts and making it harder for trackers (ads and normal stuff) from following users arround?

[ph00lt0]

Well that really depends on how you use Firefox. If you use the user.js as described on the website you get the same kind of emails when using firefox as you experience with Brave. Brave arguable doesn't do a better job. Arkenfox' protections have found to be stronger and this has been discussed many many times now. It's getting boring. I never really had issues with RPF, what does it break for you?

[Ja-ngolo]

For me it breaks apple mail (icloud.com) and some colaborative boards like miro. But for real say using slack for work on brave i would always get that email, but using the user js i never get it. So there must be a tangible difference. And I wouldn't understand why then EFF on cover your tracks would not also say that helps evade fingerprinting.

If you can, please point me to where it has been discussed, cuz I haven't been able to find it.

[Thorin-Oakenpants]

It breaks them because ...

absolute rubbish. The reason RFP breaks icloud is because of timing mitigations with performance.mark()

• https://bugzilla.mozilla.org/show_bug.cgi?id=1621729
• https://bugzilla.mozilla.org/show_bug.cgi?id=1618537

[Ja-ngolo]

absolute rubbish.

Completely agree, I know why it breaks with UblockOrigin on their dynamic blocking mode, RFP is a completely different story. And tbh it does not break on all blocking modes, just when you outright block all 3rd party frames and scripts.

The reason RFP breaks icloud is because of timing mitigations with performance.mark()

good to finally know why it breaks, I was not sure what was breaking it, thanks!

[SkewedZeppelin]

as most people look at tests in isolation: here is CreepJS on different devices side by side:

Desktop & Laptop

Virtual Machine & Host

Nexus 5 & Nexus 5x

Nexus 4

imo RFP is doing exactly what it says on the tin and that^ demonstrates the buckets well.

[Ja-ngolo]

I'm sorry, but I'm not technically versed enough to know what those tests mean. If someone could translate that into words I would greatly appreciate it. And I think there has been a misunderstanding. I'm not claiming that RFP does not do what it claims to do, it clearly works. My point is more directed to the Randomization vs Spoofing deal. From what I know RFP spoofs a lot of the fingerprint instead of randomizing it, aside of generating some breakage.

My point is, why point users towards the arkenfox user JS, if brave works by randomizing the fingerprint, thus making the user less persistently traceable by naive scripts. Basically getting you 80 or 90% close to what RFP achieves but without the tinkering and possible site breakage. If I am missing something please show me the light, or tell me in simple terms why one approach is preferred than the other.

[Thorin-Oakenpants]

I'm sorry, but I'm not technically versed enough to know what those tests mean

exactly

My point is more directed to the Randomization vs Spoofing deal

https://github.com/arkenfox/user.js/wiki/3.3-Overrides-[To-RFP-or-Not]#-fingerprinting

RULE #1 Protect the real value of each metric ... it does not matter how it does it

repeat: it does not matter how it does it

[Ja-ngolo]

Arkenfox's primary objectives have always been security, privacy and mitigating the very real and substantial forms of tracking such as state and navigational, rather than prioritizing the potential threat of a widespread advanced fingerprinting script.

RFP contains timing mitigations as a bonus against many side channel attacks.

So taking this into account, that's why y'all recommend firefox+arkenfox better than brave, or it has more to do with the fact that one is geko and the other one is blink based?

exactly

What do you mean by this? That if I'm not technically versed enough I shouldn't care about fingerprinting protections, or what implementation better protects me? If I am asking it is because I genuinely want to understand what's behind either implementation. Sadly in different forums and blogs one gets brought up as being better than the other so Its hard to get a clear answer from that. So I want to ask this community in particular, which I trust.

[Thorin-Oakenpants]

The idea behind Brave is to block everything that ...

This is not how anti-fingerprinting works. There are many methods to protecting a metric, of which disabling an API is the last option.

your description of "user.js" does not match what arkenfox does or aims to do (it does not block iframes, it does not "strip" naive scripts) and it breaks VERY LITTLE (you mileage will vary and most breakage/usage-issues comes from TWO prefs: referrers and RFP), and almost everything you have said is a word salad that I cannot make any real sense of

[Ja-ngolo]

block or unblock with the settings toggles in each of the columns

I think you might be confused between the advanced Ublock Origin dynamic blocking modes and the Resist Fingerprinting preference found on firefox's advanced config and the arkenfox user.js.

referrers and RFP
Yes i can completely agree and attest to this, if ne leaves referrers untouched and does not activate RFP most sites wont break. Unless one is also using Ublock Origin with dynamic blocking on for third party frames and scripts. However, I reiterate, that is not the reason why I asked the question in the first place. My question is geared more towards the fact that i experience more breakage with RFP than brave on strict fingerprint protection, and why is it that the EFF recommends it on coveryourtracks, but most people here say RFP is better.

[Ja-ngolo]

Ok I think I should layout my question in simpler terms to avoid misunderstandings:

• Why does the EFF on coveryourtraks makes a big deal that brave is one of the few (if not the only) browser that randomizes ones fingerprint to limit tracking by that method?

• Is randomizing the fingerprint better than just giving out false values as RFP does? (I know it only catches naive scripts)

• Wouldn't a non randomized fingerprint still leave a "trace" making one more easily traceable? (I know a randomized fingerprint can make one stand out much more, but on the long term, in my opinion it is much more harder for an advertiser or naive script [not a targeted attack] to track over time)

• Is firefox's RFP really that much better than Brave's approach? If someone could explain why in simple terms it would be greatly appreciated, since im not that well versed on the technicalities.

[Thorin-Oakenpants]

Is randomizing the fingerprint better than just giving out false values as RFP does? (I know it only catches naive scripts)

it depends on the metric: for example, the only way to protect canvas and not break it, is to randomize (subtlely). But generally speaking, it can't hurt and may help. Ultimately though, all randomizing can all be detected, which is why RFP doesn't bother. Brave meanwhile, with it's engineering set up to protect the seed, can just add as many as they want.

Wouldn't a non randomized fingerprint still leave a "trace" making one more easily traceable? (I know a randomized fingerprint can make one stand out much more, but on the long term, in my opinion it is much more harder for an advertiser or naive script [not a targeted attack] to track over time)

RFP is randomized. Brave is randomized. Brave randomizes more items. The more randomized items, the greater the chance a script swallows the poison pill and becomes a naive script and thus doesn't track you. End of story. How that translates in the real world is unknown since FPing is not super widespread, the scripts aren't that universal, known FPers are blocked (uBO, ETP), and canvas is very common and most likely naive on it's own in most cases (IMO)

[Thorin-Oakenpants]

Is firefox's RFP really that much better than Brave's approach? If someone could explain why in simple terms it would be greatly appreciated, since im not that well versed on the technicalities.

Who's saying that FF's RFP is better than Brave? Read the rules again: https://github.com/arkenfox/user.js/wiki/3.3-Overrides-[To-RFP-or-Not]#-fingerprinting

Tor Browser has some additional defenses: obviously IPs, but ignore that as a separate issue. 95% of the FP protection is RFP, but some major diffs are TB has a much more robust font protection, and webgl is behind a click-to-play. There are a few other minor diffs. RFP covers a lot (but not much has changed in the last few years, and we can still do a lot more, and are working on it). Tor Browser's FP protection assumes a threat model of advanced/sophisticated attacks, and has proven to be very effective - for a lot of metrics we know without large scale tests, because .. maths (go to school kids). But some are a little unknown. So as far as "we" know, it holds up extremely well.

Now, note, that Tor Browser is assuming advanced scripts, and thus requires a crowd. Naive scripts do not need a crowd (more on that later). There will always be a minimum set of fingerprints or buckets of users: some things you just cannot lie about (without changing their purpose) or even hide, or even make everyone the same: e.g.

• you cannot hide the OS (windows, linux, android, mac)
• you can't lie about the language: I mean if you're an arabic user requesting arabic, then so be it: no point asking for en-US and getting english pages when you can't read english
• you can't make everyone the same window size: some users have screens that are too small
• there's obviously many more metrics that splinter these groups: not everyone can be identical on every metric

So there will be a minimum set of buckets of users, and how many users are in each will vary: from e.g. a big fat chunk using en-US on windows .. down to a very long thin tail and at the end e.g. a few tibetan users on a small res linux

So Tor Browser requires a crowd, which is good because RFP and Tor Browser settings are all set as a default. And the bigger the crowds the better (and hopefully those at the end of the long thin tail get more and more numbers). I think Tor Browser has 3 to 6 million daily users. Imagine if it was 60 million. So one part is adding FP protection, the other is to grow the crowd

I will answer more on FF's RFP vs Brave next - I just wanted to clear up that RFP is designed for Tor Browser and the threat model is different

[Thorin-Oakenpants]

Is firefox's RFP really that much better than Brave's approach

Now that I pointed out that RFP was designed for Tor Browser, lets look at it FF vs Brave. First things first: the "approach" (lower/raise entropy) doesn't matter, as long as you protect the real value. Other than that, there are two answers: either script is naive or it isn't.

Answer 1: Both RFP and Brave have randomizing. If a script is naive then no crowd is required to hide in. Brave randomizes more items. That's it. Probably likely that brave sucks in more scripts that may get through

Answer 2: If a script is not naive, then a crowd is required. Brave's shields is on by default, and I believe Brave has 50mn users - so that's all excellent. RFP on the other hand is not enabled by default. The other part is, reading the RULES on my wiki page, is to "Cover enough metrics", and Brave is slowly adding more and more metric protections, and the more they add, the harder and more costly it gets for fingerprinters. But only RFP has gone anywhere near enough. Note both browsers do not cover the IP issue.

So take from that what you will. Firefox's RFP is super robust covering many metrics (missing webgl is about the ony thing and linux fonts protection is a bit iffy) and contains timing mitigations (which are not to be sneezed at: they are a very important part of overall protection) - but also because of all this (e.g. fully random canvas, timing mitigations) can be a little less compat friendly. Although we are hoping to get an RFP site exception ability added to lessen that (as well as working on known issues). Brave meanwhile has covered some very important metrics, but nowhere near enough (with a much higher threat model). Brave threat model is not the same as RFP's.

So ultimately, if your threat model is that high .. USE TOR BROWSER .. otherwise, get on with your life. If you use FF use RFP (if it suits) or at the very least CanvasBlocker (just canvas and audio will do). If you use Brave, you have Shields

There is nothing wrong or better about either of them, except it was hoped at some stage that RFP would become part of Private Browsing and/or front facing (UI) and thus would have created some large crowds. It may still happen. And Brave has a default shield, and one day will maybe add enough metrics. But neither addresses the IP issue

[Ja-ngolo]

Now that i read all that, it would be amazing to have RFP at least as part of the front facing UI, maybe more people would use it that way.

I think your answer goes above and beyond what I was hoping to get. I cant thank you enough for taking the time to write all that up and deliver such a detailed answer. It is really eye opening and it makes me understand the subject a lot better now that I have read through all of that. I feel like some of those questions just came from me reading posts, and videos from ill informed persons (albeit with good intentions I hope) that just take FPing as this huge, but nebulous, threat but never go into detail or explain what each browser really does to mitigate FPing.

I would say that my threat model is pretty low, mostly just wanting to get away from third parties and advertisers. In that case I'm guessing both of those browsers do the job, or would something as basic as that would ETP + uBO(dynamic blocking) cover enough known FPers that I shouldn't give it much thought?

[Thorin-Oakenpants]

I think your answer goes above and beyond

then marked the discussion as answered, and in future, I do not have time for these basic (for me) discussions, so just point users here in future and leave me out of it (not that you got me involved, that was someone else) - TIA