Math function implementation details fingerprintable
The Math class now exposes high-precision versions of several mathematical functions. If these are OS-specific, they may be fingerprintable.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math
OS-level fingerprinting probably is not a terribly high priority. The only situation where this is high priority is if different OS versions and library versions end up producing different results for these functions.
Activity
I did not test all functions but just some using https://people.torproject.org/~gk/misc/MathHighPrecisionAPI.html. While we have differences between OSes we have it seems differences between 32bit and 64bit architectures as well. I tested on OS X 10.6.8, 32 bit Debian testing, 32 bit Ubuntu Precise, 64 bit Ubuntu Precise, Windows 7 64 bit and Windows 8 64 bit. Small differences between Linux/OS X /Windows aside, the 64bit Ubuntu Precise gives me:
asinh(1) = 0.881373587019543 acosh(1e300) = 691.4686750787736 atanh(0.5) = 0.5493061443340548 expm1(1) = 1.718281828459045 log1p(10) = 2.3978952727983707 sinh(1) = 1.1752011936438014 cosh(10) = 11013.232920103324 tanh(1) = 0.7615941559557649While my 32bit systems give
asinh(1) = 0.8813735870195429 acosh(1e300) = 691.4686750787737 atanh(0.5) = 0.5493061443340549 expm1(1) = 1.718281828459045 log1p(10) = 2.3978952727983707 sinh(1) = 1.1752011936438014 cosh(10) = 11013.232920103328 tanh(1) = 0.7615941559557649-
The Windows values are:
asinh(1) = 0.8813735870195429 acosh(1e300) = 691.4686750787737 atanh(0.5) = 0.5493061443340549 expm1(1) = 1.718281828459045 log1p(10) = 2.3978952727983707 sinh(1) = 1.1752011936438014 cosh(10) = 11013.232920103323 tanh(1) = 0.7615941559557649And the OS X values are only in cosh(10) different, too. I wonder whether we could get bigger differences by picking better values for these functions (I almost bet this is the case).
Values computed using standard algebraic expression:
asinh(1) = 0.8813735870195429 acosh(1e300) = NaN atanh(0.5) = 0.5493061443340549 expm1(1) = 1.718281828459045 log1p(10) = 2.3978952727983707 sinh(1) = 1.1752011936438014 cosh(10) = 11013.232920103324 tanh(1) = 0.7615941559557649Using code:
function asinh(x) { if (x === -Infinity) { return x; } else { return Math.log(x + Math.sqrt(x * x + 1)); } } function acosh(x) { return Math.log(x + Math.sqrt(x * x - 1)); } function atanh(x) { return Math.log((1+x)/(1-x)) / 2; } function cbrt(x) { var y = Math.pow(Math.abs(x), 1/3); return x < 0 ? -y : y; } function cosh(x) { var y = Math.exp(x); return (y + 1 / y) / 2; } function expm1(x) { return Math.exp(x) - 1; } function log1p(x) { return Math.log(1 + x); } function sinh(x){ var y = Math.exp(x); return (y - 1/y) / 2; } function tanh(x) { if(x === Infinity) { return 1; } else if(x === -Infinity) { return -1; } else { var y = Math.exp(2 * x); return (y - 1) / (y + 1); } }
Hrmm.. Sounds like we may need to pick a library we like and include its versions of these functions rather than calling out to the OS.
I wonder why there are 32 vs 64bit differences here, though.. I guess the Linux versions probably use 'long' instead of something standard like int64_t... Bleh.
Trac:
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-os added
Summary: Determine if high-precision Math routines are fingerprintable to High-precision Math routines are OS fingerprintable-
Replying to mikeperry:
I guess the next question is to determine if this is any worse than just an OS+arch fingerprinting vector, so we can decide how to prioritize this versus other fingerprinting issues.
We should ask SpiderMonkey folks for a best way to fingerprint users using the Math object. They might know some really good corner cases due to the algorithms they chose. https://bugzilla.mozilla.org/show_bug.cgi?id=892671 could be relevant here, too.
Floating point differences between platforms (since 2009 year).
<html> <head> <title>https://bugzilla.mozilla.org/show_bug.cgi?id=531915</title> </head> <body> <p>Detected platform for Tor Browser (based on ff24-esr):</p> <script> var check_tan = Math.tan(-1e300); if (check_tan == -1.4214488238747245) document.write("Linux 64"); else if (check_tan == 0.8831488831618285) document.write("Linux 32"); else if (check_tan == -4.987183803371025) document.write("Windows"); else document.write("Mac OS X"); </script> </body> </html>-
comment:19 was
More to puzzle. Output of testing sample linked with x86 libm (not reproducible for cross compiling): {{{ Before FIX_FPU: tan(-1e300) = -1.421449, tan(strtod('-1e300')) = -4.802497 After FIX_FPU: tan(-1e300) = -1.421449, tan(strtod('-1e300')) = 0.883149 }}}
Code of sample: {{{ #include <stdio.h> #include <stdlib.h> #include <math.h>
inline void FIX_FPU() { short control; asm("fstcw %0" : "=m" (control) : ); control &= ~0x300; // Lower bits 8 and 9 (precision control). control |= 0x2f3; // Raise bits 0-5 (exception masks) and 9 (64-bit precision). asm("fldcw %0" : : "m" (control) ); }
int main () { char *end; double x;
x = strtod ("-1e300", &end); // eq "x=-1e300";
printf("Before FIX_FPU: tan(-1e300) = %f, tan(strtod('-1e300')) = %f\n", tan(-1e300), tan(x)); FIX_FPU(); printf("After FIX_FPU: tan(-1e300) = %f, tan(strtod('-1e300')) = %f\n", tan(-1e300), tan(x));
return 0; } }}} FIX_FPU
Trac:
Type: task to defect Here's a very interesting overview of sources of floating-point inconsistencies: https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/
Trac:
Severity: N/A to Normal
Reviewer: N/A to N/A
Sponsor: N/A to N/A-
This may also be the cause of the fingerprintability of the WebAudio stuff in legacy/trac#13017 (moved) (or at least part of that fingerprintability). See https://trac.torproject.org/projects/tor/ticket/13017#comment:27 for a useful test.
A few notes:
-
A quick check with the browser console gives me the impression that simple JS math expressions are evaluated with 64 bit intermediaries (as opposed to 80 bit). I am uncertain about the JS JIT behavior.
(1.0 + Number.EPSILON * 0.5) + Number.EPSILON * 0.5) -
Assuming calls are made to libm (or equivalent) blindly, the results on each system are library version and implementation dependent. A particularly egregious example would be the output of
double sin(double x);being flat out wrong for glibc < 2.19 for certain values. MS's VC++ runtime is less wrong for a different set of certain values, but is still wrong. This probably applies to most transcendental functions. -
Even if we fix the JS that calls into libm, higher level apis that just happen to do math are not guaranteed to give the correct results, depending on how the native code it's called into is written or built. If we can assume that x87 is never used at all, then we'd still need to check for things like
rsqrtss.
-
-
From legacy/trac#29566 (moved) (which I closed as duplicate):
**part2: math.cos Windows: FF vs TB** results: see attachment test: https://thorin-oakenpants.github.io/testing/ (for as long as I leave it there) I do not know if that ticket/patch causes this, but there is a difference between TB vs FF for no discernible reason (e.g Linux doesn't differ between FF and TB) Look at the first result. FF: `minus 0.374...` vs TB `plus 0.840...` **part3: math.cos reveals platform** finally, to the meat and potatoes. See attachment. I'm using math.cos because it always returns a value between -1 and 1 (i.e no NaN or Infinity). The following tests show that, so far, the last four values can be used to detect windows or Linux, and so far one Android major version (v5.*). I am fully expecting the first four value to betray other Android and macOS/macOS X. My testing is incomplete, but enough to prove os FP'ingand
Thanks :) Yup, that was the ticket. Wow, 4 years. That ticket is about the functions added in FF25+ - e.g like those in https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#math - which doesn't **seem** to differ in 60+ anyway (those FF25+ functions probably need more testing I guess) Also note, that sin() can also have differences, I'm just not sure on which values over which platforms produce the desired results (and I could probably find more functions) - I'm sure the solution for this would fix any functions, so I'm not going to dig any further (except to show combos for mac and other android versions using cos) Edit: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math#Browser_compatibility - `cos`, `sin` etc were FF version 1 compatibleTrac:
Cc: N/A to Thorin 
I was worried that we might be exposing hardware information via this.
I compared the numbers I got on my x64 Nightly running on a Surface Go and got the same results as those of Thorin's Win7/Win10 x64 on x64 here: https://github.com/ghacksuserjs/TorZillaPrint/issues/30 . I'm reasonably convinced this means that hardware is not a factor in these values, and it comes down to OS and related libraries.
FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1380031 (FF68+) introduced a change (over my head) that reduced some entropy (namely that of precision in the number of decimal places) in some ECMAScript Edition 6 functions
The one test affected in my PoC was
expm1(1): windows example below1.7182818284590455FF67 or lower1.718281828459045FF68+But this is not enough to affect overall FP'ing of 32 vs 64 builds and platforms. Combined Edition 1 (the set of cos tests) and Edition 6 (3 tests) are still enough.
Replying to cypherpunks:
Detected platform for Tor Browser For Linux it depends run-time environment (libm system library), it's possible to detect some distros such way. Why isn't https://bugzilla.mozilla.org/show_bug.cgi?id=531915 added to RFP? Windows depends compile-time environment (mingw). https://sourceforge.net/p/mingw-w64/mingw-w64/ci/c61763cc740f8f4986755eeafce832baa3655ee8/
-
Replying to cypherpunks:
Why isn't https://bugzilla.mozilla.org/show_bug.cgi?id=531915 added to RFP?
Alrighty! I've been trying to re-find that ticket for quite a few weeks. Used it many months ago and promptly lost it. Thanks. I will pass on the ticket number to the Tor Uplift guys
it's possible to detect some distros such way
Comment 18 was 5 years ago. So far, and my resources are limited (and as an upstream problem means more than Tor Browser, which already changes their math FP), I have found nothing so far that leaks anything more than major platform (win/linux/mac) and in some instances 32/64 bit builds or OS architecture (some by default: eg a 64 bit build must be on a 64bit OS).
I wanted to get a ticket at bugzilla opened. I have no idea how much work or complexity and potential issues lie with using the same libraries over all platforms (which is what Chrome seems to be doing: they have the same FP regardless of anything I test on).
-
I have done more testing, and improved the output in my test: including a red info if I haven't seen the hash before. I have now found that TB on Linux actually has more entropy than originally thought. After testing 5 distros (a mix of flavors and architecture) I have 3 distinct Linux buckets (it's not enough to distinguish the actual platform, at least not in all cases, yet). I will be adding more distros to investigate further.
mentioned in issue legacy/trac#13313 (moved)
mentioned in issue legacy/trac#13313 (moved)
mentioned in issue legacy/trac#13313 (moved)
mentioned in issue legacy/trac#21704 (moved)
mentioned in issue legacy/trac#26146 (moved)
mentioned in issue legacy/trac#29566 (moved)
moved from legacy/trac#13018 (moved)
added Bug label and removed 1 deleted label
added Fingerprinting label and removed 1 deleted label
-
tl;dr: backport 531915 @sysrqb
Can't believe it's been two years ... FF93+ Bugzilla 531915 has landed
This solves all known desktop entropy in Firefox, by using fdlibm's
sin,cosandtanin jsmath - big thanks to sanketh and tom- side note: hooking this up to webaudio math should hopefully also eliminate entropy there (which is a similar number of results)
Here is a new math test created about a year ago (which gained more entropy than my previous endeavors based on Saito et al., 2018), but TBH, we only gained it in android
- https://arkenfox.github.io/TZP/tests/math.html
- the Firefox control was a windows machine
Here were the results
- https://arkenfox.github.io/TZP/tests/mathdata.html
- of the 55 known individual math tests that differed in Firefox, all the desktop entropy came from
cos,sin,tan - five tests only contribute entropy on Android: involving
pow(Math.PI),exp(1),cosh(1)- see 531915#c29
- scroll down and look at F20 to F26
- note: there are some more known results not added that increase the FF buckets, but they follow the same rule: i.e desktop is only sin/tan/cos related
Some results of the RFP patch in FF93+
- https://github.com/arkenfox/user.js/issues/1234
- sanketh's test page: https://snkth.com/browser-fingerprinting/math-fingerprint-tests/
- or use TZP's test: for desktop you should get
F20-
F20just happens to match a known FF result - I might update the page to reflect this if
- RFP is on and the version is 93+
- RFP is on and the version is 91+ AND it is TB (if TB backport the patch)
-
TZP itself uses a very small tiny subset of cos/sin/tan that has just as much entropy for desktop as the big research one. I have updated the code for RFP compliance
- going naked with no RFP
- after putting my RFP pants on
NOTE: for any readers. This will not hide your OS and isn't meant to. The patch removes entropy within an OS (e.g. mac, windows, linux), and happens to make all desktop OSes the same (that we know of)
android entropy is now Bugzilla 1722181
- the number of android buckets should come down from 7 to 4 (see below)
- solutions?
- hardcode
exp(1),cosh(1)andMath.PI(assuming Math.PI is the variable at issue)
- hardcode
removing sin/cos/tan from Firefox android results
F20: nothing, it's the control F21 + F24 cbrt: 1p1 cosh: 0, 0p1 expm1: 0p1 sinh: 0p1 F22 + F23 + F25 cosh: 0, 0p1 expm1: 0p1 sinh: 0p1 F26 cbrt: 1p1Edited by Thorin -
added Icebox label
added Roadmap::Future label and removed Icebox label
added All Platforms label
added Apps::Type::Bug label
-
I am not a hardware expert, so my best guess is this remaining entropy that we know of, in android, IIRC of 4 results (edit: assuming it still exists), is from architecture: 32bit, 64bit, arm (excuse my lack of correct terms)? and maybe that's already exposed
Edited by Thorin
added Apps::Impact::High label
