Effort towards a common browser fingerprint

[PhysicsIsAwesome]

Hi,

since fighting browser fingerprinting is only reliably possible in a crowd of users with the same setup, a community effort is needed to make users more homogeneous.

The Arkenfox wiki in its current state leaves a lot of space for individualization, for example by explicitly saying that this is only a template and users can adjust it to their needs or by leaving it to the user to decide which of the recommended extensions to choose from.

Simply using RFP is not enough to fight fingerprinting. You could get fingerprinted by changed settings or by your extensions and their settings, for example which ad blocking lists you use.

I don't know how many users Arkenfox user.js has, but I assume, that even though it is one of the most popular ones, it's still not that many in absolute numbers. If these users then get split up into even smaller subsets by using different extensions or changing settings, it is in the end not unlikely that users end up being unique.

From what I have read so far and looking at TZP @Thorin-Oakenpants seems very knowledgeable in terms of browser fingerprinting. I would be interested in your opinion on this topic and if we could create a solution, by clearly stating a common fixed anti-fingerprinting setup in the wiki, including extensions and their settings, for all users, that want be part of that crowd and value a common fingerprint more than individualization, but for some reasons don't want to use Tor browser as their everyday browser.

Best regards,
PhysicsIsAwesome

[Thorin-Oakenpants]

🔴 Peacock365 is an ignorant troll

scroll down to see the details of his ignorance, hypocrisy and trolling

---

I will address this another day, but are some quick notes.

• on second thoughts, I think this might be it, since I ended up writing so much
  • such a wide general question, ughh
  • so much BS and FUD from the peacock

---

First of all, arkenfox has never claimed to defeat all fingerprinting, but it does help reduce it.

Fingerprinting is not the main aim here - it is security and privacy: think of all the ways sites can track you with persistent storage, cross-domain chatter, and a dozen+ other methods. This is what the bulk of trackers use (and some will also tinker with FPing) - a long established methodology with large data brokers and infrastructure already built for harvesting/buying/real-time bidding etc - cookies + site data + uuids + cross-domain = catches 95% - the rest is generally not economical or worth it

So please don't mischaracterize arkenfox or think its something it doesn't claim to be. It is about privacy and linking traffic (yes FP can link traffic - but there are many ways to reduce this - think tracking protection, uBO etc)

That said, fingerprinting is taken into consideration - but you (as in the readers/users) need to understand how fingerprinting works - what do the scripts actually do (metrics, are they naive or various levels of advanced), what is it's purpose (legit? or benign e.g. the reddit one is only used by reddit for bot detection?), does it matter if you log in, how is it shared to link traffic and whose script is it and how is it linked (universality e.g a script bundled inside a FB widget would be scary - but think of the perf hit to millions of sites, when they can just embed a fucking cookie), who does it (I think it's about 10% of top sites and then rapidly falls off to nothing), how do they do it (partyness and other tricks), is it a known script already blocked? - I've written about this before: scripts need to be universal, and a fingerprint is just a snapshot in time that can be manipulated after the fact, and that scripts are rare and most are naive and most never make it cross party, if at all.

The biggest problem with fingerprinting is that you are still giving away an IP, even if you use a VPN and hop. That IP is collected and can be used to link same VPN known IP ranges, and correlated with timestamps. IP fingerprints don't have to be precise, they can just be "AT&T Detriot" or "Shady VPN" - modified after the fact.

So even if you had a fingerprint that was in a large bucket of users - the IP or IP behavior is going to totally wreck that - and IP is trivial to collect

The only solution against advanced scripts is going to require solving that IP problem - such as using tor - which is why Firefox want to introduce a Tor Mode Window (and Tor Project to stop putting out a browser) - this is still in the pipeline, but requires changes at Tor Project - such as latency and a dozen other items [1] - because you can't go throwing open the floodgates at the tor network by adding a potential 217 million users - off the top of my head the tor network runs at about 30-50% capacity and has 2 or 6 million daily users or something

[1] I spent a week with the Tor Project guys at a Mozilla All-Hands back in 2019, and their whole time there was finishing up the pitch/ideas for eka on what needed to be done to get this Tor Window Mode. It's going to take time, and has not been forgotten

Also, people have threat models, and easily have multiple browsers. Nothing is stopping them from using Tor Browser for some traffic - it's not a be-all end-all.

That said: there are different levels of FPing (legit one-offs that pose no threat, naive thru to various levels of advanced), but ultimately the aim is to render enough metrics as useless in a given set of users (such as Tor Browser) as well as solving the IP problem in order to defeat even advanced scripts. However, that does not mean that rendering some metrics as useless doesn't improve things - because, levels of FPing.

---

since fighting browser fingerprinting is only reliably possible in a crowd of users with the same setup

this is simply not true

against advanced scripts this is highly likely true but also relies on other factors

by explicitly saying that this is only a template and users can adjust it to their needs

because no-one size fits all - users will get different mileage, and have different threat models - USERS ARE MEANT TO READ IT AND MAKE SETUP CHANGES and heed the descriptions and warnings

---

it is in the end not unlikely that users end up being unique
You could get fingerprinted by changed settings

Again, arkenfox is not trying to defeat all fingerprinting, and doing nothing you are already unique on desktop. Fonts and screen are almost enough, now add webgl where sophisticated images (with fonts and other factors like emojis and a dozen other items) and not to mention all the entropy in vendor and parameters and values etc can get upwards of 95% uniqueness (on desktop), now add timezone and language and locale and formatting (which !== the same as Intl. necessarily) all the way down to binary results like prefers-color-scheme = you are already unique

Additionally, there are large chunks of prefs specifically not active (i.e not commented out) left in with information not to change them because they don't achieve anything (security/privacy/tracking) except change your fingerprint .. including whole sections

But it doesn't really matter given most users threat model and what the actual threat of FPing is right now - low.

or by your extensions and their settings, for example which ad blocking lists you use.

Show me what in the list of extensions in the wiki alters FPs that isn't a net gain (e.g. the benefits of uBO FAR outweigh any possible FP threat of some random non-universal script) and what is the threat that anyone would bother to try and FP these if they could or if the "metric" is stable and can be used for linking, and is universally run on websites

The Arkenfox wiki in its current state leaves a lot of space for individualization

I assume you mean the user.js not the wiki - NO it doesn't leave a lot of state that changes FPing - but that is NOT the aim

Show me of all the changes in arkenfox, excluding webrtc and webgl and RFP - where it makes FPing any worse = it can't, you're already unique, and claims that a shitload of them do alter your fingerprint, is incorrect and doesn't take into account

• the threat model
• the stability of the metric
• the cost/benefit (computational costs are both client and server side) of trying to FP it
• among other things

---

🔴 Peacock365 is an ignorant troll

don't listen to him, all he wants to do is argue for attention, and try and drag arkenfox into every conversation - and he misquotes out of context (like my example of chrome zero days was bookended by warnings that THIS IS NOT HOW IT WORKS) and just likes to make generalized sweeping statements

this is all he could come up with, out of 170 odd pref flips

• and he's a hypocrite: I bet he changed things in his browser that are FPable, and that his browser doesn't do anything more than RFP (i.e fool naive scripts)

Suggests disabling WebGL (<1% of all Firefox users)
Suggests disabling IPv6 (<1% of all Firefox users).
Suggests disabling favicons (<1% of all Firefox users).
Suggests disabling disk cache (<1% of all Firefox users).
Suggests disabling TLS1.3 round-trip data (<1% of all Firefox users).
Suggests disabling SVG OpenType Fonts (<1% of all Firefox users).
Suggests modifying the referrer header policy (<1% of all Firefox users).
Suggests disabling WebRTC (<1% of all Firefox users).
Suggests disabling service workers (<1% of all Firefox users).
Suggests disabling support for push notifications (<1% of all Firefox users)
Suggests disabling third party cookies to be set (<1% of all Firefox users)

Remembering that arkenfox's primary aim is not FPing, lets have a look

UTTER BS

• favicons - arkenfox does not block favicons
• referrer header policy - is at default
• IPv6 disabled
  • 65% - of users can't even use IPv4 - https://www.google.com/intl/en/ipv6/statistics.html
  • 80% - of sites don't use IPv4 - https://w3techs.com/technologies/details/ce-ipv6
  • lets look at Firefox stats: go here , click on GC_MS and type IPV and select IPV4_AND_....
    • 80% of connections are IPv4 out of 420 million samples at the time of writing
  • as explained in the user.js: we block it at the app level as a fallback, just like anyone interested in privacy would block it at the network or OS level, especially with a VPN
• disk cache
  • and how and who is going to do that. People clear caches all the time. Using a PB/incognito mode window has no cache. Network partitioning of cache also increases the chances the cache isn't used (all those common 3rd parties on each site). This is not a stable metric, no one is going to use it
  • also, disabling DISK cache doesn't mean their is no cache (in session)
• push notifications - is a duplicate of service workers being disabled
  • also, not stable: users can set site exceptions
• 3rd party cookies
  • LOLs - what does uBO do a lot of
  • also not a stable metric

sure, but not likely

• TLS1.3 round-trip data
  • IDK, why bother FPing this, can you FP it? never really thought too much about it, it's a security measure
• svg openfonts
  • when was the last time you saw an svg opentype font? be honest
  • when was the last time you saw it in a FP script

these actually help

• webgl
  • do nothing and it is basically game over (see my comment about sophisticated tests), disabling it until RFP adds it is a surprisal - i.e a net gain towards making a metric useless, which is how you defeat FPing, metric by metric until there isn't enough left (assuming large buckets) - i.e it reduces the attack surface (and entropy) so much that the result is better than if you did nothing - this sounds counter-intuitive but depends on the metric
    • for example: you would think that if you disabled JS, that would make you stick out, but in reality the entropy for each JS metric would be the same: e.g. screen may have been 5, but with JS off you are 9 (so worse, right?). But so is timezone, and everything else, so your entropy is 9 for everything. With JS on your overall entropy was probably 18
    • this same principle applies to all the metrics and entropy that webgl's attack surface offers - and its a shitload
• webRTC
  • is there to protect local IP leakage
  • debatable - and under review. webRTC has changed a bit as has the threat, @fxbrit and I have been talking about if the last month. Android and Win7 users don't have mDNS but mac users do. Linux from memory should. I am not sure exactly how much entropy can be gained here - needs more info, but sure, the API is FPable, big deal for now
• service workers
  • an absolute MUST until they are isolated by dFPI (soon) as this is integral to blocking tracking
  • it's also the same you would get in PB mode, and you cannot reliably detect PB mode anymore (but you can with a high degree of certainty), and soon that will be impossible as well (PB mode is getting IDB and SWers)
  • its not that stable

And none of all his nonsense changes the facts

• that most scripts are naive
• that most scripts cover few metrics
• that most scripts cover simple fast metrics not hard-to-do costly ones - a lot of PoCs are great but not mainstream
• that most scripts are blocked
• that some of these listed items are not stable
• that some of these listed items are flat out false - READ THE FUCKING USER.JS
• that some of these listed items are just not worth bothering with in the arms race (yet, if ever)
• that arkenfox doesn't claim to defeat all FPing
• that arkenfox does reducing FPing (if a script gets through and runs)
  • that RFP (extensions are not as good and lack APIs and leak in workers) beats naive scripts
  • that uBO (recommended) and ETP block fingerprinters
• that RFP covers almost enough metrics to match Tor Browser - which is how you defeat FPing, metric by metric until there is so little left it makes no difference - which is why webgl is disabled (surprisal) = this is as close as you will get to fooling advanced scripts (but hey, enable them if you need them, because threat model etc - also, IP)
  • fooling ALL advanced scripts is not the primary aim of arkenfox and is impossible - we need to wait for RFP
  • fooling naive scripts is a gimme with RFP, so that part is a primary aim you could say
• that he is a hypocrite - if he thinks Brave protects his fingerprint any more than RFP, he is deluded

edited: typos

[Thorin-Oakenpants]

feel free to comment, but i'm closing

[KOLANICH]

The easiest way to achieve the same environment fingerprint is to take some lightweight distro, put it into a VM and aggree that everyone will use the browser through that VM image. The problem is it would protect only from environment fingerprinting but won't protect from hardware fingerprinting and mandatory backdoors (a.k.a TEEs, it is almost everything ready to require internet users to use devices with TEEs, i.e. https://arxiv.org/pdf/2110.07954.pdf )

[KOLANICH]

The main problem with all these privacy protecting technologies is discrimination against users using them (or even worse, against users not using the privacy-violating technologies of The Owner Of The Internets). I constantly face it.

[Thorin-Oakenpants]

I agree - the bot detection arms race is a scam and RFP/TB get hammered (plus ooh scary think of the children scaremongering for Tor Exit nodes)

[Thorin-Oakenpants]

@PhysicsIsAwesome you might also want to read #1218 where the idea is to succinctly lay this out in a wiki page so users can decide

• is FP a threat I am worried about
  • yes -> can I live with four or five RFP side affects and learn how to use a canvas site exception
    - yes -> carry on
    - no -> add Canvas Blocker with random canvas and audio and maybe screen
  • no -> disable RFP

[Thorin-Oakenpants]

Here's a pretty good list of STATE tracking

• https://privacycg.github.io/storage-partitioning/

Arkenfox is primarily concerned with STATE tracking (and cross-origin of them) - which is all the things that need to be "partitioned", some more than others e.g. double keying and scheme. Arkenfox has used this strategy since FPI first came out. Now dFPI is here (with a heuristics pref) and is probably more robust (FPI is not maintained and will be dropped). I'm not sure what FPI/dFPI are lacking in, except for dFPI's service workers. Interesting that the list includes WebRTC and webGL

Note that it also says that some of these can be and are blocked on occasions such as Cookies or as happens today for Storage in opaque origins

Arkenfox is also concerned with STATELESS tracking but not at the expense of STATE - anyway it is largely out of our hands (see IP, see enforced large set of users where people don't change things) - but we enable RFP as the most robust solution (it is built into the browser and fully tested/vetted - extensions lack APIs) and this alone fools naive scripts (assuming a script gets to run and even then the damage an advanced does is limited to it's universality) and does not require any crowd

state > stateless .. get over it you trolls :)

Anyway, I found that list and sharing is caring

[Thorin-Oakenpants]

FYI if you didn't already know about it -> https://privacytests.org/

[PhysicsIsAwesome]

Thanks for taking the time and explaining in great detail. I need to read more into this, especially state tracking, and also get more of a feeling for how common and important the different forms of browser related privacy threats are in the wild, before commenting.

[Thorin-Oakenpants]

sometimes I wish I could reply (can't be fucked with an account) - https://old.reddit.com/r/firefox/comments/qz1po6/question_about_aboutconfig/hljmmco/

Those guides are kind of useless in the grand scheme of things. arkenfox user.js is more extensive than the privacyguides/privacytoolsio guides, but even the main guy working on that is pretty clueless about the stuff he's doing.

The thing is, you'll never really effectively prevent fingerprinting on a browser that's not designed to do so by default, and that's the main thing these "guides" try to accomplish. Either stick with the built-in privacy protections (i.e. ETP Strict mode with perhaps some addons) or just go straight to Tor.

Privacy communities on reddit have always been more about larping than actually helping anyone. That's my take on the issue, at least.

First, we say (in numerous places including the user.js itself) to go use Tor Browser

Secondly we push built-in browser solutions (and recommend fuck all in way of extensions)

Third, we have never claimed to beat all FPing. Only 4 or 5 prefs are to do with FPing, and they help reduce it (robust built-in browser solution for naive scripts, and ETP's FPers blocklist - as well as uBO)

Once again, FPing is not the main thing this guide tries to accomplish - and this girl knows far more about fingerprinting than some rando on reddit making false assumptions - I really wish people would FUCKING READ before they open their mouths - as if early adopters of features and the other 95% of prefs have no any meaningful bearing on his one asinine stupid and false example, and they don't actually increase privacy

[crssi]

Would you like me to reply just with a link to your answer here?

[Thorin-Oakenpants]

@crssi nah, no need (pointless discussing things ad infinitum with every comment on the internet) - and he/she is not wrong about the how to defeat all FPing - just annoying that he/she jumps to conclusions about arkenfox and doesn't consider that there are degrees of FPing and considers it basically all pointless because of something orthogonal

[Thorin-Oakenpants]

excellent link - https://old.reddit.com/r/PrivacyGuides/comments/rum0qg/firefox_arkenfox_userjs/hr0q6vw/

[ToxicSmurf]

Who is Peacock365?

[rusty-snake]

https://github.com/Peacock365

[crssi]

@rusty-snake Peacock365 does not have any public repository. 😉