Few questions about some prefs [also webaudio FP results] #1216
Comments
Without consent? No, you will always get a prompt from Firefox.
|
I haven't done a v90 release yet, See #1099 for
Not even Firefox, with special built in code, can hide your operating system
RFP protects two of those 20 keys. RFP is on by default. #1194 contains everything you need.
Unless it's an enforced set of users like Tor Browser, then don't do it .. waste of time. The number of results is tiny (by OS and engine) and likely equivalency (but not all buckets will have equal users) - changing it would make you stand out a hell of a lot more. Audio tests
Yes please. Test with and without RFP, just expand the results and post images in a new issue for me - that would be cool. For your android and linux (can you state the distro as well) - that would be awesome |
section 4600 is massively different to RFP itself. 4600 tends to disable APIs, whereas RFP controls them. These two sections are not even in the same ballpark. |
huh? can you elaborate. We added it here for version 84 - it's worked fine for me ever since, and they have made improvements since then as well - see #1047 first post .. v90 for example got an exceptions UI in settings edit: unless this is just an android issue? |
|
Whoa I didn't expected the response to be super quick. With media.navigator.enabled the main thing is I liked how things were before as no prompt needed, no camera or microphone access which is good, as I created new profiles for them. Dom.security.httpsonly mode is android issue. Thanks for WebAudio clarrification. Here are the values in Android With RFP
Without RFP
Edit - I'm sorry I messed up the test as with RFP test is on version 90 and without one on version 91(Firefox Beta). I'll give the new test. |
|
Without RFP on version 90
Without RFP means all the browser data was cleared and no about:config changes or any extensions. |
|
@githubuniqu expand the details as well, so I can see the actual key values :) Just tajke your time. Android with and without RFP. Your linux with and without RFP. damn, still typing and you closed :) Thanks for the tests, these will help @abrahamjuliot ^see above for some FF audio values
I don't want to repeat everything (I had/have plans to create an Everything is about reducing entropy. Raising entropy by randomizing ultimately can be detected and reduced to a static value, e.g. canvas: "randomized". That doesn't mean randomizing is useless - if scripts can't detect that, then they swallow a "poison pill". But ultimately the name of the game is to never reveal the true value (it''s OK if you actually are that value), and to lower entropy. And ideally this should be done with as little web breakage as possible (like canvas breaks images into garbage), or unintended side effects (like the user doesn't expect the timezone to be UTC0 = education needed). If a metric can't be protected because it;s either too complex, or not yet implemented for various reason, another option is to disable the API. Which is what Tor Browser has done with webGL, webaudio, webRTC and media devices (camera, mike).
The things is TB has a different threat model to consider, and RFP is specifically for Tor Browser. Slowly but surely, more is getting added on, even if not specifically for TB. And a lot of things are being done even for non RFP users. Anyway, back to the OS: some items cannot be hidden if a script really wants to know it (OS, engine, version, etc), but that doesn't mean RFP can't try and make it hard. Read the above link and it explains the UA stuff, which pertains to your question about OSes. RFP doesn't try to hide the OS, and in fact spoofs values differently for some metrics based on the OS - such as those audioContext keys. godamn it .. wrote far too much .. I really should start the |
|
PS: the tests between versions don't matter - the diffs are in OS and RFP - if you do any more let me know which results relate to which os, thanks |
Ahh, right. I haven't particularly followed it in android. I looked at https://bugzilla.mozilla.org/show_bug.cgi?id=1613063 and didn't immediately spot a reference ticket, but it rings a bell that HTTPS-Only Mode hasn't been enabled for geckoview yet |
ghost
reopened this
|
ANDROID e8482ba39b760522764695fb0075cb7685787461 [1 metric][ i ] [api] web audio | enabled
|
|
About Ubuntu, well I'm getting different result from the previous one. Here is the one in new created profile without RFP 6e0d66e64d12e600db73a769b918c91ea0f2fa5e [1 metric]
|
|
thanks for the re-tests 👍
hiding a metric is still measurable. let's not get too complicated, but essentially if you do nothing you will be unique. if you do your own thing trying to hide, you will be very likely still be unique (except for poison pills). You cannot beat all fingerprinting - the goal is make enough metrics useless that it becomes impossible to linkify your traffic with certainty. Since all metrics ultimately rely on lowering entropy, it therefore can only properly succeed when large sets of users do the same thing. arkenfox doesn't claim to defeat FPing. RFP doesn't either. Even Brave doesn't (it only says it fools naive scripts). The only browser that does this successfully, and says it is doing this, is Tor Browser - because it's a large set of users with all the same enforced protections. Tor Browser's antifingerprinting is 90% RFP, 5% some pref flips (webgl, webaudio etc), and 5% their own stuff. They don't guarantee FPing is fully defeated, but it's been proven super robust and only getting better.
No worries. Prompt fatigue is a PITA (I never see it TBH) .. but it's your choice/threat model, do what you like. The user.js is just stating prefs and facts - e.g. the fact that geo is behind a prompt means it's not a risk, and the fact that setting it to default deny is fingerprintable and disabling the API is fingerprintable. You can assess that how you like: e.g
:) |
|
@githubuniqu If you care about prompts, have a look at the |
Thorin-Oakenpants
changed the title
In the latest version 90 release dom.webaudio.enabled and media.navigator.enabled are changed. I noticed it when I updated Mull from F-Droid main repo today and visited browserleaks.com to detect changes which I normally do when browser gets updated in desktop and in Android(yes Arkenfox user.js file works in Android and as a regular user I can confirm it works pretty darn good), well in this case Android first. So both prefs were detected in JavaScript and WebRTC browserleaks pages respectively, as before WebRTC page showed all values null and JavaScript showed WebAudio null which is not the case now. I don't use this website to see if I'm unique but to detect changes between updates like dom.security.httpsonlymode stopped working in version 87, before that it was working fine in Android.
When I visited the section 4500, there is some explanation for media.navigator.enabled being removed, but I still don't get it. With that pref being disabled, I was relaxed(maybe false security before) that no website can access camera & microphone. So that has gone now means websites can access them or I'm not seeing things properly?
I'll admit I don't pay much attention to Github discussions as I'm not a developer, just a casual user, and so I missed whole discussion in #1194
By doing the test in Firefox 90 in Ubuntu, the audio context value differs from what reported by other users(2glops) on Linux. The audio context value is 573f84633bd0a02ab6da198fbe4879f28b5d2f77 [20 keys] without RFP
All other values are same(without RFP). I honestly don't even know what that means, but mentioned it coz its different and is potentially a raised entropy. I can provide values for Android too if needed.
I would like to ask one question, can a linux user using user.js file fool the website in believing that he is using windows as that can make things for me clear? Because that's what I believed RFP and other values in user.js does which is reducing the info about hardware and software to a minimum in desktop and Androids.
Plus why these two values in RFP alternatives section as enabling them reports different values from RFP in version 90. I never paid much attention to this section but believed that values in the section would bridge some gap from no RFP to RFP. With these two prefs there is another ground. Of course I might be wrong.
I don't see any harm in webaudio being disabled as audio in all websites worked fine and it differs between OS. Plus in that discussion although it was mentioned - not for Android, but things are different there. Is disabling WebAudio a good idea in Android?
Just don't say things like only few users do it or percentage as I prefer to disable prefs which are in some way connected to hardware, coz percentage of users doesn't apply there, like for any chromium browser. And please don't dismiss this as no discussion for Android. And don't consider me a troll, I just created a new account and have some doubts for something I use daily.
The text was updated successfully, but these errors were encountered: