search

arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
10.02k stars 514 forks source link

FYI: future fingerprinting options #1716

Closed Thorin-Oakenpants closed 7 months ago

Thorin-Oakenpants commented 1 year ago

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

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 https://github.com/arkenfox/user.js/issues/1711#issuecomment-1698488246

Thorin-Oakenpants commented 1 year ago

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

KOLANICH commented 1 year ago
  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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Thorin-Oakenpants commented 1 year ago

I did some quick tests in nightly 119

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

tomrittervg commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

PS: search and replace RFPTargets :) please

tomrittervg commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

This is getting confusing again (sticking to nightly).

so

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

example

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 commented 1 year ago

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

I think so, or FPP is hardcoded

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 commented 1 year ago 
* 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 commented 1 year ago

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

Thorin-Oakenpants commented 1 year ago

this is a draft

so it's very sparse. The all windows FPP setting is controlled via ETP, so I can't add that. The pbmode is redundant and at default, so is only there for info purposes. The css font vis pref is not usable for us. So all that really matters is the overrides

We could spin this off into a new topic to refine it further. I am thinking of a timeline of adding this info in 119, and assuming most bugs are ironed out with the default settings FPP settings, turning it on for 120 (i.e RFP etc becomes inactive). RFPTargets are not recommended - and I don't particularly want to support them, same as tom - make people jump through hoops - you should either use RFP or FPP as is - choose your threat model.

Thorin-Oakenpants commented 11 months ago

FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1862195

So I mentioned earlier, handy wavy because WIP, that FPP will have remote overrides per site for compat reasons - mozilla do not want to break anything for end users since it is on by default in PB windows and ETP Strict. Thus our users could silently have something relaxed on specific sites - which is not directly a FP issue as this is global and only rarely/selectively per site. But something like canvas is currently the only randomized feature for naive scripts ...

So yeah

There's probably a pref to disable Remote Settings entirely

We already have a pref to disable all/some compat/shims - under the DON'T TOUCH section

/* 6009: enforce SmartBlock shims [FF81+]
 * In FF96+ these are listed in about:compat
 * [1] https://blog.mozilla.org/security/2021/03/23/introducing-smartblock/ ***/
user_pref("extensions.webcompat.enable_shims", true); // [DEFAULT: true]

Hopefully, and I honestly don't think we need it, a pref to control FPP remote overrides is just that - only FPP ones

tomrittervg commented 11 months ago

Hopefully ... a pref to control FPP remote overrides is just that - only FPP ones

Yeah, the pref would only control the remote overrides that come from Remote Settings and those only affect FPP. Users who use RFP are unaffected by any override prefs or Remote Settings. Users who use custom FPP with privacy.fingerprintingProtection.granularOverrides or privacy.fingerprintingProtection.overrides would set the to-be-created pref to disable the Remote Settings aspect.

Thorin-Oakenpants commented 11 months ago 
/*** [SECTION 4000]: FPP (fingerprintingProtection)
   RFP (4501) overrides FPP

   In FF118+ FPP is on by default in private windows (4001) and in FF119+ is controlled
   by ETP (2701). FPP will also use Remote Services to relax specific protections on a
   per site basis for compatibility (pref coming).

   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", "");

/* 4002 ***/
// privacy.fingerprintingProtection.granularOverrides  ???

/* 4003 ***/
// pref to disable using remote services list of per site FPP overrides

still not sure what granularOverrides pref does

Thorin-Oakenpants commented 11 months ago

PS: @tomrittervg since javascript.use_us_english_locale is no more in FF119 (and this is not an issue for TB/MB), we've been left exposing our locale - and since it's also not a FPP thing, I'm guessing this is low priority

edit: https://bugzilla.mozilla.org/show_bug.cgi?id=1846224 is where it was removed

amiracle717 commented 9 months ago

So if I am understanding this correctly.. The user.js is going to move toward just FPP? Because I do not like that. RFP is much better, and still very usable besides a few edge cases where you would need to use something less restrictive. If you ask me I would prefer RFP in both modes, and directing users to create a seperate profile with FPP for the few sites that would require it, but I suppose some people just can't be bothered to do anything themselves..

Anyways I don't like this at all because it greatly reduces the crowd size for those of us using RFP. The whole point of this project is to create a crowd to blend in with. And then you go and screw us with a less-secure default so that either you use neutered FPP or use RFP and stick out even more. I don't like it at all. Things like 'use mullvad' are sidestepping the issue. Mullvad is great but its akin to using tor browser for everything, but sometimes we want to use extensions or customize our browser, and that is counterproductive on a browser like mullvad. Essentially it seems like you are just telling us users who care to go eat rocks and use mullvad or, god forbid, tor, instead of having the nice user.js crowd to blend into.

The best thing to do would at least be FPP in normal and RFP in private browsing. I hate private browsing because of the way I can't save history per session, which is useful to me, but I would at least consider that better than being stuck with FPP.

rusty-snake commented 9 months ago

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

crowds

Thorin-Oakenpants commented 9 months ago

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 commented 9 months ago

So I for one will be adding overrides to use RFP

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

Thorin-Oakenpants commented 9 months ago

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

monsieuremre commented 8 months ago

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 commented 8 months ago

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)

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 commented 8 months ago

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

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 commented 8 months ago

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 commented 8 months ago

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

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'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 commented 8 months ago

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

Thorin-Oakenpants commented 8 months ago

it appears so

canvas FPP window open

tomrittervg commented 7 months ago

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 commented 7 months ago

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

In the same browser (nightly) with ETP Standard

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

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

conclusion

tomrittervg commented 7 months ago 
* 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 commented 7 months ago

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)

opusforlife2 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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