-
Notifications
You must be signed in to change notification settings - Fork 523
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
FF118+ audio tests #1701
Comments
Release:
Nightly:
Release:
Nightly:
It's Linux. |
Windows, RFP on.
Click:
|
macOS Ventura 13.5 offlineAudioContext Stable: Stable:
Nightly:
keys are the same so I'm not re-posting them. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
PieroV, Linux, Firefox 118.0a1 nightly 2023-08-15:
|
pants I saw you marked the comments as outdated, would you say the mac result is fine or do we need to dig deeper? |
AIUI fxbrit meant
So this would be " |
yeah, the context keys should be identical. I wasn't super clear in my instructions, both are with RFP in the click test fxbrit - marked it as noise because I added a WTF to OP. I was going to come back round to it (and test on my own mac) why not test the click test again
edit: it doesn't really matter, I was just trying to show that it changed. The real test is with the math patches and that looks good. I'll fire up my mac and see what I can wrangle (still grappling with how to run multiple FFs with their own profiles) |
MacOS M2 Pro (ARM): Nightly
Release
|
scrap that, just retested. I must have copypasta'ed the wrong hashes - we're the same |
32-bit Firefox on Windows 11: Nightly 2023-08-16
Release 116.0.3
|
thanks karl looks like "easy" (performant, no user gestures) fingerprinting of offlineAudioContext is two buckets: ARM vs non-ARM? and with RFP, ignoring context keys which is per OS (and we can't hide the OS so this is equivalency), the oscillator non-performant fingerprinting is also two buckets. IDK much about ARM [1], but I guess that's at least a binary split there. We probably can't hide ARM in other tests (IDK, I lack devices) [1] https://en.wikipedia.org/wiki/ARM_architecture_family#Operating_system_support |
sorry for the delay, never got the e-mail for some reason.
isn't you mac ARM? I don't remember if we ever checked for differences in architecture or GPU (webgl) for Apple Silicon and Intel. platform is protected by RFP right? anyway we can do this elsewhere to avoid the noise. |
what is yours?* (so I can update OP). Where do I check on mine? (I've used this mac for like a hour total since I bought it - total mac newbie) I have no clue what I mean when I say ARM. I thought since your mac differed from karlt's and karlt specified ARM as a point of difference (and ARM is expected to cause differences), that this was a mac thing/change with newer models (like M1, M2 - I'm just throwing out words, ignore if I don't make sense) So there is clearly some difference in macs - I just labelled it ARM because I am ignorant |
excellent .. listen to the expert, not me ;) edit: as karl points out: the other thing is the math entropy that was in audio is/was equivalency of (at least?) trigonometric math, which RFP also covers |
my Mac is Intel, IIRC yours is ARM. In general, all newer Macs are ARM and they rock the M-series processor (M1, M2).
which is something you've been preaching for quite a bit right? so all of this sounds like good news and the game is hardening math if I understood correctly. |
Yes. A lot of differences are because of other underlying "causes". So you fix the cause, not the symptom. Or you accept it :) We cannot hide the OS (win, linux, mac,. android), it's impossible with JS enabled. So here for example, RFP sets a different ac-outputLatency for each of the four OSes. So the RFP context keys reveal OS = equivalency of OS (e.g. userAgent) or userAgent RFP uses four results, because compat and we can't really hide the OS. So there are four buckets = equivalency of the actual OS. Capisce? Another example: canvas (depending on how sophisticated your test is) can be a mix of lots of sources of entropy: math, default fonts, font anti-aliasing (e.g. clear type), unicode support, subpixels, default font sizes, and so on. If we made all users have the exact same fonts and nothing else, that would eliminate some direct font fingerprinting, and as a consequence also reduce entropy in canvas.
well then, so it all makes sense, OP is correct :) |
I've added some audio notations (health checks). They do not show unless FF118 or higher. Health check counts should be consistent, so I have to fail them (it alerts us) if they don't match, but of course we do not conclusively know all the results, and for the two oscillator tests, there will be noise/failures from some non-RFP users (but we can determine that on the back end). So technically a red X may be a false positive. I think over time we will get a full picture (and there weren't that many buckets to start with in my opinion from research and others - we may already be there!!) So anyway, ignoring RFP audioContext keys which has been done since around FF72, each of the three have two known hashes which determines if it says top is my win11 FF118 with RFP enabled, bottom is a simulation when it fails our known results. Might come in handy for others, not just TZP/tor project - @karlt FYI |
thanks everyone for submitting results .. here's some 🥧 and more 🍻 |
@abrahamjuliot re abrahamjuliot/creepjs@cdc6951 since FF118 all firefox users should report one of two sums
you only picked up on the first |
OK, didn't do a moz-regression yet (not saying it was a regression, I just use that to pinpoint the bugzilla), but beta124 (and nightly) exhibit at least a new FP for new results for my
@abrahamjuliot cc: @karlt edit: so the change was from Bug 1877221 - Update vendored ffmpeg library to current tip
edit: my ARM phone on FF124nightly and then I did an update and am now on FF25nightly, both didn't change, so I think the patch only affected x86/amd |
So this came up in Tor Browser, and I should have been more vigilant - the https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43212#note_3099854 |
1358149 landed
test 1
offlineAudioContext
FF118+ RFP doesn't matterwas values are FF115-117
test 2
CLICK
test FF118+, RFP = ONwas values are FF115-117 with RFP on
The text was updated successfully, but these errors were encountered: