91–100 of 237 posts
Even Tor Browser (/mullvad-browser) gave up trying to obscure the operating system though arguably they shouldn't have. There appear to be too many fingerprinting vectors.
how hardened are modern browsers with respect to detecting underlying os? seems like there would be loads of gaps?
I guess that's one more good reason to push for correctly rounded transcendental functions. I recently learned that they're basically solved now. [1] [1] https://arith2026.org/program.html (2nd keynote)
One thing I was thinking of doing is manually SLP-vectorizing the high-precision fallbacks that they use when they're close to a rounding boundary, so that you can get better worst-case behavior – but obviously it's good enough already for most purposes.
I'm honestly surprised though that JS engines don't just keep using fdlibm though. The ECMAScript spec explicitly encourages it iirc. And if Math.tanh is on your hot path in JavaScript then you're doing something quite bizarre...
> One tanh call on the right input is a per-OS signature. Claim macOS, return Linux math bits, and you have contradicted your own User-Agent. They (or rather the LLM that wrote this) missed that this is possibly fingerprintable to browser version range, which is slightly more interesting. Most users aren't spoofing their user agent headers to be a different operating system. Most fingerprinting solutions aren't tryin…
> Most users aren't spoofing their user agent headers to be a different operating system. The people behind the LLM behind this blog post are. They're trying to pretend their robots are people to sell other websites' data to their customer. It's easier to pass bot detection gates if you pretend to be a physical machine running Windows or macOS than if you honestly admit you're using Linux on a VM.
Earlier quoted context omitted.
I recommend pretty much everyone avoid fixed point and other float alternatives, barring exceptional cases after you've done your own numerical analysis, or you lack floating point hardware (rare these days). Yes, fixed point can use simpler hardware. That's also a completely irrelevant consideration for software. The vast majority of processors are optimized for floats now and some operations (e.g. division) are act…
fixed-point provides uniform precision, exact integer-scaled arithmetic, is deterministic whereas floating point is more convenient but its not a panacea
Hardware floating point on CPUs (including SIMD units) is almost always IEEE 754 compliant these days (excepting only IBM’s weird fantasy land), and there the rules for the non-YOLO operations (+, -, *, /, sqrt, fma) are completely unambiguous and deterministic: treating the inputs as exact, compute the mathematically exact result, then either return it as is if it is exactly representable as a floating-point number, or if it’s not then round it to one that is according to the current rounding mode.
Things that can mess this up:
- GPUs just do whatever they feel like will make them look faster on benchmarks, don’t count on anything.
- Transcendental functions (exp, sin, etc.) are really hard (multiple literal PhDs) to implement according to the rules I’ve just described (“correct rounding”), so you’ve only been able to get such implementations in the last few years, and I believe no stock libm has completely switched so bring your own if you need them.
- Decimal-to-binary and binary-to-decimal conversions, by contrast, are not that hard to implement according to the rules in principle (it’s making them fast that’s difficult), yet Microsoft couldn’t get it right for literal decades, so if you need Windows then double-check CRT versions and bring in well-known open-source conversion code as necessary.
- Denormal inputs or outputs are very slow in some implementations, leading to a hardware option to flush them to zero. Either make sure to not produce them or keep an eye on the option.
- The precise bit pattern of the NaNs you get for invalid inputs may differ across platforms. Either make sure to not produce them (you really shouldn’t) or canonicalize upon de/serialization.
- Sometimes compilers will try to HALP by performing e.g. single-precision math in double-precision accumulators and only rerounding upon store to memory; by fusing * followed by + (two roundings) to hardware fma (only one); by reassociating; etc. Take care to prohibit your compiler from doing these shenanigans (no -ffast-math or -funsafe-math-optimizations ever, in your code or in any dependencies, and God help you if you’re on MSVC).
- Most shamefully, the 8087 (despite spawning the entire IEEE standard in the first place) tried to HALP by using 80-bit registers, so if you need x86-32 then be especially careful with compiler settings (I seem to remember the HALP mode might even be ABI-mandated on some 32-bit platforms so you’ll need to violate that).
The concept of floating point is solid, the IEEE standard is stellar, but the superstructure around it is just—not, requiring an unnecessary amount of vigilance to just make it work as designed.