reminder: wiki page

[Thorin-Oakenpants]

• 1.3.1 FPI/dFPI
• 1.3.2 RFP

And link to them in the implementation page. This is to help the user decide if they want these two things - i.e threat model, what it protects, what to expect in terms of usability/breakage. People seem to be surprised, and yet the list is really small, and can be worked around - everyone's mileage will differ

🔻 FPI

only breaks some cross site logins, e.g. SSOs - either use a different browser for those sites or switch to dFPI now that it exists - e.g. override recipe - pretty simple page

• edit: note: existing FPI site exceptions are keyed by OA

🔻 RFP

🔹 breakage (compat)

• is limited to about three things: canvas (use site exceptions: more on that), timing jank, alt shortcut keys on some sites
• note: should add a pic of a randomized canvas pattern

🔹 usability (not compat issues)

• usability issues as distinct from actual breakage
• issues include timezone, new window sizes (there are prefs), and prefers-color (light/dark). And somewhere in between breakage and usability would be blurry images (due to devicePixelRatio spoof).

Of ~100+ things RFP protects, that's it (will be the other odd item). I'm sick and tired of people claiming (reddit a billion times) that RFP generally breaks everything. Timezone is not breakage. Using en-US is not breakage (and en-US is optional). Prefers light is not breakage. They are expectation issues, not breakage.

There are solutions, but first of all the user needs to decide if RFP is for them = threat model. If they can't handle minor things like looks and feel (prefers-light, non-native widgets, letterboxing etc : yes widgets is not RFP and LBing is separate: just pointing out other FPing examples) then maybe it's not for them. The FPing threat and what RFP can do also needs to be put into context. For most users, just randomizing canvas will achieve the same result in most cases: e.g. just use Canvas Blocker

And something should be said about not undermining RFP protected metrics - like installing Dark Reader. There are solutions - the user just needs to be selective

• just like you can allow a canvas site exception: it won't be used to link all your traffic because
  • one, it's not all sites
  • two: it's only one metric
  • three: canvas alone, depending on the canvas being tested, is usually equivalency
  • four: not all excepted sites use the same canvas test
  • five: not all excepted sites share FP data
  • six: if it's a site you log into all the time, you're already ID'ed (as a repeat visitor)
  • seven: is it even being used to FP you?
• you could do the same for timezone, e.g. use an extension to spoof the timezone as your real one for e.g. just gmail

I laid out something like this for someone else, and despite talking about this shit for years, realized I didn't really have something about it here (it's mostly in the user.js if people looked) certainly not nicely all explained in a nice single wiki page

[Thorin-Oakenpants]

@youdontneedtoknow22 .. I'll answer here (rather than add noise at the other topic) ... and it fits this issue anyway @fxbrit 🐟

I'm interested in this discussion tbh

fxbrit and I haven't said much about it (we're both busy: one private post each on it), and I only stated part of the below in mine - I skipped the parts about FPing + entropy etc as assumed. So this is more of a third iteration, hopefully more structured. I'm sure fxbrit will chime in if he feels the need

---

RECAP

🔻 the real issue

Users do not understand FPing (at least not fully), and they are not expected to. Users get upset at thing like breakage (fair enough), and unexpected consequences (like timezone, prefers-color). Or they don't even know that it's RFP doing it, or do not know about canvas exceptions, and create issues and complain etc. FAIR ENOUGH too .. no one told them anything about how this shit works or what to expect

🔻 the perceived issues

Because they can't make exceptions (except site ones for canvas), they look to either abandon RFP or alter those things (e.g. Dark Reader) - which might make things worse, or not, depending on the metric and how they implement it.

trying to equate Dark Reader + RFP as worse than RFP + prefers dark. I believe this is one crux of LW's argument. I would actually argue that the first is a better solution, just not the best solution available right now (I'm assuming Dark Reader is enabled for all sites). It's a bit hard to quantify, but I can say that scripts check prefers-color (super easy and fast), they don't check for dark readers (more complicated and slower), and that all that is immaterial if you use the best solution (which involves some compromise)

🔻 the reality

RFP ultimately relies on numbers (see technical below about how everything is about lowering entropy), and uptake requires usability. Uptake in Firefox is a bit of a moot point - don't get me wrong, it has lots of benefits (e.g. timing attacks, and certainly can't hurt fingerprinting: you're unique if you do nothing). The reality is really one of threat modelling, and understanding that Firefox is not an enforced set of users like Tor Browser, and that other solutions to FPing exists (like blocking the scripts, and sucking in naive ones that get through)

Dropping RFP means a user loses protection against naive scripts (canvas is a poison pill). They need to be given an alternative, that's all - tell em to use Canvas Blocker's canvas if they can't handle RFP

• edit: note that it is not perfect: extensions cannot protect workers

So there's a fine line between keeping robust protection, and users accepting what they get in return. RFP hasn't really changed for almost two years, since FF68. It took a break at Mozilla due to other priorities. At some stage (it absolutely has not been forgotten), the last pieces will be worked on - the aim is to get RFP front facing (a UI presence), increase usability (site exceptions?, less canvas breakage? better solutions for new window sizes, fixing blurry images, etc) and maybe turn it on for PB windows. Ultimately, they want to have a Tor Browser window mode (and Tor Project to stop putting out a Tor Browser) - these things all take time.

Anyway, the answer to all of that is EDUCATION, and waiting for upstream solutions. Also see my post above about using extensions for select sites. Exposing RFP via the UI is great, and an opportunity to educate (with a learn more link)

🔻 proposed solution

let the noisy uneducated great dirty unwashed plebs and luddite complainers about RFP have on/off toggles for parts of RFP (I'm simplifying - they did raise concerns, it's not final, they want to add locks etc)

---

TECHNICAL

Anyway, away we go, some of which was in my private reply to fxbrit

the proposed "solution" (of allowing users to opt into changing a RFP protected metric) is not a good idea on a number of levels

• technically it universally alters the fingerprint (doh!) .. i.e. changes it for all websites
• it undermines the message about entropy [1]
  • "hey use RFP to protect your fingerprint but feel free to change parts of it"
  • ^ this is a terrible message to be sending to people who don't know (and shouldn't need to know) better
  • one argument is that some RFP protection is better than none, but that's not how it works
    • in developing anti-FP solutions, you work metric by metric to reduce the surface and render each one as useless as possible (taking equivalency, breakage, compat, usability and how much entropy could leak, etc into account)
    • overall, you still need to protect enough metrics to make a difference
    • once you have that (enough metrics covered), you can't deviate or you lose your "herd immunity" - e.g. take RFP (which can be detected in < 1ms) and alter prefers-color (also detectable < 1ms) = undoes ALL the benefits of RFP
  • I'll repeat that: when you have a solution, and you mess with that solution, you wreck the solution, all of it, because FPing is the art of combining enough, multiple metrics, to create entropy as high as possible. RFP has crafted a distinct (unusual) set of values to protect you, if you change one thing, you are now that unsual set with an extra very unusual change
  • ^^ read that again
• giving anyone a means to use it means they will
  • fxbrit mentioned something about making the lock pref harder to unlock .. but it can still be unlocked .. otherwise why have it there
• misunderstanding the actual problem (regurgitating from above, although I wrote this first)
  • the problem is not RFP or fingerprinting
  • the PROBLEM is users
    • what is the threat model
      • most FP scripts would fall for just Canvas Blocker randomizing canvas, add audio randomizing for good measure
      • most FP scripts don't even run (ETP + uBO lists, uBO medium/hardened modes)
      • most FP scripts are not universal or shared (but it's a bit murky out there)
    • users should either not use RFP if they can't handle it, or accept it in all it's glory
      • trust the experts: they have denied requests for years to disable timezone, prefers color etc
  • the ANSWER is education
    • user expectations
    • there are other solutions to carve out a few select site exceptions
• wait for upstream solutions
  • don't hold your breath but experimental RFP tweaks are being implemented in devs' spare time: such as granularity (e.g. all windows, PB windows only, exclude extensions, etc) and RFP site exceptions (e.g. you could exempt gmail, since you sign in anyway, big deal)

[1] entropy: everything is ultimate about lowered entropy, even randomizing. All randomizing can be detected, and rendered to a static value = lowered entropy via the same analyzed value

PS: I typed this out for myself as much as for anyone else, it got a bit long, sorry, not sorry. Maybe I can't be assed adding a wiki entry

[Thorin-Oakenpants]

Indeed. Using multiple profiles, or secondary browsers, is a legit method to reduce breakage - depends on the user's experience. So that could maybe be mentioned in the wiki page - I do need to keep it as simple and short as possible though.

The issue is really about what users can live with in their everyday browsing

• FPI vs dFPI is a no-brainer (if you need SSOs, cross site logins, use dFPI - we have a recipe).
• RFP and fingerprinting is also pretty simple
  • ask yourself if you really NEED it - e.g. is your IP hidden, explain threat model
  • if you can handle RFP, cool
    • don't mess with it universally in any way
    • list breakage, side effects: workarounds/threat model: e.g. maybe use gmail in a secondary browser, or an extension for select sites to spoof the correct timezone
  • if you can't handle RFP, or don't need it
    • [x] turn RFP ALTS into a "DO NOT USE, this is pointless" section
    • direct users to just use CanvasBlocker to randomize canvas + maybe audio spoofing (a secondary random value cannot hurt) - that's all you need

I'm not sure it can get any simpler: assess and either go with RFP or use a minimal effort via CB. Both do the same job at a minimum of fooling naive scripts that may run

[Thorin-Oakenpants]

I don't want to get bogged down with detail. RFP and FPI fundamentally change the browser in big ways. WebGL is a single API - but yes, added specifically for FPing purposes - so maybe that can be added in the can't handle bit: i.e enabled webGL and install CB or something

[fxbrit]

trying to equate Dark Reader + RFP as worse than RFP + prefers dark. I believe this is one crux of LW's argument. I would actually argue that the first is a better solution, just not the best solution available right now (I'm assuming Dark Reader is enabled for all sites). It's a bit hard to quantify, but I can say that scripts check prefers-color (super easy and fast), they don't check for dark readers (more complicated and slower), and that all that is immaterial if you use the best solution (which involves some compromise)

valid points for sure, but on the other end I would like to point out some disadvantages related to using something like dark reader (no knock on them in particular, just to be clear):

• performance: it might sound out of place but we are talking bout a browser, all extension of this kind make browsing kinda slow unfortunately.
• attack surface: one more extension is one more risk, most users don't review the code (can't blame them) and it's always best to be careful with extension, especially ones with particular permissions.
• detection: on this I would ask for you opinion, would you consider possible that naive script are detecting the theming preferences or is it probably more of an advanced thing? despite being fast is it that powerful given that it's either light or dark and is it used often (hard to tell I suppose, and also one could argue back with what you already said about combining metrics and really specific values related to RFP)? I also want to add that installed extensions are detected using javascript but again I don't have numbers to describe how much of a threat that is, but sure it's something to keep in mind and another possible case against dark reader type of extensions.

once you have that (enough metrics covered), you can't deviate or you lose your "herd immunity" - e.g. take RFP (which can be detected in < 1ms) and alter prefers-color (also detectable < 1ms) = undoes ALL the benefits of RFP

I'll repeat that: when you have a solution, and you mess with that solution, you wreck the solution, all of it, because FPing is the art of combining enough, multiple metrics, to create entropy as high as possible. RFP has crafted a distinct (unusual) set of values to protect you, if you change one thing, you are now that unsual set with an extra very unusual change

thank you for breaking that into more details (even more than our previous discussion), I need to let this breath and think more about this (me and the rest of the team) so this discussion is very appreciated. I did consider the fact that you are outside of the RFP-pack by changing that single pref but 'unusual set with extra unusual change' sounds worst. however is it bad enough that you want to give up also canvas protection, timing attacks protection, the small webrtc protection and the good stuff that you get from RFP? that's still my point, despite all the above about fitting in, especially with what you said bout naive scripts (which would probably bring us back to 'just use CB and fuck it').

[Thorin-Oakenpants]

some quick notes

• So... DR has a "Invert listed only" mode
• not going to bother finding them, but about four or five recent reddit threads all mention DR being performant heavy, but there's something like a dynamic mode vs a static mode, and dynamic sucks
• detection: I would consider it something more akin to a boolean: is color being messed with? true/false. It's super quick so I would totally expect this to be in lots of scripts

Extension detection is via two main methods

• behavioral changes in the DOM
• changes in expected js: function names, prototype, property orders etc
• also: leaks: e.g. Cydec gives a lot away
• also: UUIDs bugs

This is different to detection of spoofing/lies, but those too can be used to fingerprint the extension: e.g. how canvas is altered from a known canvas, what items are changed

But after that it can become a bit of a game of number theory, trying to actually state X extension is used, because many extensions show the same symptoms, and multi extensions can be in play. It's also important to remember that some of these can be enabled for some sites and not for others, or the extension randomizes what it being altered - so it's not a perfect FP, but the science of linkifying FPs is a thing, so just because you differ across sites, they can still be linked

Sorry, just dropped in after having a massive poop .. back to the Olympics .. so will add some MOAR later. I think the thing is either use RFP (with whitelisted select only sites for say dark reader, timezone if we can find an extension) or don't bother, just get a canvas + audio randomizer and be a happy little camper - and if you're not using RFP then prefers colors, timezone and shit don't matter etc = you do not need all these extensions, We shouldn't be sending mixed messages.

I'm going to do my wiki page hopefully next week

[curiosityseeker]

I've been using RFP for a long time without serious problems. However, one aspect not mentioned here: If I load with FF 90, e.g., https://www.deviceinfo.me/ it will tell me:

Operating System:
Windows 10 version 10.0 (32-bit), or Windows Server 2016 or 2019 version 10.0 (32-bit)
True Operating System Core:
Linux x86_64

And in the user agent section it reports:

Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

So on the one hand the user agent set by RFP is detected but also the real correct user agent/OS (with the incorrect FF version, though). Doesn't this add entropy? Perhaps not for Windows users but for users of other OSs.

[rusty-snake]

So on the one hand the user agent set by RFP is detected but also the real correct user agent/OS (with the incorrect FF version, though)

• The windows one is the HTTP UA and the linux one the JS UA (navigator.userAgent).
• Tor Browser does exactly the same (because RFP)
• The incorrect version is because it is spoofed as ESR
• https://github.com/arkenfox/user.js/blob/92b7fb81d0ca6bfd58aeca175749b4bd2777ef20/user.js#L1419-L1421
• If you allow JS, your real OS is leaked in any case. You can not hide it.

Doesn't this add entropy?

• If a site compare HTTP and JS UA and you are not using Windows and you allow JS: yes
• If you use a release firefox: yes

[curiosityseeker]

@rusty-snake : Thanks, I was actually aware of that. My remark was meant to add that aspect to this discussion (as it had been not mentioned before) and to raise the question if for non-Windows users it might be better to use Canvas Blocker instead. Thoughts?

[rusty-snake]

raise the question if for non-Windows users it might be better to use Canvas Blocker instead. Thoughts?

• FWIW: https://privacy-handbuch.de/ does not recommend RFP and uses CB instead because of that.
• Some linux distros add extra entropy to the UA send by the firefox from their repositories. At least Fedora does: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0.
• As long as JS is disable (as it should be by default), there is no quick and easy check for the real OS AFAIK.
• If JS is enabled there is already a lot entropy even without comparing data collected on the client with data collected on the server.
• The ESR fake is also detectable. So the discussion also includes windows users.
• What is more likey? Comparing client collected data with server collected data or comparing browser features with said version?
  • It's easy to check if navigator.userAgent says ESR but a feature added ESR+1 was added.
  • On the other hand are there any RFP ware script out there?

[Thorin-Oakenpants]

Doesn't this add entropy?

No. You can't hide your OS. And RFP is not trying to hide (and can't be either). As a set, all RFP users per platform are still identical

[atomGit]

trying to equate Dark Reader + RFP as worse than RFP + prefers dark.

@Thorin-Oakenpants - what do you mean by 'RFP + prefers dark'? is there some sort of native dark mode for the www at large that i missed?

(slightly off topic): Dark Reader is a rather poor solution for making the web dark IMO - you'll find a ton of neg feedback regarding performance issues - Dark Background and Light Text is a better solution IMO - note that exactly NONE of these dark web add-ons work very well, but some work better than others

[Thorin-Oakenpants]

what do you mean by 'RFP + prefers dark'

It's not a Firefox thing - it's something LW wants to do (and in case anyone is not sure .. I find this really STUPID)

For the record, I'm not advocating using any extension. Users should use RFP as is, not undermine it. But first they need to decide if they want or need RFP. If they don't, then there is nothing to discuss. If they do, then they need to accept the consequences.

If they want to work around those consequences, then that's on them. The more I think about it, the more I'm not really interested in telling them the best way how TBH.

[fxbrit]

@rusty-snake said:

Some linux distros add extra entropy to the UA send by the firefox from their repositories. At least Fedora does

that's the result of the Fedora-specific FF version right (the one that ships with the distro)? I wonder if that would be the same if one was to manually install the browser from Mozilla's website, I'd might have to check tomorrow.

[Thorin-Oakenpants]

@fxbrit - firefox direct is not - the user agent changes come from distros because they feel the need to advertise themselves

[Dyrimon]

@Thorin-Oakenpants So here's my dilemma. I use RFP+FPI+Temporary Containers+Canvasblocker(faking all). I want every websites to get unique but random canvas as CB does. But if I use RFP in addition to it will it just rewrite CB and show all sites the Tor fingerprint? Also as all websites are in separate, temporary containers that is nuked when the tab/the browser is closed, maybe FPI is redundant. Unless FPI adds some extra benefit alongside Temp_containers and is perfectly fine to run together? Unfortunately I can't disable JS as it's a pain to reconfigure every sites I visit so I've chosen the CB way.

Edit: Since JS reveals my OS anyway, I don't think using RFP just to spoof your OS to Windows is worth it. I want to keep the extensions as limited as possible.

[Thorin-Oakenpants]

It doesn't "rewrite", RFP doesn't even release the canvas to WebExts, you need to set an RFP canvas site exception. There is no point in doing so unless to need to unbreak something, in which case CB then kicks in as fallback with subtle randomizing.

not sure what you mean by "faking all" - I wouldn't fake anything already covered by RFP (but leave canvas on as fallback). Bad habit, bad practice

Since JS reveals my OS anyway, I don't think using RFP just to spoof your OS to Windows is worth it

RFP doesn't just spoof your OS (it doesn't really), it has a lot of other protections. And extensions leak - your screen can be gained via css pseudo values, canvas, screen, useragent and more can leak via workers ... etc

Up to you if you don't want RFP. In which case, yes, I suggest at least randomizing canvas and probably audio for good measure for any naive scripts that get through - but it's not foolpoof. But you're fucked anyway against an advanced script, so that's not the point of using CB

---

Also as all websites are in separate, temporary containers that is nuked when the tab/the browser is closed, maybe FPI is redundant

That's up to you and how you configure TC - see the wiki

This can achieve almost everything First Party Isolation (FPI) does without breaking cross-domain logins. And (with or without FPI), in a hardened TC setup, this can even isolate repeat visits to the same domain, which FPI alone cannot.

personally, the repeat visit thing is a bit moot - except it's a great way to sanitize eg paywalls - did you change your IP (and cover ALL vectors)?

You could also just use dFPI, it has shims and other benefits - it can't hurt, and TC probably also blocks those cross-site logins should you accidentally click a fuckbook button (but I'm sure you have uBO in some decent config anyway, if not annoyances list which removes, from memory, all those widgets)

[Dyrimon]

It doesn't "rewrite", RFP doesn't even release the canvas to WebExts, you need to set an RFP canvas site exception. There is no point in doing so unless to need to unbreak something, in which case CB then kicks in as fallback with subtle randomizing.

That's exactly what I mean, RFP doesn't even let sites to access my canvas, and I don't bother it to allow either (except some intrusive captcha like puzzle solving slider). I presume only then CB kicks in and randomizes a fake one. But doesn't it stand out more when one user is blocking all canvas extraction instead of giving out at least a fake one? Maybe I should make an exception for CB with RFP. I'm not sure, so would like your suggestions.

not sure what you mean by "faking all" - I wouldn't fake anything already covered by RFP (but leave canvas on as fallback).

here's my CB config (what I mean by "faking" with CB)

{
"logLevel": 1,
"urlSettings": [],
"hiddenSettings": {
"rng": false,
"protectNavigator": false
},
"expandStatus": {
"highlightPageAction": true,
"showNotifications": true,
"blockMode": true,
"section_faking": true,
"highlightBrowserAction": true,
"protectedCanvasPart": true,
"section_settings": true,
"protectNavigator": true,
"fakeMinimalScreenSize": true,
"protectScreen": true,
"protectTextMetrics": true,
"protectDOMRect": true,
"allowWindowNameInFrames": true,
"protectWindow": true,
"historyLengthThreshold": true,
"section_History-API": true,
"useAudioCache": true,
"protectAudio": true,
"blockDataURLs": true
},
"displayHiddenSettings": true,
"whiteList": "",
"sessionWhiteList": "",
"blackList": "",
"blockMode": "fake",
"protectedCanvasPart": "readout",
"minFakeSize": 0,
"maxFakeSize": 0,
"rng": "nonPersistent",
"protectedAPIFeatures": {},
"useCanvasCache": true,
"ignoreFrequentColors": 0,
"minColors": 0,
"fakeAlphaChannel": false,
"webGLVendor": "",
"webGLRenderer": "",
"webGLUnmaskedVendor": "",
"webGLUnmaskedRenderer": "",
"persistentRndStorage": "",
"persistentIncognitoRndStorage": "",
"storePersistentRnd": false,
"persistentRndClearIntervalValue": 0,
"persistentRndClearIntervalUnit": "days",
"lastPersistentRndClearing": 1627063614000,
"sharePersistentRndBetweenDomains": false,
"askOnlyOnce": "individual",
"askDenyMode": "block",
"showCanvasWhileAsking": true,
"showNotifications": true,
"highlightPageAction": "none",
"highlightBrowserAction": "color",
"displayBadge": true,
"storeNotificationData": false,
"storeImageForInspection": false,
"ignoreList": "",
"ignoredAPIs": {},
"showCallingFile": false,
"showCompleteCallingStack": false,
"enableStackList": false,
"stackList": "",
"protectAudio": true,
"audioFakeRate": "100",
"audioNoiseLevel": "minimal",
"useAudioCache": true,
"audioUseFixedIndices": true,
"audioFixedIndices": "16",
"historyLengthThreshold": 2,
"protectWindow": true,
"allowWindowNameInFrames": true,
"protectDOMRect": true,
"domRectIntegerFactor": 4,
"protectTextMetrics": true,
"blockDataURLs": true,
"protectNavigator": false,
"navigatorDetails": {},
"protectScreen": true,
"screenSize": "",
"fakeMinimalScreenSize": true,
"displayAdvancedSettings": true,
"displayDescriptions": true,
"theme": "auto",
"dontShowOptionsOnUpdate": false,
"disruptSessionOnUpdate": false,
"updatePending": false,
"isStillDefault": false,
"storageVersion": 1
}

personally, the repeat visit thing is a bit moot - except it's a great way to sanitize eg paywalls - did you change your IP (and cover ALL vectors)?

that's indeed one of my use cases, bypassing soft paywalls and read limitations, TC works great for that. And of course I try to cover as much vectors I can, VPN with permanent killswitch and uBO with annoyances list.

So, I guess my setup is alright now (RFP+FPI+TC+CB). All I need to be sure that should I use RFP with CB as usual or add an exception to make CB always randomize data. Thanks!

[Thorin-Oakenpants]

RFP doesn't even let sites to access my canvas,

Good. It's doing it's job then.

But doesn't it stand out more when one user is blocking all canvas extraction instead of giving out at least a fake one?

No one is blocking canvas extraction. RFP randomizes, CB randomizes.

[crssi]

@Thorin-Oakenpants What is your opinion on DOMRect and TextMetrics APIs covered by CB? Is it worth? Is the CB WebGL protection good when allowing WebGL?

Thank you and cheers

EDIT: I have found your answer at https://github.com/arkenfox/user.js/issues/767#issuecomment-831229286... sorry to bother you.

[Thorin-Oakenpants]

I'm not entirely sure of all the factors that effect textmetrics/domrect, and my gut instinct is it is mostly equivalency (of language). Maybe clear type, and subpixels (devicePixelRatio) play a role

how many times do I need to say in this thread (and elsewhere) that if you're not using RFP then all you need is canvas and maybe audio. Read the wiki .. also the bit at the end tat says if you don;t use RFP you;re on your own. Extensions leak, but at least they'll fuck up naive scripts

[crssi]

I am using RFP and TC, but not FPI. 😉

Thank you Pants. ❤️

[Thorin-Oakenpants]

So the next step I think is to merge section 2500 (four items max) into section 4500 - maybe 2502 can go to the don't touch section. Then we can refer to, and users deal with, all the fingerprinting items in one hit/section. This would mean sacrificing a parrot 😭

webrtc doesn't fit nicely here IMO ... I don't consider it a FPing item, but rather a leak (yes IP's can link data). And that's OK because the implementation page can say

• shit you need to look at
• hey we clear data (blah blah)
• we break DRM like Netflix (2022), we break WebRTC like zoom (2001)
• we break cross-site logins with FPI (4501) - click here to see if it's for you and alternatives (link to FPI/dFPI page)
• we enable anti-fingerprinting (4500s), click here to see if this is for you and alternatives (link to "RFP/FPing" page)

Whaddaya think. I'm holding off on the FPI page, because it looks like we'll soon be able to move to dFPI with a hardened optional knob, FF94'ish at the earliest

[rusty-snake]

Am I right that network.dns.disableIPv6¹, network.proxy.socks_remote_dns, media.peerconnection.enabled, network.gio.supported-protocols, network.proxy.failover_direct and media.peerconnection.ice.proxy_only_if_behind_proxy are only relevant if you use a VPN/proxy? If so we could make them inactive in a VPN section/subsection of 2600.

¹ This makes IP-based Geolocation more accurate and can leak your MAC-addr if you did not configured your OS to be privacy-friendly.

[Thorin-Oakenpants]

IDK, @fxbrit knows way more than me about networking, but sure, some of these don't really achieve anything if you're not already hiding your real IP - but the same can be said for a lot of other items, like RFP. It's an assumption that you hide your digital IP footprints. They also don't cause any issues AFAIK left as are - except for media.peerconnection.enabled

[fxbrit]

network.dns.disableIPv6 is the only one that I'd like to say and hear something about, in the sense that I don't see a clearly right solution and approach.

imo it is mostly dangerous for non-vpn users that don't have privacy addresses configured by default, so it's mostly a matter of outside browser settings. it remains to be seen how many OSs / distros still ship without privacy addresses. I think privacy addresses are actually good, the linked myth number 5 bashes it because it makes net admins work harder: it is true, but who cares, the same could be said about ipsec for example. for vpn users the main concern is that the provider might do a trash job with ipv6 handling. ideally those who don't need it should disable it at the OS level just to make sure, while those who want or need ipv6 should make sure they pick a reputable provider that provides tunneling or some kind of solution. my biggest takeaway is that it's something that should be addressed outside of the browser.

[Thorin-Oakenpants]

closing, this is being dealt with elsewhere and will land when it lands

[opusforlife2]

It's a bit hard to quantify, but I can say that scripts check prefers-color (super easy and fast), they don't check for dark readers (more complicated and slower), and that all that is immaterial if you use the best solution (which involves some compromise)

@Thorin-Oakenpants I just did a basic code search for this attribute in the repos of both Dark Reader, and Dark Background Light Text.

DR: https://github.com/darkreader/darkreader/search?q=prefers-color-scheme DBLT: https://github.com/m-khvoinitsky/dark-background-light-text-extension/search?q=prefers-color-scheme

DBLT shows no code related to this, but DR does. Does this mean it is safer to use DBLT? I use uBO in hard mode, if that matters.

[Thorin-Oakenpants]

If something touches the dom it can be detected and measured. Why don't you test it. I do not care about people's obsessions with dark themes

[rusty-snake]

https://github.com/arkenfox/user.js/issues/655#issuecomment-771067926

[opusforlife2]

@rusty-snake I've read your comment. I'm just specifically asking if it's better to use DBLT over DR, since it doesn't touch the prefers-color-scheme value, which Thorin says is easily detected. I've quoted that part of the text, so I'm aware that advanced scripts may still detect the extension, which I hope will be mitigated by keeping uBO in medium (or stricter) mode.

[rusty-snake]

ATM Maybe (pants will likely not care and I actually don't care either).

The question is, is this guaranteed or can any update of DBLT change the implementation (because of bug/feature) and become detectable like DR?