Quick question about WebAssembly. Some sites are moving to WebAssembly. My current Tor Browser setting for WebAssembly (which i think is default) is False (javascript.options.wasm). If you enable this specific setting, does that make your browser fingerprint different from default Tor Browser, like an Add-On would?
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.
Related question:
If WebAssembly is enabled, are there any known risks of leaking browser identifiers? (For example, do the mitigations against things like Javascript timing attacks, Canvas fingerprinting, etc. still work to protect against WebAssembly code?)
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.
actually 
… 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
Hi @thorin maybe you are knowledgeable to answer the related question I posted above? Do all of Tor Browser’s Javascript anti-fingerprinting mitigations (like timing attacks, Canvas fingerprinting, etc.) still work effectively against WebAssembly fingerprinting code? Does enabling WebAssembly increase potential for identity leak in any known way (more then Javascript) e.g. can WebAssembly code bypass browser anti-fingerprinting protection easier then Javascript?
Javascript is enabled at “safer” security level but WebAssembly only at “standard” security level. Is WebAssembly considered less safe due only to the reason of potential for zero-day WebAssembly exploits and the fact that malicious sites can easier obfuscate WebAssembly code or are there other considerations to be aware about?
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
/* 2422: disable WebAssembly [FF52+]
* Vulnerabilities have increasingly been found, including those known and fixed
* in native programs years ago [2]. WASM has powerful low-level access, making
* certain attacks (brute-force) and vulnerabilities more possible
* [STATS] ~0.2% of websites, about half of which are for crytopmining / malvertising [2][3]
* [1] https://developer.mozilla.org/docs/WebAssembly
* [2] https://spectrum.ieee.org/tech-talk/telecom/security/more-worries-over-the-security-of-web-assembly
* [3] https://www.zdnet.com/article/half-of-the-websites-using-webassembly-use-it-for-malicious-purposes ***/
user_pref("javascript.options.wasm", false);
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?
TZP
it’s my little test playground, don’t read anything into it - TZP
uplift
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