-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
what is ETP>Custom>Suspected fingerprinters [A: FPP] #1729
Comments
It's FPP (finger print protection) and is enabled by default in ETP strict mode - see #1716 |
I would assume that running those settings on + addons like CanvasBlocker and JShelter is not recommended? |
we currently use RFP so FPP is not used - RFP overrides it if not using RFP, private browsing windows use FPP, otherwise ETP Strict also uses FPP - the exact releases these are/were/will-be hooked up is not worth me checking - e.g. FF119 hooks FPP to ETP Strict At some point, arkenfox will move to FPP. i.e it will be on by default in all windows because we set ETP = strict. And RFP + letterboxing and webgl will be commented out - but users can add them to overrides and RFP overrides FPP. Simple huh! And with FPP, when it's ready, it does what we want - it subtly randomizes canvas which is good enough for now for a Firefox threat model, and way more compat friendly. Over time FPP will add more and more protections. Hopefully they do something about webgl, because we'll never get that in the RFP world (at this rate, since TB just kinda nuke it) And yes, when FPP is ready and we move to it, even CanavsBlocker will no longer be recommended JShelter has never been recommended, it's a piece of shit - it's so ridiculously dumb (for gecko) it needs to be in it's own museum. dumb
extensions are fucking dumb for resisting FPing - end of story |
lols (yes I changed the title)
reminder #1334 do not ask about ETP Custom |
also #1388 - JShelter is shit - my comments towards the end in several posts |
Interesting, I see that your website detects a lot of its changes while RFP is not detected ... I rememeber in it's infancy RFP broke fucking everything and made browsing the web a chore and unfun - perhaps it's time to give it another whirl. |
ok, so I don't want to get into a discussion about TZP, but it's changed over time, it's basically a non-stop prototype RFP has never tried to hide itself, and RFP can always be detected. I am not marking RFP as lies because RFP doesn't actually lie - that's the Also, I no longer bother to do bypasses. I only did this to show that a lot of "protection" is rubbish, mainly to show all those extensions were shit - bypasses were all done based on the current data, via JS, client side. In reality you can just do this on the backend. This saves a on code complexity I also no longer bother to return a lot of stuff as lies, instead I just try to catch them in errors, e.g. if it's an unexpected typeof or an invalid value, or a timeout etc. All errors are in the errors FP, and the actual FP just returns "error". Errors are not lies, so it helps keep the noise down and simplifies code a little. And the errors help paint methods (e.g. "typeof error got array expected object"). Additionally, all the prototype and proxy lies are a fingerprint - it's not like I need to highlight each metric to show this I also have a smart mode, a basic mode, and a blocked mode. So basically what this does is remove a lot of checks and code complexity by trapping a lot of nonsense as errors which also creates a fingerprint, and by simplifying checks to the current ESR cycle. But don't let any of this let you think that things aren't what they seem. Fingerprints are a snapshot in time and are considered fuzzy, and all the data is there to bypass some (not all) extension nonsense or leaks, especially via service workers (I am yet to add this phase) PS: if you don't know what a test is doing, then don't make assumptions tl;dr extensions are SHIT at fingerprint protection and due to low usage just make you unique - always said you need to use built in browser solutions - see RFP (solid as FUCK but missing webgl), now FPP (which will grow protected metrics), Brave's Shield (also growing but getting quite mature - even if a lot of randomness is bypassed, it still protects the real value or reduces entropy) |
It's only ever "broken" about 5 or 6 things
Things that are NOT broken (i.e the website is not broken). These are usability issues, not compat issues
Quite frankly, being on windows so no mismatched headers/UA, and having 60hrtz monitors, and not being into streaming services or using google docs or whatever - I have zero issues with RFP. That's why you make a choice, as per the wiki. If you can put up with what may break for you, then use it, if not then you have options ^ and of course that option will be moot/reversed, instead it will be we use FPP and the option is to upgrade to RFP + disable webgl + enable letterboxing instead if you can live with it - depends on how you look at it and one assumes you mask your IP, but for now I consider this superior with more protections, e.g. timing mitigations, no averaging of canvas for bypasses, etc end of thread, please don't post anything else |
sorry not sorry |
@privacyguy123 dude, drop it. Tying prefers-color-scheme to RFP is exactly the thing that SHOULD be done
FYI: and I honestly don't know why I'm wasting time typing this, prefers-color-scheme is not an accessibility issue, it is a personal preference - if you can't handle it or understand why, that is not my problem. It's not even a global solution, providing dark + light themes is only arbitrarily used on a tiny fraction of sites (albeit some large ones) and often the dark theme is an |
Noticed this new setting pop up randomly and not sure where better to ask about it.
Any idea what this is doing under the hood?
The text was updated successfully, but these errors were encountered: