Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FYI: future fingerprinting options #1716

Closed
Thorin-Oakenpants opened this issue Sep 2, 2023 · 54 comments
Closed

FYI: future fingerprinting options #1716

Thorin-Oakenpants opened this issue Sep 2, 2023 · 54 comments

Comments

@Thorin-Oakenpants
Copy link
Contributor

Thorin-Oakenpants commented Sep 2, 2023

oh, I should also mention that in the future we will be able to have two different mode of FP protection, and RFP will be able to have some protections disabled

So the first is we will be able to use RFP in normal windows, and FPP in private windows. FPP is a work in progress (and almost ready). Initially (more will be added) will subtly randomize canvas, audio has been normalized for all users in FF118+, it returns 0 for window/screen positions (I think) and it will use font vis level 2. So in effect, if something is totally fucked in normal mode, you can just flick it open in a PB window. FPP will also have compat rules - so they can ship an unbreak per site (i.e not apply e.g. canvas on site A) - but these are very basic protections so far and shouldn't break anything

No, we cannot have FPP in normal windows and RFP in PB mode - it's not engineered to do that

we can only have a mix of these in this config: normal windows FPP, pbmode RFP


For RFP itself, we can create our own set of what to apply globally - using RFPTargets. Since the main emphasis of RFP for us is fooling naive scripts, then relaxing some of the others is not as much of a concern. Personally I think it's a bit silly - RFP is an all-in or nothing approach, at best it could have three levels (like brave's FPing shield levels - off, standard, aggressive) and per site. But I get the engineering side of it, where all those RFPTargets allow crafting compat rules, and these FPing protections will slowly start to creep into FPP - edit just to be clear, compat rules are only for FPP

So AF moving forward has some options with defaults and override recipes

  • a we could use FPP mode in all windows
  • b we could use FPP in normal windows and RFP in PB windows
  • c we could relax some RFP protections

So for example, for RFP, if you have a monitor where the FPS !== 60 and it causes videos/animations etc dropping frames, you could modify the pref to apply all but timing protections.

https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/RFPTargets.inc

I think I will go with option a down the track. While I do think RFP (no exceptions to targets) is best (the more metrics protected, the better the chances, plus it has timing mitigations), this really is best suited for a crowd and a different threat model - use Mullvad Browser, Tor Browser

Originally posted by @Thorin-Oakenpants in #1711 (comment)

@Thorin-Oakenpants
Copy link
Contributor Author

I think I will go with option a down the track

So this will likely be around FF120+. And the reasoning is that RFP users are going to likely want to add some RFPTargets, so by default we can be lax, and RFP users can add an additional override

Anyway, have at it, discuss, talk, bitch, scream, act like experts :) .. have at it

Sidenote: The HTTP header + navigator UA mismatch issue is not "properly" solved with RFPTargets - you can fix the mismatch but you lose the RFP protection - i.e you have to relax both. This is not the solution anyone is looking for upstream

@Thorin-Oakenpants Thorin-Oakenpants pinned this issue Sep 2, 2023
@KOLANICH
Copy link

KOLANICH commented Sep 2, 2023

  1. Is FPP (the name you use here) and RFPLite (the name used in source code and somewhere on Bugzilla) the same thing?

a we could use FPP mode in all windows
No, we cannot have FPP in normal windows and RFP in PB mode - it's not engineered to do that

What do you mean?

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Sep 2, 2023

I think RFPLite was an early name for FPO - there is now only one mention of it in code, in a comment

we cannot have FPP in normal windows and RFP in PB mode

This is what I was told 4 months ago, by tom ritter. Maybe I misunderstood, or maybe things have changed. You could always test it by pref fiddling - there's two RFP and two FPP prefs, one each for all windows and one each for pb windows - the all windows prefs edit if true, as per usual, tend to override the pb window prefs

privacy.resistFingerprinting
privacy.resistFingerprinting.pbmode

privacy.fingerprintingProtection
privacy.fingerprintingProtection.pbmode

I didn't bother to try and follow any of the engineering or reasons. But clearly if they're both true in all windows, something has to give

@tomrittervg if you want to add anything

@Jee-Hex
Copy link

Jee-Hex commented Sep 2, 2023

So AF moving forward has some options with defaults and override recipes

a we could use FPP mode in all windows
b we could use RFP in normal windows and FPP in PB windows
c we could relax some RFP protections

Anyway, have at it, discuss, talk, bitch, scream, act like experts :) .. have at it

So what happens when I enable both privacy.resistfingerprinting and privacy.fingerprintingprotection? Will RFP takes precedence over FPP? I am asking because a new Suspected fingerprinters option landed in 118 (bug 1841097) and I wonder what would happen when FPP is added to ETP Strict (that would be bug 1841104).

@Thorin-Oakenpants
Copy link
Contributor Author

That UI option was for custom (more on this)

so what happens

IDK, did you test it :) We'll have to wait and see how things shake out, no need to waste energy now only for it to change. I haven't bothered to test anything and won't until it's ready - i.e they announce it. There's a few release note comments on various bugzillas so I suspect some items might be announced in 118/119 - not really tracking it, seems to me that none of it should be announced until it lands in stable as always on for PB mode - as a set of protections

Anyway, back to AF choices. Without testing, I was hoping the combo of those four prefs would be enough to do what we want, otherwise we could always force a ETP custom

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Sep 2, 2023

btw, the way I have tested (I used it to check out canvas in FPP) is to load https://arkenfox.github.io/TZP/tests/canvasnoise.html

you want all reds - if it's per execution (and around 400 cells, and includes alpha channel) it's RFP, it's cached (and should be around 100 10-100 cells) it's FPP

I should probably create a simple RFP or FPP test page - added to my massive ToDo list

edit: holy crap .. it's only around 10 cells changed (out of 400) - that's ultra subtle

edit 2: ok, varies, got as low as 8 and as high as 100

@mik0l
Copy link

mik0l commented Sep 2, 2023

https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/nsRFPService.cpp#100-108

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Sep 2, 2023

I did some quick tests in nightly 119

  • every pb mode test was done in a new pb window (and other pb windows were closed)
  • every normal mode test was done in a new tab after closing the others
  • there are 16 possible combinations
  • seems like I got the message back to front, we could (assuming a bug) have FPP in normal mode and RFP in pbmode, but not the reverse

tests

       all    pb          all     pb
       ---    --          ---     --
- RFP true,  true  | FPP false, false | both rfp
- RFP true,  true  | FPP false,  true | both rfp
- RFP true,  true  | FPP true,  false | both rfp
- RFP true,  true  | FPP true,   true | both rfp

- RFP true, false  | FPP false, false | both rfp
- RFP true, false  | FPP false,  true | both rfp
- RFP true, false  | FPP true,  false | both rfp
- RFP true, false  | FPP true,   true | both rfp

^ so as long as privacy.resistFingerprinting = true, everything uses RFP
^ and RFP always overrides FPP

---

- RFP false,  true | FPP false, false | normal = nothing, pbmode = rfp
- RFP false,  true | FPP false,  true | normal = nothing, pbmode = rfp

^ so RFP always overrides FPP

- RFP false,  true | FPP true,  false | both rfp <- bug?
- RFP false,  true | FPP true,   true | both rfp <- bug?

^ something is not quite right, methinks. the last two should use FPP in normal mode

---

- RFP false, false | FPP false, false | both nothing
- RFP false, false | FPP false,  true | normal = nothing, pbmode = fpp
- RFP false, false | FPP true,  false | both fpp
- RFP false, false | FPP true,   true | both fpp

^ when rfp is off, fpp works as advertised

so it seems as if RFP always overrides FPP, but I also think there is a bug - @tomrittervg

  • RFP is set only for pbmode but causes normal mode to also use it
  • I would have expected both these to be normal windows = FPP, pbmode = RFP
- RFP false,  true | FPP true,  false | both rfp <- bug?
- RFP false,  true | FPP true,   true | both rfp <- bug?

@tomrittervg
Copy link

  1. RFPLite is a dead name, FPP is the correct name for what we briefly called RFPLite.
  2. The more restrictive option (RFP) overrides. So the intention is that RFP is enabled globally (i.e. no pbmode) then RFP is enabled everywhere no matter what any FPP is. If RFP is enabled in pbmode, then it is enabled in PBMode no matter what any FPP the setting is. The last combination is that FPP can be enabled globally, and RFP can be enabled in PBMode, which will give you RFP in PBMode and FPP in normal mode. This is what you arrived at in your most recent comment.
  3. I cannot reproduce your bug. If you can, could you file a bugzilla bug with your repro steps? It might be a bug with the specific RFPTarget you're testing with. I enabled RFP.pbmode and visited https://ritter.vg/misc/ff/canvas.html in normal and PBMode and get the expected canvas behavior in each.

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Sep 2, 2023

I'm not using any RFPTargets, just the four prefs

The last combination is that FPP can be enabled globally, and RFP can be enabled in PBMode, which will give you RFP in PBMode and FPP in normal mode. This is what you arrived at in your most recent comment.

nope. I repeat

- RFP false,  true | FPP true,  false | both rfp <- bug?
- RFP false,  true | FPP true,   true | both rfp <- bug?

@tomrittervg
Copy link

I meant; how are you testing it? I'm using Canvas, what are you using? Can you reproduce it using my canvas page?

@g-2-s
Copy link

g-2-s commented Sep 6, 2023

Whoa slow down please. RFP stands for ResistFingerPrinting, right? What does FFP stand for? Also is it FFP or FPP (which I would understand better as FingerPrintingProtection), or is that a completely different beast?

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Sep 6, 2023

it's FPP (FingerPrint Protection) .. anything else is me doing typos (and I just went thru and edited them all in this issue)

@Thorin-Oakenpants
Copy link
Contributor Author

https://bugzilla.mozilla.org/show_bug.cgi?id=1777614#c5

Now this is getting a bit messy. I thought RFPTargets were for RFP @tomrittervg - I get that you can also leverage them in FPP (so when you expand protections you can ship interventions per site for compat). Now you're hinting that RFP isn't supported (officially) in RFPTargets?

@tomrittervg
Copy link

Now this is getting a bit messy. I thought RFPTargets were for RFP @tomrittervg - I get that you can also leverage them in FPP (so when you expand protections you can ship interventions per site for compat). Now you're hinting that RFP isn't supported (officially) in RFPTargets?

The two hardest parts of computer science: resiliency, naming things, and off by one errors.

In hindsight, a better name for RFPTargets would really be FPTargets to make it clear they are generically 'Fingerprinting Targets' or possibly FPPTargets to make it clear that they only affect the FPP feature.

If you have RFP enabled, you get all the RFPTargets. No exceptions (unless you have exempted a site with the still-unpublicised privacy.resistFingerprinting.exemptedDomains pref - in which case you get almost zero targets. There's a couple exceptions like RoundedWindowSize.)

So yes, RFPTargets don't really interact with the RFP pref. [face_palm]

@Thorin-Oakenpants
Copy link
Contributor Author

that's fine if that's how it's engineered .. buuuuuut there was this push/idea to exempt things like timezone and prefers-color-scheme (all those people on bugzilla moaning, and moz dev comments about this very thing) and even examples in comments in the code, your in fact :)

not complaining .. just saying the whole thing has been extremely confusing and hard to follow at times

PS: you could change *UTC name to something else since we're going to use a real timezone in future (UTC, GMT aren't really used the real world and trigger fraud bots etc)

@Thorin-Oakenpants
Copy link
Contributor Author

PS: search and replace RFPTargets :) please

@tomrittervg
Copy link

that's fine if that's how it's engineered .. buuuuuut there was this push/idea to exempt things like timezone and prefers-color-scheme (all those people on bugzilla moaning, and moz dev comments about this very thing) and even examples in comments in the code, your in fact :)

Yeah, but to preserve the 'pureness' of RFP, we're making people who want to do that of jumping through the hoops of (1) Switch to FPP (2) Make FPP behave like RFP (3) Remove one thing at a time from FPP...

It made sense to me when we started working on it...

@Thorin-Oakenpants
Copy link
Contributor Author

no worries. the initial name was RFPLite.

I couldn't understand why you would do that (allow RFP targets) on RFP, because I've always said it's an all-in buy-in with no exceptions so "the crowd" looks the same (well, equivalency and all that, minimal buckets). I wasn't worried about TB because they could lock it down

But for FF I was like WTF but at least it appeases all those people who want to turn off one or two protections and since it's not on by default or user facing, then so be it, at least they have random canvas. RFP is for TB but it has lots of benefits in FF

(1) Switch to FPP (2) Make FPP behave like RFP (3) Remove one thing at a time from FPP...

Now I see where this is going. We're going to move to FPP anyway. It's a better fit for FF (e.g. subtle canvas), but understandably lacking (it's early days) - the good thing is at least there is e.g. compat-friendly subtle random canvas.

We have options and I understand the mechanics of it a lot better now, thanks

@Thorin-Oakenpants
Copy link
Contributor Author

This is getting confusing again (sticking to nightly).

so

  • FPP is enabled in PBM (and ETP Strict but let's ignore strict)
  • FPP so far includes font vis and random canvas (audio = for everyone, math = everyone on nightly/beta for now)
    • ^ I don't think I missed anything at this stage
  • PBM also ships with font vis restrictions regardless of FPP
  • The FPP restriction is set, I think, by adding two font targets (base, supplemental)

So I'm struggling to see where/how layout.css.font-visibility (default 3) fits in properly 1847599

example

  • start in normal mode, no RFP, ETP = standard
  • test in normal mode: for me on windows, using TZP
    • layout.css.font-visibility = 3 = 189 fonts (all windows supplied fonts btw)
    • layout.css.font-visibility = 2 = 172 fonts (all kBaseFonts + kLangPackFonts)
    • layout.css.font-visibility = 1 = 79 fonts (all kBaseFonts)
  • so far so good
  • set layout.css.font-visibility = 1
  • test in a PB window and it fails, we get font-vis level 2 results

Is this expected? FPP is enabled which uses vis=2 but we set the master pref to use 1. Is there some least restrictive thing going on here to ensure FPP is as compat as possible?

@Thorin-Oakenpants
Copy link
Contributor Author

Is there some least restrictive thing going on here to ensure FPP is as compat as possible?

I think so, or FPP is hardcoded

  • font-vis = 1, normal window, FPP on via ETP Strict, I get font-vis 2 results
  • font-vis = 1, normal window, FPP on via FPP pref, I get font-vis 2 results

And AFAICT this pref is ignored by RFP. Seems like a redundant pref, but I'm clearly missing something - I mean they just added it

@Jee-Hex
Copy link

Jee-Hex commented Sep 30, 2023

* FPP so far includes font vis and random canvas (audio = for everyone, math = everyone on nightly/beta for now)
  
  * ^ I don't think I missed anything at this stage

* PBM also ships with font vis restrictions regardless of FPP
* font-vis = 1, normal window, FPP on via ETP Strict, I get font-vis 2 results

* font-vis = 1, normal window, FPP on via FPP pref, I get font-vis 2 results

https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/nsRFPService.cpp#102-110

How did you set font visibility level? Maybe you will need to set +FontVisibilityBaseSystem (and -FontVisibilityLangPack?) in FPP overrides?

@Thorin-Oakenpants
Copy link
Contributor Author

Thanks Jee-Hex. So see https://bugzilla.mozilla.org/show_bug.cgi?id=1849903 and the patch - it sets targets for adding font vis protection to PB mode (this has nothing to do with FPP) - which is what you linked to. I had already seen this 👍

Ignoring RFP. What I was testing was the pref layout.css.font-visibility in various configs. E.g. no protections in PB windows, FPP enabled in normal/PB windows etc.

I'm not going to try and find it again (there's about 2 dozen font tickets re font vis recently) but essentially, I am 99% sure there is no longer a way to change RFP font vis (good), and FPP font vis "looks" the same [1]. And the layout.css.font-visibility pref only seems to work if you are not using RFP/FPP.

So my question was, really, what is the point of adding the pref to arkenfox. For testing it's handy, and there would be edge cases where you want to apply that to normal mode (no RFP, and PB mode is default FPP) - so similar to what Safari does and probably where Firefox will end up (for windows/mac - linux is too dicey)

[1] I haven't dived into the RFPTargets yet - I was testing the pref. But RFPTargets are engineered to remove things so you could harden it e.g. "+AllTargets,-FontVisibilityLangPack"

FYI

  • this is a draft
/*** [SECTION 4000]: FPP (fingerprintingProtection)
   RFP overrides FPP. In FF119+ FPP is controlled by ETP (2701) and uses webcompat (2702)

   [WARNING] DO NOT USE YET: THIS IS A WORK-IN-PROGRESS

   1816189 - subtly randomize canvas per eTLD+1, per session and per window-mode
   1826408 - restrict fonts to system (kBaseFonts + kLangPackFonts) (Windows, Mac, some Linux)
      https://searchfox.org/mozilla-central/search?path=StandardFonts*.inc
***/
user_pref("_user.js.parrot", "1400 syntax error: the parrot's bereft of life!");
/* 4001: enable FPP in PB mode [FF114+]
 * [NOTE] In FF119+, FPP for all modes (7106) is enabled with ETP Strict (2701) ***/
   // user_pref("privacy.fingerprintingProtection.pbmode", true); // [DEFAULT: true FF118+]
/* 4002: set FPP overrides [FF114+]
 * Controls what protections FPP uses globally, including "RFPTargets" (despite the name these are NOT used by RFP)
 * e.g. "+AllTargets,-CSSPrefersColorScheme" or "-AllTargets,+CanvasRandomization"
 * [NOTE] Be aware that not all RFP protections are necessarily in RFPTargets
 * [WARNING] Not recommended. Either use RFP or FPP at defaults
 * [1] https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/RFPTargets.inc ***/
   // user pref("privacy.fingerprintingProtection.overrides", "");

@rusty-snake
Copy link
Contributor

The whole point of this project is to create a crowd to blend in with.

crowds

@Thorin-Oakenpants
Copy link
Contributor Author

The whole point of this project is to create a crowd to blend in with

This is not true. When it first started (before it came to github) RFP didn't even exist. As per the readme

The arkenfox user.js is a template which aims to provide as much privacy and enhanced security as possible, and to reduce tracking and fingerprinting as much as possible - while minimizing any loss of functionality and breakage (but it will happen).

That privacy bit meant FPI (now dFPI) and sanitizing to limit state tracking. And limiting navigational and other sneaky tracking (think windows.name, ETAGs etc... ) ... and over the years as RFP came on and canvas was randomized, the ability to help limit stateless tracking. RFP does come with extra benefits (more on that below). Firefox isn't going to be a crowd unless it's front facing and built in and used by large numbers. RFP is not going to cut it. So the only hope here is long term that FPP starts adding more and more protections - in the meantime it's good enough - it's default in PB mode + ETP strict - and soon PB mode will look identical to normal mode (i.e with service workers, cache API, etc) - so that's literally millions and millions of users (at least) - this is your crowd, just needs more metrics protected

tl;dr: RFP doesn't have a crowd in Firefox

As for what arkenfox does (and yes, most likely it will move to FPP by default), remember that it is a template - but usability is also important. For those who want it, all you have to do is add some overrides. So by default most people won't need to change much at all, and those who more likely to understand and want RFP and be more tech lit (not that's it's fucking hard or anything) can flip RFP on. I don't really see any downsides.

Personally, I get zero breakage from using RFP, and RFP does offer some extra benefits: with advanced scripts that don't get sucked in by random canvas, it may help to have a large number of metrics the same as some other users - not all scripts are the same, so who knows. And upstream and via tor project I am trying to get protections more compat (such as mismatched userAgents on mac/linux, we already upped the dpi spoof to fix blurry images, we already bumped newwin sizes, we're looking at changing from UTC since it's not real world and triggers fraud bot detection, and maybe using subtle canvas (in FF, or depending on TB security settings, or exceptions), we'll see, it's been brought up in talks and not pooh-poohed etc - all driven by me, you can send me some money later 😁 ). And of course there are timing mitigations. So I for one will be adding overrides to use RFP

so that's my recommendation - if you want RFP then go for it - without any RFPTarget changes (otherwise you are defeating the purpose)

or use Mullvad Browser, or use Tor Browser

@theltalpha
Copy link

So I for one will be adding overrides to use RFP

I hope you will share them in #1080 eventually. :-)

@Thorin-Oakenpants
Copy link
Contributor Author

it's already there - the reverse of I don't want RFP

@monsieuremre
Copy link

IMO the ideal setting would be using RFP in PB mode. Unfortunately this is still broken. Trying to set this enables RFP in all windows. There is also no way that I know of to set letterboxing on PB mode only too, when RFP is on.

Do you think FPP is actually good enough to replace RFP (in arkenfox style usage)? My observation is that it is solid for audiocontext and passable for canvas (not really actually, it is pretty much brave style resistance, but still something). But there are also the billion other small things that RFP covers that are not covered with FPP, like I/O devices and time zone even and so on. The pool for RFP on firefox is already non existent almost, so I'm not sure if enabling it is worth the potential breakage, especially when something not as solid but still decent can be achieved with FPP. The wiki mentions that RFP is still good even if the pool is small to non existent, because what matters is to protect real metrics. In this logic, RFP is still the preferable option, no?

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Jan 24, 2024

Unfortunately this is still broken

I don't know if I edited my comments elsewhere, but I have corrected myself in a few threads

there are four prefs, I will call them RFP, RFP.pbm, FPP, FPP.pbm (with strict mode FPP is essential on)

so here are the two scenarios in FF123+ (with it working as intended + with ETP Strict)

  • RFP on + the rest don't matter = RFP everywhere
  • RFP off + RFP.pbm on = FPP in normal mode, RFP in PBM

so long story short, you get what you want next release. I personally wouldn't have minded it the other way round (RFP normal windows and FPP PB windows - that way to unbreak troublesome sites you could just flick open a pb window - but that's not how it's been engineered for reasons)

So this is a kinda OK setup if you want it - because at least it would give you a very different (static) FP in PBM va normal windows, but of course you still have your IP to worry about (and I'm not talking about how PBM has some diffs such as missing service workers, etc - that's all being worked on)

Personally though, I am going to suggest, as per the next PR with the FPP section, that you should just stick to FPP everywhere if that is what you use, because then you will look like all those other users in PBM (on those metrics) - this is all a bit wishwashy me saying this because see the next post about RFP vs FPP (it's not a competition)

Do you think FPP is actually good enough ...

Lets just start with the first part - is it production ready? There are still bugs for improvements - for example 1852738 was fixed FF124+ - there are others which I won't bother to dig out - but in general they enabled it for all PBM users and all ETP Strict users (RFP permitting) a couple of releases ago so I would say yes - I have just been holding back on it whilst it matures and they add more mechanisms (such as unbreaking sites - exemptions, a bit like compat stuff, not really following it too closely)

... good enough to replace RFP

For our general threat model, it is good enough for most users. This needs a separate comment (coming)

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Jan 24, 2024

RFP in PBM but FPP in normal mode (available FF123)

a little more on that

treating IP as separate: I think you can assign a different IP to PBM with Mozilla's VPN? otherwise this is a gaping hole - i.e we start in normal mode (tons of benefits), then flick some sites open in PBM. Otherwise (and I am not talking about extensions, but system wide VPNs) you would really want to change your IP (IPs can be fuzzy such as knownVPnServiceX and are definitely part of an overall FP, I just always treat it as a different tracker vs say JS client side)

I also want to ignore the part of PBM vs normal windows differences at the moment (excluding FPP being in it). Service Workers, cache API, indexedDB (done), etc (there's more such as persistent clearkey usage) are being worked on to make PB more compat friendly and ultimately make them "indistinguishable" - and at the moment most of those diffs can be changed in normal mode to make normal mode look like PBM, but this is unlikely, so just detecting SWers and a few other windows properties is enough to declare with 99.9% confidence that it is a PBM window. But let's ignore that, as it's being worked on as a consequence, not a goal.

Let's also ignore the fact that all PBM windows now have FPP (detect subtle canvas randomizing). This directly flies in the face of the "goal" of making PBM indistinguishable from normal mode - again with a large degree of certainty (from firefox defaults) - if FPP is detected (known pixel tests and no proxy/prototype lies from extensions). Hence it's counterintuitive and why I said the "goal" in quote marks (hint, it was a goal to make them the same in regards to compat and discrimination by websites, but ultimately it was never stated to make then super FP-diff proof - and FPP is a net gain for PBM not a loss). Maybe one day FPP will be enabled for normal mode


so

  • ignoring pbmode diffs due to SWers etc
  • ignoring the IP
  • noting that the default is FPP only in pbmode (via default ETP Standard strict and by default in pbmode)
  • noting that we will have something in normal mode (FPP via ETP Strict or RFP)

So I said this was "kinda" ok because effectively having two different FPs is a little nuts and doesn't make a lot of sense to me: i.e FPP fingerprint in normal mode, and RFP fingerprint in private window mode

The key here is there is a crowd, so do you want to match the FF crowd here, it's a nice thought (i.e in your PB windows you match everyone else's protections). This ignores the fact that we have other prefs such as disabling webgl (you really need this if you use RFP anywhere) - and any script that can distinguish FPP canvas from RFP canvas will run rings around basic FP metrics. So you'll never really be the same

So I'm torn. There's a lot of variables going on here. And I'm just typing this out as I drink think. At the end of the day, you do you, but I think it's best to stick to one mode. And this entirely ignores the fact that advanced users can mess about with RFPTargets (which I don't want to get into right now)

If you can handle RFP then user RFP, it you can't then use FPP - I don't see what you gain from RFP in PBmode only, ot just makes compat harder (and by choosing FPP in normal mode, you decided you couldn't handle it) - does that make sense?

And of course, FPP in private mode will match all other FF private mode users regards fingerprint protections - not saying it's enough protection, it will ramp up - I'm just saying the method RFP-vs-FPP is a FP - and ultimately you need a crowd

And that comes down to what I have always said, see wiki, that the best FF can do is fool naive scripts, because they don't have a crowd (RFP), and if they do have a crowd (FPP) they don't cover enough metrics. And that crowd isn't on in normal mode. Thus ultimately if you want any website compat and usability (retain some logins, history etc) you need normal mode, and you are not in a crowd - so once again, the best you can do is fool naive scripts

lemme repeat

the best you can do is fool naive scripts

and that almost answers the question on which is better (it's not a competition). I've talked about this before: RFP covers more metrics and has timing mitigations which are very important but comes with compat costs. FPP is very limited at the moment but super compat friendly and will grow in time. And scripts are not just two types: naive and advanced. I think the scripts that matter today mostly detect random canvas are are not fooled, so are "advanced", but not all advanced scripts are the same. So the more you protect (even without a default crowd) then better your odds (probably)

So it's really a preference up to you: if you can live with RFP use it, if not use FPP. You certainly can't do nothing, I personally have no issues with RFP, but I can certainly see e.g. jank and timing issues with non-60Hrtz monitors being painful to the point of not using it. This is not Tor Browser, you are not forced to used RFP.

And so what I will be doing is making the RFP section inactive as an optional "hardening". So by default AF users lose 95-99% of their compat issues and only those who read and know the pitfalls will enable it all.

I like using RFP because it means I get to test it and improve it and I have no major issues. I also use multiple browsers (and so should you) I have dev, beta, nightly and AF'ed stable. Usage is 90% stable (I could easily up that but I like the second nightly window plus using nightly more enabled to spot bugs), 9.9% nightly (for a bunch of things plus one off troublesome sites like HN links than reader mode doesn't remedy), and 0.1% beta for other shit. I also have Dev and "clean" stable releases - and the entire lot are configured to sanitize everything on close. Fuck profiles, use browser instances! :)

tl;dr: FPP everywhere by default, optionally use RFP everywhere if you want, otherwise use Tor Browser or Mullvad Browser - that's my recommendation. Anything outside that is just messy and doesn't make logical sense to me

imma going to stop here ...

@monsieuremre
Copy link

so long story short, you get what you want next release.

Good to hear. It still wouldn't be optimal tho because letterboxing is still all in or no, there is no way to have it only in PBM like RFP.

Maybe one day FPP will be enabled for normal mode

Hopefully. The ultimate way of having a sizeable pool of real users to blend in.

If you can handle RFP then user RFP, it you can't then use FPP - I don't see what you gain from RFP in PBmode only, ot just makes compat harder (and by choosing FPP in normal mode, you decided you couldn't handle it) - does that make sense?

Yes that makes sense. I can handle RFP but FPP seems like a viable option. The reason I said RFP in PB would be better is, in my mind, FPP is just another randomizer for scripts. Canvas randomization with RFP could not be circumvented by any tests I could make, but FPP can be, with some elaborate JS code, tho really unlikely to be encountered in real life.

I think overall you are right. In the future, sticking to FPP all the time might be a better idea. It seems maybe even you might choose to go with that for arkenfox... It is decent. And for use cases where you want real big time fingerprinting protection, RFP on firefox won't and can't give you what MB or TB can give anyway.

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Jan 31, 2024

but FPP can be, with some elaborate JS code

If you have a PoC that bypasses FPP canvas, then let Mozilla know, and don't assume what I said above below as gospel - maybe they can improve against averaging or it is a bypass cc: @tomrittervg


It still wouldn't be optimal tho because letterboxing is still all in or no

Not everything is hooked up and some things are broken (such as spoof english - i.e broken in FF, not TB)

In terms of letterboxing, it's an edge case where I believe it's the only one completely separate from RFP. If you disable letterboxing it won't affect RFP, and you should be able to rely on RFP's newwin sizes for your one off PBM windows

FPP seems like a viable option

Absolutely. Without a crowd the best you can do is fool naive scripts (e.g. randomize canvas and they don't check for that: see amiunique, you are always unique - but see coveryourtracks and it will always return a stable result for canvas)

FPP just needs to grow to be more effective. The more randomizing the better the chance a script becomes naive. The more metrics protected, the better for advanced scripts in a crowd. See my basic three rules in the wiki. 190mn or whatever FF users will provide a lot of PBMode/ETP-Strict traffic

FPP is just another randomizer for scripts

it will do more in time - it's a WiP. It's also more performant and does not leak via various types of workers, and does not affect prototype/proxy lies - extensions are shit at this job, FPing protections need to be built into browser code

Canvas randomization with RFP could not be circumvented by any tests I could make, but FPP can be, with some elaborate JS code, tho really unlikely to be encountered in real life

So RFP totally destroys canvas (you see those wavy/stripey patterns) because it has no mechanism to protect the seed. FPP does a subtle randomizing so as to be usable. Both have fingerprints - i.e FP the anti-FP methods (channels modified, movement of values, % of pixels modified etc).

When Brave added canvas randomizing, I was able to bypass it in various degrees

  • first in workers (they missed them)
  • then because not all channels were randomized - from memory the cached eTLD+1 spoof would assign a session channel, so if the first image only changed the R in RGB, then you knew all subsequent images (for that session) only the R channel would be unreliable.
    • this meant several different attacks such as using a single known color in one corner and monochroming the rest, and fixing the affected channel to match the others, so you could still get lots of entropy in font rendering, anti-aliasing, kerning, etc all-in-one in a single (or two) tests
  • also, I found the amount of pixels randomized was too low (IMO) - it's all a bit hazy now
  • I mentioned these things to Mozilla for when they implemented so as to not make the same mistakes, not that they need my help (probably) :)

and this ignores the fact that you can average - you can't use the exact same image, it's cached, but there are simple workaround for that - but that is not the aim of FPP, unlike Tor Browser/RFP. FPP has to be usable/compat friendly - and only FPP has the engineering (for now) for caching seeds etc

Looking at FPP using https://arkenfox.github.io/TZP/tests/canvasnoise.html

  • it always changes at least some of R G and B
  • collisions mean sometimes it changes combos of RG or GB etc or even RGB
  • it varies wildly as to the number of pixels altered: of the 400 in the test I get as low as 19 and as high as 182 (on a couple dozen reruns)
  • it changes the value between -3 and +2 (or +3), not sure

It's fairly wild as compared to Brave (not tested in ages, and it;s not on my new machine, and IDFCare about blink)

That said, it can be averaged, but as you pointed out, it's probably not likely in the real world - it's performant heavy and more likely targeted IMO - and this is the threat model e.g. FF compat + model vs TB protect at all costs assume advanced adversaries

@mik0l
Copy link

mik0l commented Feb 3, 2024

https://canvasblocker.kkapsner.de/test/test.html
Leak in "window.open Test"

@Thorin-Oakenpants
Copy link
Contributor Author

it appears so

canvas FPP window open

@Thorin-Oakenpants Thorin-Oakenpants unpinned this issue Feb 4, 2024
@tomrittervg
Copy link

Hm. I couldn't reproduce that exact issue, but I did observe something else screwy that hopefully is the same issue. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1878716

@Thorin-Oakenpants
Copy link
Contributor Author

are you sure that in your test the window.open value isn't the real one (hence it would explain that they are the same) @tomrittervg

in every possible circumstance, I cannot get windown.open to NOT be my real value. I used ESR102 as a point, since earlier versions (FF97+ I think from memory) use a different canvas compression but has been stable since


control: this is returned in

  • 9b45ad26c922396f0d84b4d18ede3c43e1029d4e177f7857788474aacddbda59 is MY real value
  • ESR102 normal mode (well before there was any FPP code)
  • Nightly with ETP Standard in normal mode

In the same browser (nightly) with ETP Standard

  • normal window: real value everywhere
  • PBM window
    • random hash in automated tests: f8b3b84978096ac7079d9967bc327cf1b5101833b0e173e84ccfc87f496bce89
    • window.open: real value
  • close PBM window, new PBM window (or reset with End Private Session button now that bug is fixed)
    • random hash in automated tests: e.g. 39d7edd4fa9fc147581c76c4a846cafe379f9a46e8c6ce3e79b6a2b3b75af665
    • window.open: real value

In the same browser (nightly) with ETP Strict (so FPP everywhere)

  • normal window:
    • random hash in automated tests: e.g. 0437372507affcac29f1cb1c8ab7639e712e87d342aec6708d5742d4ca550814
    • window.open: real value
  • PBM window
    • same as before: random but cached per PB session

In the same browser (nightly): start in PBMode (+ ETP Standard or ETP Strict)

  • one
    • random hash in automated tests: e.g. a7334c9971c46b54d87ca2e2fd9d6a06cb909cb1e413ac3a084d343dbb99062b
    • window.open: real value
  • close and reopen
    • new random hash in automated tests: e.g. 5ab358b748ba86f85effaa959afff46f59ca6a4637c274c2ae1e25ec2c155bd3
    • window.open: real value
  • hit End Private Session button
    • new random hash in automated tests: e.g. c40740e173df744a06a1ad7d56f11cf93b91ff53dd5eb820e0fe9791f979f0d3
    • window.open: real value

conclusion

  • everything BUT window.open is randomized correctly per session per window-mode type
  • window.open is NEVER randomized

@tomrittervg
Copy link

* everything BUT window.open is randomized correctly per session per window-mode type

* window.open is NEVER randomized

I concur :) I have a dirty patch that fixes it, but I need feedback from Tim to figure out if we want to go that route...

@Thorin-Oakenpants
Copy link
Contributor Author

I have a dirty patch

the good news is RFP canvas works here, but I guess it's a different engineering path with the seed - but then surely detecting if a protection should be applied would be in common? IDK ... you're the one paid the big bucks 😁

PS: thanks @mik0l for pointing this out

On a side note, I plan to add more canvas tests to TZP - it just hasn't been a priority since I'm focused on RFP which is solid and because we have CB's test page (linked to on TZP)

  • solid color tests (FPP exempts this, RFP doesn't but we would like it to)
  • window.open
  • offscreen canvas
  • convertToBlob .. etc
  • ^ so everything is in one place: this is top level document only at this stage, the entire TZP will eventually also have iframe and various worker tests, and manual window.open tests, for everything (not just canvas) under the sun in the future

@opusforlife2
Copy link

You've given a tentative milestone of version 124 or 125 to make the switch. Is that when you expect the feature to stabilise, or is that the time you expect to take to fully understand the implications and incorporate it into AF? Or something else?

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Feb 8, 2024

well, I could do it next release - I'm just giving users a lot of heads up

edit: it's not like we're in a hurry, we've lived and used RFP for 4+ years or whatever, and users who disable that already have FPP (because we use ETP Strict) - it's not life changing, AF is after all a template

@opusforlife2
Copy link

I hope it's at least after you've finished your condensed write up on the differences between FPP and RFP so that users are able to make an informed choice.

@Thorin-Oakenpants
Copy link
Contributor Author

the differences can be counted on two fingers (or one hand at most) - see the wiki and use some logic :)

I'm not exactly planning on explaining "differences" - the basic rules (see wiki) have not changed. The choice is yours, use RFP if you can live with it, if not then be happy with FPP. If your threat model requires it, use TB/MB. Doesn't get any simpler

@opusforlife2
Copy link

The wiki seems straightforward enough, but reading through this issue raises a couple questions. Is it as simple as FPP + extra privacy = RFP? Do buckets come into the picture at all or is that only for Tor Browser?

@Thorin-Oakenpants
Copy link
Contributor Author

FPP cannot and never will be RFP, even if you enable all RFPTargets - so lets get that straight. If you want to look like RFP people (who do not have a default crowd) in FF on the metrics it's protects then you need to use RFP, period, end of.

also ... buckets always exist .. everywhere, all the time, forever

@opusforlife2
Copy link

That doesn't really make it clear. Let's pose it this way: Does AF v125 user John Doe get more privacy protection by sticking to AF defaults (hence FPP), or by manually flipping RFP on?

@mik0l
Copy link

mik0l commented Feb 25, 2024

Not always, but sometimes there is a leak in "Service".

  1. Start browser and paste into the address bar https://abrahamjuliot.github.io/creepjs/tests/workers.html
  2. If there is no leak, close browser and return to step 1.

@Thorin-Oakenpants
Copy link
Contributor Author

OK, so I can confirm (nightly 125) - the result in SWers sometimes (I get it almost every time) is not randomized

@tomrittervg see STR in previous comment

this is without FPP
noFPP

some FPP examples

diff1

diff2

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Feb 27, 2024

^ ping! @tomrittervg reminder .. next reminder in 1 day :)

Edit: RFP works like a charm, no leaks - random execution every time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests