FYI: future fingerprinting options #1716
Comments
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 |
What do you mean? |
|
I think RFPLite was an early name for FPO - there is now only one mention of it in code, in a comment
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 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 |
So what happens when I enable both |
|
That UI option was for custom (more on this)
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 |
|
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 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 |
|
I did some quick tests in nightly 119
tests so it seems as if RFP always overrides FPP, but I also think there is a bug - @tomrittervg
|
|
|
I'm not using any RFPTargets, just the four prefs
nope. I repeat |
|
I meant; how are you testing it? I'm using Canvas, what are you using? Can you reproduce it using my canvas page? |
|
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? |
|
it's FPP (FingerPrint Protection) .. anything else is me doing typos (and I just went thru and edited them all in this issue) |
|
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? |
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 If you have RFP enabled, you get all the RFPTargets. No exceptions (unless you have exempted a site with the still-unpublicised So yes, RFPTargets don't really interact with the RFP pref. [face_palm] |
|
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) |
|
PS: search and replace RFPTargets :) please |
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... |
|
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
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 |
|
This is getting confusing again (sticking to nightly). so
So I'm struggling to see where/how 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? |
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 |
How did you set font visibility level? Maybe you will need to set |
|
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 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 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
/*** [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", ""); |
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. |
|
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
We already have a pref to disable all/some compat/shims - under the DON'T TOUCH section Hopefully, and I honestly don't think we need it, 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 |
/*** [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 overridesstill not sure what |
|
PS: @tomrittervg since edit: https://bugzilla.mozilla.org/show_bug.cgi?id=1846224 is where it was removed |
|
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. |
crowds |
This is not true. When it first started (before it came to github) RFP didn't even exist. As per the readme
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 |
I hope you will share them in #1080 eventually. :-) |
|
it's already there - the reverse of |
|
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? |
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)
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)
For our general threat model, it is good enough for most users. This needs a separate comment (coming) |
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 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 scriptsand 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 ... |
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.
Hopefully. The ultimate way of having a sizeable pool of real users to blend in.
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. |
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 anythingNo, we cannot have FPP in normal windows and RFP in PB mode - it's not engineered to do thatwe 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
awe could use FPP mode in all windowsbwe could use FPP in normal windows and RFP in PB windowscwe could relax some RFP protectionsSo 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
adown 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 BrowserOriginally posted by @Thorin-Oakenpants in #1711 (comment)
The text was updated successfully, but these errors were encountered: