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", ""); |
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. |
If you have a PoC that bypasses FPP canvas, then let Mozilla know, and don't assume what I said
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
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
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
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 |
|
https://canvasblocker.kkapsner.de/test/test.html |
|
it appears so
|
|
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 |
|
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
|
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... |
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)
|
|
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? |
|
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 |
|
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. |
|
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 |
|
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? |
|
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 |
|
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? |
|
Not always, but sometimes there is a leak in "Service".
|
|
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 some FPP examples
|
|
^ ping! @tomrittervg reminder .. next reminder in 1 day :) Edit: RFP works like a charm, no leaks - random execution every time |
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: