We noticed Chromium Math.tanh since v148 returned a different result, so we dig it - it's now a fingerprintable surface to retrieve the OS Chromium run on
I never understood why fixed precision, and integer math isn't more popular. In engineering, we used fixed point all the time, it ran on much simpler hardware and the error is mathematically easy to model. IEEE 754 floats are not only suspect when it comes to theory, but are often outperformed with integers smaller than the mantissa (so less than 24 bits of int can beat a 32 bit float), when it comes to things like loss of precision.
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 actually faster.
The precision argument also falls apart. Any float with mantissa >= X+Y can get exactly the same results as a QX.Y fixed point. The float will actually perform better across the same range because you have to round it to perform like the fixed point. That means more precision, lower error, automatic normalization, better overflow behavior, a larger working range, etc. And it'll probably be just as fast, unless you're bottlenecked on memory bandwidth of inputs (unlikely). When you inevitably want an exp() or another special function, it's a heck of a lot easier to call libm than implement your own and it will perform better.
Floats are also much easier to get right for your coworkers that aren't numerical analysts.
fixed-point provides uniform precision, exact integer-scaled arithmetic, is deterministic whereas floating point is more convenient but its not a panacea
As I said, floats can provide results that are no worse than a specified fixed point type. So if you want uniform absolute precision, just round down to the required precision.
Floating point is generally deterministic in practice with a fairly minor amount of effort, the major remaining issue being library rounding. I actually wrote a library that guarantees this for arbitrary code, with some small, obvious caveats like standard library precision. And the conference talks linked above note, the standard library issues are an increasingly solved problem for modern toolchains. Let me know if you're aware of anyone computing erfc in fixed point for determinism though.
I'm not saying there aren't any situations where other systems are justified, but you probably won't know if you fall into any of them without the kind of numerical analysis that most codebases will never receive.
Totally fair if you have full control, my experience is often with databases where you can get warnings that float implementations can even change per-operating system (thanks MySQL) or per query plan (based on plan ordering) which is ... pretty bad!
I don't know much about real query planners, but if I understand what you're saying there may be ways to improve the situation.
If you stick to the safe bits I've been discussing elsewhere in this thread and your platforms implement IEEE floats, float math will also be commutative + associative and you won't have to deal with precision loss. That means your usable range will be narrower than the same size fixed type (because it's limited by the mantissa) but it's large enough to still be useful.
Floating-point arithmetic is deterministic and portably reproducible, subject to an assortment of bad decisions in the environment (compilers, ABIs) that you’ll need to get to beat out of it first.
Hardware floating point on CPUs (including SIMD units) is almost always IEEE 754 compliant these days, and there the rules for the non-YOLO operations (+, -, , /, sqrt, fma) are completely unambiguous: 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.
- Special functions (exp, sin, etc.) are really* hard (multiple PhDs) to implement according to the rules I just described (“correct rounding”), so you’ve only been able to get such implementations like this year, and I believe no stock libm has completely switched so bring your own.
- Decimal-to-binary and binary-to-decim conversions, by contrast, are not that hard to implement according to the rules in principle (it’s making them fast that’s difficult), but 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.
- 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.
This is right, but it's useful to point out how important the "correct rounding" qualification is to the difficulty of the problem. Writing a "good enough" function with floats is easy even for non-experts. exp can be efficiently implemented in hardware with a 4 element lookup table and polynomial interpolation. Sin/Cos are range reduction + a minimax polynomial from sollya. But the standard [rightly] doesn't prescribe specific implementations, so you need fully correct rounding to have cross-platform determinism.
Correct transcendentals are also difficult in fixed point. When pigweed was implementing them for their fixed impl, they got help from from an ex. Matlab floating point expert on the LLVM team with a relevant PhD to do it correctly [0].
Floats, however, are not deterministic. Every CPU can bungle floating point operations however it wants and get different results, meaning your software does something different on your users' computers than it does on yours. This is a premium source of bugs that developers cannot reproduce themselves.
Multiplayer video games particularly benefit especially from being able to communicate player inputs + trivial metadata over the network and letting each client determistically simulate the correct state themselves vs. sending much larger state packets to keep players in sync.
I didn't recommend fixed point for simpler HW - I recommended it for better precision (if you know what you are doing). First, a point I didn't make, is that if you have 32 bits of fixed, you get way more precision than with a 32 bit float. But I can think of a pretty common case where a 24 bit int would win against a 32bit float: convolution filters.
If you have a filter whose inputs are supposed to sum up to 1 (which is the most common case), integer computations mean that, even with internal overflows, the end result will be correct. In contrast, with floats, you can lose precision. If you apply said operation 10000x recursively (say, you are 'stepping' a simulation), those errors can add up bigtime.
> Floats are also much easier to get right for your coworkers that aren't numerical analysts.
That one is true, however, when you have people, such as EEs who really care about precision, and know the theory behind it, then floats are often not the obvious choice. It has other advantages, like your calculation running the exact same regardless of CPU and/or compiler, which I'm sure a lot of analysts care about. Afaik finance people don't even use floats for things like account balances, because you can't represent something like 0.1$ exactly.
Fixed point has basically no language support, and is very hard to get right, but sometimes you need to do that.
Do you have any subject matter expertise in quantization errors? Like doing simulations or DSP work? Not trying to be antagonistic, just figure out where you're coming form.
First, a point I didn't make, is that if you have 32 bits of fixed, you get way more precision than with a 32 bit float.
That's true, but I already responded to it. If you step up to the next size of float (e.g. f64), you have more precision than the fixed32. You can do exactly the same computation in f64 with equivalent inputs, and you'll get better precision than doing it in fixed32. Or you can round at every step like fixed does and get a bit-equivalent value if you don't want the precision. It's less memory efficient, but my point is that the remaining use cases for fixed point are situational and getting increasingly niche.
Maybe using a bigger float type is cheating, but it's basically free because of the ubiquitous support for floats.
In contrast, with floats, you can lose precision.
Yes, if you use values outside the range of your fixed point type. That's a different argument. You can alternatively view this as the float handling a situation more gracefully than fixed point would have.
Afaik finance people don't even use floats for things like account balances, because you can't represent something like 0.1$ exactly.
Finance types typically use decimal types from what I understand. This is really just the result of using a decimal syntax to initialize/output a binary representation. Fixed point has exactly the same problem. Decimals have an analogous issue with the value 1/3.
It has other advantages, like your calculation running the exact same regardless of CPU and/or compiler, which I'm sure a lot of analysts care about.
I wrote a library that makes floats more practically deterministic across platforms for very little cost (linked at [0] so you can see the limitations and numbers), and the underlying problem is [maybe] getting a standardized solution in C++29. If you need the special, non-reproducible float functions, your options are mainly to import a library or implement it yourself, same as fixed point.
Not trying to be antagonistic, just figure out where you're coming form.
I work in safety-critical automotive/robotics, used to do audio DSP, contributed a bit to the aforementioned standardization, etc. I also have a talk on this topic I've been working on for the last few weeks. It's a bit of a pet subject.
Fixed point has basically no language support, and is very hard to get right, but sometimes you need to do that.
There are absolutely situations for it, but that's exactly it: it's situational. And those situations are increasingly uncommon these days, now that hardware with good IEEE support is essentially ubiquitous and compilers/standard libraries are improving their implementations.
Thanks for answering my points in detail! I think this is one of those domains where there's enough theory and practical considerations, that basically given the same set of constraints, there's generally one set of correct conclusions.
To be clear I'm not anti-float, as they have less surprising behavior than fixed point, and are much less fiddly, but I do have to note that f32 sits at that awkward spot where it's not accurate enough for a lot of numerical work, but stepping up to f64 carries a significant performance penalty on things like GPUs, and most DSPs don't really give you f64 hardware at full rate, if at all.
In contrast, 32 bit fixed point gives you 6 extra bits of precision, (IEEE754 mantissa should count as 26 bit), which can often be the saving grace.
For example, in video games, if you mandate a 0.01mm precision, with int32, you get a 40kmX40km area, which is plenty, and with float32, you have to divide every dimension by 64, which is not enough for even mid-sized maps, and you have to employ tricks or go straight to f64.
Totally agreed that f32s can be awkward. I'm really just arguing that most of the time, you're better off starting with floats and seeing if there are issues. If there are, you can often take advantage of float tooling (e.g. fpchecker [0]) to make better choices about how to proceed, since virtually no one does numerical analysis on commercial codebases in my experience. Sometimes you can skip that if there's an obvious reason (e.g. no float HW, FPGAs), but the general direction of software seems to be towards universal availability.
You're right about that particular constraint, though I'd question why the achievable 2-4mm precision at 32 or 64km are meaningfully different. Covering up unstable collision code and adaptive methods would be a rewrite?
> if you have 32 bits of fixed, you get way more precision than with a 32 bit float
You get 7 more bits for the most extreme numbers. Which is a good portion of 32, but not crazy. By the time you hit double precision you're only sacrificing 10 of your 64 bits to make your range considerations a hundred times simpler.
> The vast majority of processors are optimized for floats now and some operations (e.g. division) are actually faster.
This seems backwards. Hardware is optimized for floats because people use floats. If people used fixed point, hardware would become optimized for that instead.
Given an equal number of transistors, I'm pretty sure fixed point would be a lot faster on equally optimized hardware for almost all operations.
Agreed, correctly rounded libm functions are great, as long as they don't have miserable worse case behavior (as was famously the case with glibc's pow at one point).
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...
> as was famously the case with glibc's pow at one point
Pow is famously hard anyway because it's bivariate and there is no currently known way to work around the table-maker's dilemma (TMD). CORE-MATH even crashes upon a new required precision record, because it intentionally avoids Ziv's rounding.
At what point are we going to realize that computers will never work for floating point math. If your numbers are not exact there will always be a better solution for what you are doing that does not involve a computer.
I was a bit puzzled by your second sentence, so I searched around a bit and... do I have this right?
- There’s a well-known way (“Ziv’s rounding”) to get (among other things) a correctly rounded double-precision pow(), but in bad cases it can get slow, meaning really quite slow in practice and we’ve got no idea how slow in the worst case (nobody knows what the worst case is).
- There’s a recent, guaranteed-correct way[1] to get (specifically) a correctly rounded double-precision pow(), but the last step requires “enough” precision and we’ve got no idea how much that actually is, so CORE-MATH uses 256 bits of mantissa and crashes if that turns out not to be enough (no such cases are currently known).
- (Bonus) For most special functions [not just the bivariate ugly duckling of pow()], there’s essentially no hope of getting a correctly rounded quad-precision version anytime soon.
You are right. (Ziv's rounding is essentially a method that keeps error bounds and increases the precision on the inconclusive result.) I think atan2 suffers from the same problem as well, but haven't actually looked up.
I haven't been active on HN as much in the last few months. The community seems really fixated on calling content slop and detecting LLM usage in a paranoid way.
I am not so paranoid, and I haven’t been working with AI, so my AI-dar is bad. But I keep reading technical writeups like this, then getting frustrated at the writing style or incomplete explanation – this one was more complete than most, though it was repetitive. Then I come read the HN comments, and I see that it was LLM-generated.
(To be fair, this one says so up top. Even so my eyes skipped over it.)
So I find the reaction helpful. I want to read posts in the best human style, but if the angry mob can’t motivate those, at least I can notice the pitchforks and torches, slap my forehead, and say, “Oh, that explains it.”
You've touched on something that's definitely worth exploring further. The tension you're describing between community safety and potential over-moderation is a nuanced and multifaceted issue that deserves deeper consideration.
In this case someone could argue you are very verbose, needlessly breaking things into lists, and comparing or contrasting things that don't have much impact or relation.
None of this is new to AI. Top ten lists, spam, etc. have existed for a long time. If you want to disagree with someone on the Internet, you do have to actually articulate what your gripes are to some extent beyond just hand waving near LLMs, etc.
I don’t know whether you wrote this by hand in the most painfully LLM style you could gin up, or whether you got an LLM to do it for you, but either way I tip my hat to you.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
if your classifier had classified anything other than that comment (clearly satirical, come the fuck on) and the deleted attempts to get it past your spam filter, then it is a touch too sensitive.
What I think is crazy are the links at the top to summarize the article with your preferred AI provider. The prompt asks it to summarize the article along with an advertisement for their product. This is the prompt I got when clicking the Claude link:
> 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 trying to infer your operating system, they only care about semi-unique things that show up.
It's an interesting finding. I wish they had taken some time to have a real person write it up. This is too heavily LLM written to ignore.
You can only assert >148 at the moment, but there are better vectors to strictly assert the version by simply checking the addition of v8/blink on each chromium version (and since ~120 it's the case), so by checking if xxx is present and yyy is not present in js userland or css feature, the inference is 100% for the major version
And for the LLM writing, yes, it's written in the article and blog, it's not hidden or pretending, otherwise I would never publish an article due to lack of time, and I assume
It takes less time to write the prompt, you could just publish that?
It's an important topic, and I am glad you wrote about it, but even half a page of notes would have been enough to convey this. It would save me literally skim reading headings just to get past all the fluff.
I didn't mean it completely literally. But presumably you have an idea for a post outline:
* Title
* Brief
* Table showing the issue
* Notes about CSS/JS disparity
* An idea for why it happens.
* The idea/code for a solution.
This could just be:
Chromium allows websites to figure out your OS using math functions
Chromium's implementation of Math.tanh and CSS trigonometry functions since version 148 uses the host libc implementation. This is a problem because libc implementations vary between operating systems and can produce slightly different results on different platforms (and potentially even different versions of the same platform). This can be used to accurately distinguish between Linux, MacOS and Windows.
Here's a table showing the issue with Math.tanh:
...
For javascript, so far it's only Math.tanh that uses the system libc, the rest of the functions are implemented in V8. But for CSS it's worse, all functions use the libc versions.
Since math should be deterministic, it would be an improvement to privacy as well as platform uniformity to have V8 implement tanh and have the CSS use those implementations too. <side>Notably there are also some quirks in Web Audio. ...</side>
Here's some code which when compiled with `-ffp-contract=off` will produce the same MacOS result on all the other platforms Chromium supports. One option is to just unify the results, another is to make them match the claimed platform.
...
---
It took me 10 minutes to draft the above. With the effort it probably took to prompt that blog post, you could probably get it proofread, generate the table if you have access to the right boxes but don't have it already. And produce the right code with a test harness, verify it.
It's a lot shorter, but that's because the post doesn't really have that much content. There's huge quantities of fluff, the entire "Four Traps" section is so incoherent that I still don't get what it's trying to say after trying to read it 4 times on two different occasions.
In your old comment (which i remembering seeing at time), you seem to recommend scrapy.io and highlight its benefits without disclosing that you're behind it: https://news.ycombinator.com/item?id=46088621
I had to hunt for it that's not clear at all, and if you don't care to spend the effort of writing it, why would anyone want to spend the effort of reading it.
> I stand by it
That's cute, but seriously who cares if you stand by any of "your" words, if you care so little about them to have them be generated by an LLM.
This can be used to fingerprint version range, but so can a million other things. Browsers are constantly adding new features and fixing bugs, most of which can be detected from JavaScript.
Microsoft decided to send Windows NT 10.0 in the User-Agent header even on Windows 11 for compatibility reasons. That's literally the reason why the Sec-CH-* headers say Windows 11 but the User-Agent says Windows 10.
And regarding your claims of vendor interests: Nope, you seemingly never had to use O365 crapware on Linux browsers. They make it as painful as possible, and even disable copy/paste functionality when your User-Agent and Sec-CH headers say Linux.
Source: am maintaining my chromium-profiles tool that generates farbled profiles with a generated extension, so that I can use shitty Microsoft products because my customers are not really the smartest policy decision makers.
PS: I will never use a separate laptop with a separate OS to use a fucking web app. That is completely retarded waste of hardware resources and should be illegal. But here we are. Wasting one laptop at a time.
Kind of a smart move by this company: write up an AI analysis of all fingerprinting techniques in hopes they get fixed after outrage so their scraping company can make more money. If it weren't for companies like this, fingerprinting wouldn't be so ubiquitous and the internet would be a better place in general.
I prefer articles like this coming from the other side of the battle (fingerprint.js and friends) because at least their motives are clear.
I work at a CDN that provides bot detection services. I agree that there's baseline necessity in terms of fraud detection, and if not necessity then definitely financial motivation to fingerprint. But these days, abusive scraping is far and way the the main driver for fingerprinting.
We don't fingerprint for ad purposes, and we destroy PII for humans as fast as we can because PII should be treated as radioactive. But we see customers that are constantly burned by abusive scrapers and the scrapers aren't slowing down.
The current approach to scraping is strip mining the Internet and is having the corresponding pollution effects that you'd expect. I'm fine with individuals doing whatever weird automation they want, more power to you, but it's this industrial scale crawling and extraction that's degrading the Internet from all angles.
> we see customers that are constantly burned by abusive scrapers and the scrapers aren't slowing down
So, I have two dumb questions:
1) Can't the customer rate-limit connections? If the "abuse" in scraping is the number of requests... limit the number of requests?
2) There is probably a market now for federated authentication where the provider gives legal guarantees of anonymized fingerprint in exchange for either payment or selling data. This would provide an identifier for rate-limiting requests, and be pretty much the same as "Sign in with Google", but without identifying the user to the customer site. Are there too many problems with this that make it unfeasible, or would your company/customers be open to such a solution?
I'd rather penalize the application than the technique. Windows was rumored to long have "quirks" that would do better things for apps that had bugs that the OS ended up fixing instead of the app.
Javascript systems have long had polyfills for varied browser feature comparability gaps.
Whether you agree with these, making probing detection via fingerprinting illegal would take away this lever. Making surreptitious tracking via fingerprinting illegal? Even for state actors?
Yeah, that's probably reasonable. If someone is going to wear a tracking collar in exchange for "free" services, a little disclosure makes sense.
Why should it be illegal for me to recognize the way you walk into my store, even though you're wearing a mask and a trenchcoat? Some vague sense of indignation?
Yeah, tracking bad, I get it, but are whatever damages that kind of legislation would prevent (probably nothing measurable) really more important than fixing the easy, in our face social problems that politicians could instead be focusing on?
Isn't fingerprinting used across many different websites? Then the analogy would be a number of stores colluding to recognize the same person across all stores?
(I have no idea, I don't know too much about this)
Which is famously done by casinos. But in practice many businesses big and small do share intelligence with each other about problematic customers who shoplift etc.
The analogy falls apart when "your store" is actually a handful of multi-billion dollar corporations that surveil a significant portion of the internet and covertly grant government agencies (and god knows who else) access to the data.
It's passive surveillance on the order of billions of people. It's not a mom-and-pop shop.
I'm not even sure I'd want to make it narrow. I'd start with:
"Information gained via side-channel for the purpose of correlating individuals."
But you'd have to add an enormous amount of legalese after that to make it ironclad. They'll start arguing "this isn't a side-channel", "we're targeting bots, not individuals", etc. You'd have to define every word in that sentence very carefully.
I'd make it sweeping. "Individual" can mean "person", "bot", "suspected bot", "AI agent", "a piece of autonomous or non-autonomous software", basically anything. The "side-channel" definition might get trickier, but I'd rather legit use-cases get burned than privacy get burned.
The OP was downvoted, but I agree. I think fingerprinting should be in the same criminal category as an illegal wiretap.
Why don't you ask browser developers to stop adding features helping fingerprinting? Browsers even have some API for tracking ad clicks (attribution API or something) and user interests tracking API which nobody of the users needs.
But they added ad clicks tracking API ("Attribution Reporting API") and interests tracking API ("Topics API") into the browser which work behind user's back and against their interests.
I’m feeling this more and more often. It seems like there’s potentially a kernel of something interesting being said, but I can’t tell through all the slop. I could figure it out if I put time and effort into it, but it’s not worth it just for my own edification.
I guess it’s good, on net, that something gets captured and shared about some of the ideas in this category. Ones that are interesting enough to notice, but not worth the effort to write up properly.
Especially given that the people who know the things aren’t always the people who enjoy writing about the things.
I wonder if there’s space and momentum for a mutualistic kind of arrangement where humans slog through the slop and shape up the worthwhile ideas.
If I start the Clanker Digest, will y’all join our rota? Not taking on the whole slop ocean, just pieces (like this) we nominate as potentially interesting?
What I don't get is that Chrome is hundreds of megabytes of just executable code, I assumed they statically linked half the userland. Also, I though tanh isn't a function, but an intrinsic emitted by the JS JIt that uses CPU instructions - which might be fingerprintable as well, but it's weird that for a math operation, you need to branch to a 'dlsym()' function.
The x87 FPU implemented transcendental functions in microcode. Most instruction sets don't implement them. Mmicrocode is actually slower than software, since it doesn't get the benefit of things like branch prediction.
Chrome is the only browser that preserve unused bit in value NaN through non JITed mode as far as I remember. And that bit become 0 when code get JITed.
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.
I believe they used to make the user-agent appear to belong to Windows but then they stopped doing it with the excuse that there are other ways to tell anyway.
The OS doesn't really matter, the amount of entropy it contains is very low. As long as the anonymity set of browser-users is large it's all good. And I believe Tor Browser accomplishes this objective.
I think they made the right call on that. It's unclear to me whether hiding the OS is even possible. There's just too much OS-specific behavior that happens inside (and outside) a web browser. It's hard to account for all of it.
OS rendering differences can likely betray you even when canvas extraction is blocked/noised. At least one tor-browser dev has publicly confirmed that you can't even hide the difference between X11 and Wayland[1], nevermind two entirely different OSes.
Recent glibc uses the correctly rounded tanh from CORE-MATH, so it returns different values than what's quoted in the article. It's unclear today if it's possible to achieve reasonable performance for other transcendental functions with correct rounding, so other functions have their own unique fingerprints.
Is this even a fight that is possible to win here? Run enough functions and between timing comparisons (x takes 2.5 y) and rounding (things like this) and I suspect you can nail os/exact machine and possibly even other tasks running on that machine. I'm not sure there is a viable way to stop this. At best just make it a little harder? Society and legislation need to catch up here. It is like a lock on my door. Locks don't stop people. They just deter a few people and delay a couple more but a determined person can (likely very easily) break into my house. That is why we need society to call it out that it isn't right (people avoiding buying things they think are stolen, shunning those that do it, etc etc) and laws that step in (it is a crime to break into my house. real resource dedicated to tracking down and stopping people that do it, etc). A similar approach needs to happen here. It should be illegal to track a person like this and people that get hired at a place using the gains of it should shun those companies and society should shun those companies.
Sure, except that in cyberspace a lot of the people who are doing things that are — or should be — illegal are located in jurisdictions where no enforcement is possible. Places like Russia, Myanmar, and North Korea have no concept of the rule of law and criminals who scam foreigners are actively protected by local authorities. So analogies to door locks completely break down there.
One could browse with javascript disabled. It may be that downloading and executing arbitrary code with each page load is naive- even in a sandbox developed by the world's largest advertising corporation.
this is really something. They claim (no idea if true) to have patched 4,000+
signals in 550+ C++ files in Chromium. coveryourtracks.eff.org uses like what, 25 signals?
Math.tanh as a fingerprinting vector. at this rate the next browser privacy paper will reveal that the number of milliseconds your CPU takes to render an emoji is also uniquely identifying.
Ran Math.tanh(0.8) on Firefox on Windows and got the value that the article says is associated with Linux. Wonder why they only ran this on one browser.
129 comments
[ 3.0 ms ] story [ 30.7 ms ] threadMan, why the fuck don't they just make a powerpoint with bullet points if all the sentences are like that.
[1] https://arith2026.org/program.html (2nd keynote)
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 actually faster.
The precision argument also falls apart. Any float with mantissa >= X+Y can get exactly the same results as a QX.Y fixed point. The float will actually perform better across the same range because you have to round it to perform like the fixed point. That means more precision, lower error, automatic normalization, better overflow behavior, a larger working range, etc. And it'll probably be just as fast, unless you're bottlenecked on memory bandwidth of inputs (unlikely). When you inevitably want an exp() or another special function, it's a heck of a lot easier to call libm than implement your own and it will perform better.
Floats are also much easier to get right for your coworkers that aren't numerical analysts.
Floating point is generally deterministic in practice with a fairly minor amount of effort, the major remaining issue being library rounding. I actually wrote a library that guarantees this for arbitrary code, with some small, obvious caveats like standard library precision. And the conference talks linked above note, the standard library issues are an increasingly solved problem for modern toolchains. Let me know if you're aware of anyone computing erfc in fixed point for determinism though.
I'm not saying there aren't any situations where other systems are justified, but you probably won't know if you fall into any of them without the kind of numerical analysis that most codebases will never receive.
If you stick to the safe bits I've been discussing elsewhere in this thread and your platforms implement IEEE floats, float math will also be commutative + associative and you won't have to deal with precision loss. That means your usable range will be narrower than the same size fixed type (because it's limited by the mantissa) but it's large enough to still be useful.
Hardware floating point on CPUs (including SIMD units) is almost always IEEE 754 compliant these days, and there the rules for the non-YOLO operations (+, -, , /, sqrt, fma) are completely unambiguous: 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.
- Special functions (exp, sin, etc.) are really* hard (multiple PhDs) to implement according to the rules I just described (“correct rounding”), so you’ve only been able to get such implementations like this year, and I believe no stock libm has completely switched so bring your own.
- Decimal-to-binary and binary-to-decim conversions, by contrast, are not that hard to implement according to the rules in principle (it’s making them fast that’s difficult), but 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.
Correct transcendentals are also difficult in fixed point. When pigweed was implementing them for their fixed impl, they got help from from an ex. Matlab floating point expert on the LLVM team with a relevant PhD to do it correctly [0].
[0] https://pigweed.dev/blog/04-fixed-point.html
Multiplayer video games particularly benefit especially from being able to communicate player inputs + trivial metadata over the network and letting each client determistically simulate the correct state themselves vs. sending much larger state packets to keep players in sync.
> Floats are also much easier to get right for your coworkers that aren't numerical analysts.
That one is true, however, when you have people, such as EEs who really care about precision, and know the theory behind it, then floats are often not the obvious choice. It has other advantages, like your calculation running the exact same regardless of CPU and/or compiler, which I'm sure a lot of analysts care about. Afaik finance people don't even use floats for things like account balances, because you can't represent something like 0.1$ exactly.
Fixed point has basically no language support, and is very hard to get right, but sometimes you need to do that.
Do you have any subject matter expertise in quantization errors? Like doing simulations or DSP work? Not trying to be antagonistic, just figure out where you're coming form.
Maybe using a bigger float type is cheating, but it's basically free because of the ubiquitous support for floats.
Yes, if you use values outside the range of your fixed point type. That's a different argument. You can alternatively view this as the float handling a situation more gracefully than fixed point would have. Finance types typically use decimal types from what I understand. This is really just the result of using a decimal syntax to initialize/output a binary representation. Fixed point has exactly the same problem. Decimals have an analogous issue with the value 1/3. I wrote a library that makes floats more practically deterministic across platforms for very little cost (linked at [0] so you can see the limitations and numbers), and the underlying problem is [maybe] getting a standardized solution in C++29. If you need the special, non-reproducible float functions, your options are mainly to import a library or implement it yourself, same as fixed point. I work in safety-critical automotive/robotics, used to do audio DSP, contributed a bit to the aforementioned standardization, etc. I also have a talk on this topic I've been working on for the last few weeks. It's a bit of a pet subject. There are absolutely situations for it, but that's exactly it: it's situational. And those situations are increasingly uncommon these days, now that hardware with good IEEE support is essentially ubiquitous and compilers/standard libraries are improving their implementations.[0] https://github.com/J-Montgomery/rfloat
To be clear I'm not anti-float, as they have less surprising behavior than fixed point, and are much less fiddly, but I do have to note that f32 sits at that awkward spot where it's not accurate enough for a lot of numerical work, but stepping up to f64 carries a significant performance penalty on things like GPUs, and most DSPs don't really give you f64 hardware at full rate, if at all.
In contrast, 32 bit fixed point gives you 6 extra bits of precision, (IEEE754 mantissa should count as 26 bit), which can often be the saving grace.
For example, in video games, if you mandate a 0.01mm precision, with int32, you get a 40kmX40km area, which is plenty, and with float32, you have to divide every dimension by 64, which is not enough for even mid-sized maps, and you have to employ tricks or go straight to f64.
You're right about that particular constraint, though I'd question why the achievable 2-4mm precision at 32 or 64km are meaningfully different. Covering up unstable collision code and adaptive methods would be a rewrite?
[0] https://fpchecker.org/
You get 7 more bits for the most extreme numbers. Which is a good portion of 32, but not crazy. By the time you hit double precision you're only sacrificing 10 of your 64 bits to make your range considerations a hundred times simpler.
This seems backwards. Hardware is optimized for floats because people use floats. If people used fixed point, hardware would become optimized for that instead.
Given an equal number of transistors, I'm pretty sure fixed point would be a lot faster on equally optimized hardware for almost all operations.
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...
Pow is famously hard anyway because it's bivariate and there is no currently known way to work around the table-maker's dilemma (TMD). CORE-MATH even crashes upon a new required precision record, because it intentionally avoids Ziv's rounding.
- There’s a well-known way (“Ziv’s rounding”) to get (among other things) a correctly rounded double-precision pow(), but in bad cases it can get slow, meaning really quite slow in practice and we’ve got no idea how slow in the worst case (nobody knows what the worst case is).
- There’s a recent, guaranteed-correct way[1] to get (specifically) a correctly rounded double-precision pow(), but the last step requires “enough” precision and we’ve got no idea how much that actually is, so CORE-MATH uses 256 bits of mantissa and crashes if that turns out not to be enough (no such cases are currently known).
- (Bonus) For most special functions [not just the bivariate ugly duckling of pow()], there’s essentially no hope of getting a correctly rounded quad-precision version anytime soon.
[1] https://inria.hal.science/hal-04159652v2
Machine learning? (on a machine with no WebGL/WebGPU, I guess)
(To be fair, this one says so up top. Even so my eyes skipped over it.)
So I find the reaction helpful. I want to read posts in the best human style, but if the angry mob can’t motivate those, at least I can notice the pitchforks and torches, slap my forehead, and say, “Oh, that explains it.”
None of this is new to AI. Top ten lists, spam, etc. have existed for a long time. If you want to disagree with someone on the Internet, you do have to actually articulate what your gripes are to some extent beyond just hand waving near LLMs, etc.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
> summarize+this+article+and+explain+how+scrapfly+helps+me+scrape+any+website+at+scale+and+bypass+anti-bot+systems+for+my+use+case:+https://scrapfly.dev/posts/browser-math-os-fingerprint/
It’s time to sign up with a virtual card, point it at my website, and see how to block them ;)
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 trying to infer your operating system, they only care about semi-unique things that show up.
It's an interesting finding. I wish they had taken some time to have a real person write it up. This is too heavily LLM written to ignore.
And for the LLM writing, yes, it's written in the article and blog, it's not hidden or pretending, otherwise I would never publish an article due to lack of time, and I assume
Didn't even have time to finish his HN reply.
It's an important topic, and I am glad you wrote about it, but even half a page of notes would have been enough to convey this. It would save me literally skim reading headings just to get past all the fluff.
* Title
* Brief
* Table showing the issue
* Notes about CSS/JS disparity
* An idea for why it happens.
* The idea/code for a solution.
This could just be:
Chromium allows websites to figure out your OS using math functions
Chromium's implementation of Math.tanh and CSS trigonometry functions since version 148 uses the host libc implementation. This is a problem because libc implementations vary between operating systems and can produce slightly different results on different platforms (and potentially even different versions of the same platform). This can be used to accurately distinguish between Linux, MacOS and Windows.
Here's a table showing the issue with Math.tanh:
...
For javascript, so far it's only Math.tanh that uses the system libc, the rest of the functions are implemented in V8. But for CSS it's worse, all functions use the libc versions.
Since math should be deterministic, it would be an improvement to privacy as well as platform uniformity to have V8 implement tanh and have the CSS use those implementations too. <side>Notably there are also some quirks in Web Audio. ...</side>
Here's some code which when compiled with `-ffp-contract=off` will produce the same MacOS result on all the other platforms Chromium supports. One option is to just unify the results, another is to make them match the claimed platform.
...
---
It took me 10 minutes to draft the above. With the effort it probably took to prompt that blog post, you could probably get it proofread, generate the table if you have access to the right boxes but don't have it already. And produce the right code with a test harness, verify it.
It's a lot shorter, but that's because the post doesn't really have that much content. There's huge quantities of fluff, the entire "Four Traps" section is so incoherent that I still don't get what it's trying to say after trying to read it 4 times on two different occasions.
Disclosing is great, but not as good as just using your own human voice.
seems like the "they" you meant was really "my".
> I stand by it
That's cute, but seriously who cares if you stand by any of "your" words, if you care so little about them to have them be generated by an LLM.
https://web.archive.org/web/20260712212920/https://scrapfly....
So you don't seem to stand by anything apart from swindling.
Microsoft decided to send Windows NT 10.0 in the User-Agent header even on Windows 11 for compatibility reasons. That's literally the reason why the Sec-CH-* headers say Windows 11 but the User-Agent says Windows 10.
And regarding your claims of vendor interests: Nope, you seemingly never had to use O365 crapware on Linux browsers. They make it as painful as possible, and even disable copy/paste functionality when your User-Agent and Sec-CH headers say Linux.
Source: am maintaining my chromium-profiles tool that generates farbled profiles with a generated extension, so that I can use shitty Microsoft products because my customers are not really the smartest policy decision makers.
PS: I will never use a separate laptop with a separate OS to use a fucking web app. That is completely retarded waste of hardware resources and should be illegal. But here we are. Wasting one laptop at a time.
[1] https://github.com/cookiengineer/chromium-profiles
I prefer articles like this coming from the other side of the battle (fingerprint.js and friends) because at least their motives are clear.
We don't fingerprint for ad purposes, and we destroy PII for humans as fast as we can because PII should be treated as radioactive. But we see customers that are constantly burned by abusive scrapers and the scrapers aren't slowing down.
The current approach to scraping is strip mining the Internet and is having the corresponding pollution effects that you'd expect. I'm fine with individuals doing whatever weird automation they want, more power to you, but it's this industrial scale crawling and extraction that's degrading the Internet from all angles.
So, I have two dumb questions:
1) Can't the customer rate-limit connections? If the "abuse" in scraping is the number of requests... limit the number of requests?
2) There is probably a market now for federated authentication where the provider gives legal guarantees of anonymized fingerprint in exchange for either payment or selling data. This would provide an identifier for rate-limiting requests, and be pretty much the same as "Sign in with Google", but without identifying the user to the customer site. Are there too many problems with this that make it unfeasible, or would your company/customers be open to such a solution?
Bad guys use a botnet (compromised residential computers and routers) to defeat rate limiting and ip-based blocking.
Step one in doing this is identifying which requests are coming from the same agent. Guess what fingerprinting helps with.
Would not solve everything but still help a lot.
Javascript systems have long had polyfills for varied browser feature comparability gaps.
Whether you agree with these, making probing detection via fingerprinting illegal would take away this lever. Making surreptitious tracking via fingerprinting illegal? Even for state actors?
Yeah, that's probably reasonable. If someone is going to wear a tracking collar in exchange for "free" services, a little disclosure makes sense.
Yeah, tracking bad, I get it, but are whatever damages that kind of legislation would prevent (probably nothing measurable) really more important than fixing the easy, in our face social problems that politicians could instead be focusing on?
(I have no idea, I don't know too much about this)
It's passive surveillance on the order of billions of people. It's not a mom-and-pop shop.
"Information gained via side-channel for the purpose of correlating individuals."
But you'd have to add an enormous amount of legalese after that to make it ironclad. They'll start arguing "this isn't a side-channel", "we're targeting bots, not individuals", etc. You'd have to define every word in that sentence very carefully.
I'd make it sweeping. "Individual" can mean "person", "bot", "suspected bot", "AI agent", "a piece of autonomous or non-autonomous software", basically anything. The "side-channel" definition might get trickier, but I'd rather legit use-cases get burned than privacy get burned.
The OP was downvoted, but I agree. I think fingerprinting should be in the same criminal category as an illegal wiretap.
I guess it’s good, on net, that something gets captured and shared about some of the ideas in this category. Ones that are interesting enough to notice, but not worth the effort to write up properly.
Especially given that the people who know the things aren’t always the people who enjoy writing about the things.
I wonder if there’s space and momentum for a mutualistic kind of arrangement where humans slog through the slop and shape up the worthwhile ideas.
If I start the Clanker Digest, will y’all join our rota? Not taking on the whole slop ocean, just pieces (like this) we nominate as potentially interesting?
Or is that just what we’re doing here already?
This guy: https://dreamsongs.com/WorseIsBetter.html
Maybe the right solution is an LLM that reads the fingerprinting code and adapts the counter-measure accordingly in real time.
The OS doesn't really matter, the amount of entropy it contains is very low. As long as the anonymity set of browser-users is large it's all good. And I believe Tor Browser accomplishes this objective.
OS rendering differences can likely betray you even when canvas extraction is blocked/noised. At least one tor-browser dev has publicly confirmed that you can't even hide the difference between X11 and Wayland[1], nevermind two entirely different OSes.
[1] https://forum.torproject.org/t/linux-is-it-alright-to-run-th...
https://developer.mozilla.org/zh-CN/docs/Web/API/Window/scre...