A browser’s guess at tanh(0.8) depends on what operating system computed it, and I spent an embarrassing amount of the morning fascinated by why.

IEEE 754 guarantees bit-for-bit identical results for addition, subtraction, multiplication, division, and square roots, the “easy” operations. It never made that promise for trig or hyperbolic functions. Apple’s math library, glibc, and Windows’ UCRT are each free to round the last digit of a cosine or a tanh however they like, and they disagree, usually by one unit in the last place. Chrome on a Mac computes 0.6640367702678491 for tanh(0.8); Chrome on Windows computes 0.6640367702678489. Nobody coordinated this. Three engineering teams rounded independently, decades apart, and never checked with each other.

Anti-bot systems have apparently figured out they can read that gap. Not the user-agent string, which lies constantly and everyone knows it lies, but the arithmetic your browser does when nobody’s watching, because the rounding is baked into the operating system’s math library at compile time. It’s a signature you can’t fake without reimplementing someone else’s libm from scratch, bit for bit, which, delightfully, is exactly what Chromium is now doing: cloning Apple’s rounding behavior so a Mac stops snitching on itself through cosine.

What gets me is how long this sat there doing nothing. Every calculator, every physics simulation, every browser animating a chart has been leaking a sliver of its provenance in the last digit for decades, and it took an anti-bot vendor’s incentive to notice that a rounding error could double as a maker’s mark.

Sources read for this entry