It’s definitely something a website can detect (the website just has to try to run some webassembly and see that it’s not blocked), so it changes the fingerprint a website can build of your browser.
Or is the only reason to disable WebAssembly to be protected against zero-day code exploits?
If you set to low security (“Standard” instead of “Safer” or “Safest”) then default for WebAssembly is True. And low security (“Standard” level) is for better or for worse the default setting and therefore also the most common Tor Browser fingerprint.
Anyway if you are dealing with websites run by “reasonable” people, maybe it is worth to write to them with your concerns and explain why they should keep current options available for their users.
typeof window.WebAssembly will expose the API state, which is a different FP to if the code is say blocked via extension (which is not a Tor Browser thing) - the errors generated trying to run it will differ
As @twisted has said, use the security level settings to match your threat model (see about:preferences#privacy) - this in turn tells NoScript to flip the relevant prefs
Do not change about:config prefs or you will most likely affect your fingerprint - “most likely” because not everything in there (approx 3000 prefs) is web content related - but most are and easily detected
wasm is in the security levels because, AFAIK, it was new and as such had a history of exploits etc … lemme dig out some old info I once wrote
obviously JS is required to run wasm, and wasm can be more performant which is a nice-to-have in scripts (grab more FP metrics), but may hurt timing attacks (smaller differences).
I would assume, and hope, that any of our mitigations in JS are automagically covered in wasm - I doubt upstream moz devs would leave such a gaping hole
PS: one day I want to add wasm FPing tests (i.e not checking for wasm but using it to get values) into TZP, but it’s low priority
Thanks for information!
I doubt upstream moz devs would leave such a gaping hole
I thought upstream moz devs rely on Uplift for state of the art privacy/security, not other way around?
Is TZP a FP test suite?
it’s my little test playground, don’t read anything into it - TZP
initially a heap of TB protections were uplifted (Tor Uplift: isolation, RFP etc) and modified/scrutinized with more brains on the issues and tests added and approved by moz engineers - then that wound down
since then, we still try and uplift what we can, for less rebasing, but it still goes thru Mozilla scrutiny/expertise. Additionally, a lot of tweaks and patches are done purely upstream in anticipation for TB… or there are leaks/regressions and since the patch is upstream we get it fixed upstream if possible