> 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.
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.
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 stand by it
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
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.
> 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.
The HTTP User-Agent header was a mistake from the beginning. There is no legitimate need for the server to know what software the client is (or claims to be) running.
It was a mistake in the beginning too. If you want to serve different content to different people, you use two different URLs. There's never a valid case for doing it while hiding it from the user.
No, that misses the whole point of content negotiation (for language, et al). In the age of search engines though, different urls are often perferable.
NCSA Mosaic is the early graphical browser that begat Netscape Navigator that begat Firefox. Later came Internet Explorer, Safari, Chrome and so on
What was the point of spoofing in 1996
Maybe it was just for fun, judging by the examples in the "mosaic-spoof-agents" file
As a matter of practice, by default I do not send a user-agent header. I only send the minumum headers required. For me, that's almost always 1-2 for GET and 4 for POST
For the vast majority of websites I have accessed,^1 this header minimisation has zero effect on the success of the HTTP request
1. For example, I have used a database of sites submitted to HN as way to test if header minimisation affects HTTP request success
Generally I do not use a web browser to make HTTP requests. I perform text processing on the HTML, JSON or whatever is returned, using custom utilities. I store information in SQLite. I read this information as plain text, preferably 7-bit ASCII. I dislike UTF-8
Onlilne debates about "browser fingerprinting" always seem to focus on trying to "blend in", e.g., via "spoofing"
As such, because browser continue to get more bloated with "features", online commenters argue in favor of sending more and more data points to servers that can be used to create a fingerprint instead of reducing the amount of data sent
Because, according to their reasoning (or lack thereof), sending less data would "stand out"
True, but it's generally easier to "spoof" a client that sends less data than one that sends more. And the number of sites that require a user-agent header is still smaller than the number that don't
There is actually/obviously. It lets you identify bugs in well meaning clients. e.g. you can identify if IE v1.2.3 isn't handling form submissions correctly. It lets you serve content that works for clients with known issues or limitations.
When distributing software, it’s very useful to know which OS and which architecture the user is on in order to present them with the appropriate file.
I feel like this is with 2026 view where browsers are so mutually compatible.
In the bad old days there were so many differences between html, css and js behaviors that if you wanted your site to be nice you had to change it for the browser. The way css padding worked wasn't even the same. Feature detection was rarely viable for any of this.
No user agent would probably have only entrenched IE6 dominance even more by blocking you from deliberately making a site that works at all on other browsers (including IE7 for that matter)
I'm aware of that history and the User-Agent header was a mistake even back then. It took the pressure off of browser vendors and gave them an excuse to not fix their bugs.
road to hell is paved with good intentions. one could argue it would've made browser vendors fix their bugs, but with the side-effect that any behavior that isn't bug-compatible with IE becomes a bug. this would've ironically entrenched IE permanently.
The mistake was not claiming features rather browser client versions...
JS devs were kinda able to patch around the nonsense because they were able to feature-detect - part of the reason this stuck around was because no legitimate user or dev cared (or should care). But the header was mostly (useless) noise, and the people spoofing were dealing with the couple bad apples of the time.
Of course, defining features is easier said than done, and a standards body is a challenging environment to define these in...
I get why people are fingerprinting bots and others are working around it, but neither are "legitimate" applications - if your content is public, it's public, end of story. And working around these controls to sell botnet access to sites is equally illegitimate - nobody has a right to resell content they do not own...
I just can't see how it could make sense to define features when a ton of the the behavior wasn't even intentional but just tons of bugs. I recall debugging issues that only reproduced in "IE7 compatibility mode of IE8" which didn't reproduce in either IE7 or IE8. And that was already after the standards were taken at all seriously
And you can see how well that worked by how many user-agents are such a sane, terse description of the browser rather than a hodgepodge of random words that give the impression that they're trying to seem like every browser at once.
> I feel like this is with 2026 view where browsers are so mutually compatible.
I wish this was the case. Unfortunately, companies that work on non-Chromium browsers need to employ dedicated web compatibility teams to either a) help website users fix non-standard (i.e. Chrome only) HTML/CSS/JS, or b) replicate Chromium-like behaviour for specific (very popular) websites so that they work "correctly".
There's also the websites that deliberately block certain browsers which is what tools like "chrome-mask"[1] are built to solve.
Infinite captcha welcomes those who are using FF and linux on stackoverflow. Easier to skip its links in search results than waste time solving it (captcha never finishes).
Some scrape activity happens because I can't obtain the data any other way. I would be thrilled if certain retailers had price and availability data as an API so I could not bother with the bulk of scrape and process.
As much as I would like pricing APIs as well, the economics don’t add up for retail, and it would effectively lead to a scalper’s market.
A regular Joe consumer shouldn’t have to learn python to get thier foot in the door because some arbitrage purchaser has automated a ‘best deal’ purchasing bot based on real time pricing APIs.
It is when you're doing it like the LLM companies are: at scale, to the degree that you're taking down my site, without my consent by masking your user-agent, for the purpose of stealing data I didn't authorize you to have.
> at scale, to the degree that you're taking down my site
Fair. Scrapers should be polite and do their utmost to consume the smallest possible amount of resources.
> without my consent by masking your user-agent
Your consent is not required. It's my user agent. I set it to whatever I want.
> for the purpose of stealing data I didn't authorize you to have
Data can't be "stolen", only copied.
You set up an HTTP server that literally sends people the data when they request it. Don't do that if you don't want people to have the data. Secrecy is the only possible defense.
Though, scrapers can certainly steal capacity through conversion for their own use. When they do so, they permanently deprive the site owner and other users the beneficial use of that capacity at that time.
I'm speaking morally, not legally. Though, in the US at least, there are parallels with free newspapers. You're allowed to take one for free. It's not legal to clear the whole rack.
> You set up an HTTP server that literally sends people the data when they request it. Don't do that if you don't want people to have the data.
By the same argument I could say: If I send you an exploit and you execute it, don’t complain that your setup fell for it. Just don’t download and run random data from the internet.
In reality there’s a consent and expectation beyond the pure technicals.
> Just don’t download and run random data from the internet.
I don't. I go out of my way to filter everything. Scraping is but one of the tools I use to do it. I want just the data that I actually care about, not people's javascripted hot mess websites full of malware-vectoring ads, fingerprinting and tracking.
I don't let my computers talk to strangers either. My servers don't respond to just anyone, they only reply to me, and only after I've cryptographically authenticated. When others try to talk to them it's like they're not even there.
But people want their computers to talk to strangers, don't they? They want to serve pages and pages of ads to massive audiences. Unlike your exploitation example, nobody's actively invading their computers and exfiltrating data. Breaking into someone else's computers and dumping their private databases is one thing. We're just requesting the exact same data that they're more than happy to send out to literally anyone who shows up with a browser, through the exact same channels even. So I really have no sympathy.
I documented some crude methods that can stop most of that without a CDN. [1] There will be some false positives so I guess it depends on ones priorities which methods if any to implement or test on a throw-away test site. Not perfect, nothing is. I am watching hundreds of bots sending SYN's and the daemons are oblivious to them. The only method I have not played around with yet is #7 ssl fingerprinting.
There are additional methods I chose not to document such as limiting access to logged in accounts that require double-opting-in to acceptable use policies and terms of use, not that most scrapers would give a toss. That it too much whack-a-mole for me personally. That method requires progressively adding friction to account creation and that comes with some pros and cons.
A Flock camera isn’t an invasion of privacy. Fleets of hundreds or thousands of Flock cameras feeding into a massive dataset is definitely an invasion of privacy, and hardly sudden.
More precisely: pinpointing you at a given place and time does not need a warrant. Collecting many such pinpoints, allowing authorities to reconstruct your exact movements at some point in the future (without needing to flag you or issue a BOLO or whatever), does.
Unfortunately the response to that right now is to nuke everything that isn't within a strict set of constraints. That helps with the bad bulk-scrapers, but hits everyone else as well as collateral damage.
Something like Anubis in front of the server to protect it might be an option. It sucks that we have to resort to that yes, but it seems the least bad option currently (better than the entire internet going through Cloudflare at least).
The idiotic "stealing" argument again? At least use "piracy" if you want to be correct...
The moment you openly publish information on the Internet, you have already given consent. There are other solutions to bandwidth usage.
User-agent discrimination should be illegal. All it does is further the control that Big Tech has, and help authoritarian governments with their control too.
Couldn't agree more. Nonsense like remote attestation too. If this discrimination persists, it will lead to the destruction of what little computing freedom we still have.
What data is being stolen? Are you referring to copyright violation or something else? If you don't want LLM companies to scrape a site then just restrict access to authorized users. Simple.
This is the same mindset of criminal in a low trust society btw
"If you didn't want me to do this, you should had a fence/cameras/security guards. You shouldn't have dressed like that. You shouldn't have put your phone in that pocket."
Excusing trillion dollar corporations like low level criminals is embarrassing. Society shouldn't have to lock itself up because bad actors are spreading everywhere. The bad actors should just be removed.
That's what's being done, isn't it? Fingerprinting technologies and proof of work are trying to authorize people and block bots. Unfortunately, companies like these are trying to bypass the authorization controls.
If these scraping companies would respect some kind of X-Scraping-Permitted header, this whole process would be a lot better, but that's not going to happen in an industry that has already normalized using botnets.
Has the internet made the average human’s life better? As someone that lived in both eras I have to say no. If you want to improve humanity greatly and prevent currently 8.3 billion people’s misery and counting, you build a time machine and prevent Tim Berners-Lee from inventing it in the first place. But it wouldn’t help, because someone else would still invent this torture nexus of hyperconnected human minds.
The internet was amazing before the big techs started centralizing everything, before governments started fragmenting it into censored regional networks...
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. Identical browser with an extension that overrides the fingerprinting headers and it works perfectly.
Also as an additional note: Cloudflare does TCP fingerprinting, because no cloudflare pages will work (and send you into an infinite loop of unsolvable captchas) when these headers mismatch with the tcp window and other options in the handshake frames.
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 damn web app. That is a completely unjustified waste of hardware resources and should be illegal. But here we are. Wasting one laptop at a time for absolutely no reason.
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?
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.
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.
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 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.
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.
> 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.
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 exceptional/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.
This only happens with values outside the range of your fixed point type if you use larger floats as mentioned above. I consider that 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. You can get the same thing today just by changing compiler flags. 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?
> 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.
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. The remaining cases are mostly things you won't do in fixed point. 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.
Fixed-point arithmetic provides uniform absolute precision; floating-point arithmetic provides almost-uniform relative precision, as used by scientists and engineers for literally centuries (“significant digits” except the binary version is more uniform than the decimal one customary with pencil and paper).
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.
- 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. Mathworks floating point expert on the LLVM team with a relevant PhD to do it correctly [0].
I go to the conference frequently and know the organizing committee. It depends on the year (2025 and 2026 did it, but not 2024). And if someone decides to register arith20xx.org, I doubt the conference would buy it.
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:
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.”
The medium is the message, which is especially true when it exists as content-marketing for their anti-anti-scraping product for AI companies to use to improve their ability to emulate blogs, among other things.
Those are closer to real objective analysis. Much better than hand waving near LLMs and dismissing the content without articulating why. My guess is that a comment that directly says that doesn't get as much traction and depending on how straight-faced it was could be violating the guidelines on accusing someone of manipulating HN, etc.
Why's that bad? It's valuable to discuss whether a presentation should have been a blog post, a video, or a tech talk. The same logic applies to LLM text.
If people consistently describe LLM text as having low information density or irritating to read, perhaps there's something to it?
None of that is specific to the actual content. Might as well just say "I don't like it" which is also not objective analysis.
This article was about math functions, chrome, etc. If the author got something wrong, mention that, or if you don't like the pacing or how the content was divided into pieces, etc.
All of the issues with AI generated content can be explained further and in-depth because it has such a unique fingerprint in the pacing, verbosity, long-winded explanations, etc.. It also shows lack of effort. Just give me the prompt and the findings, I can write the article.
AI slop is a category and is categorically irritating to read, and not worth reading.
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.
Hopefully it takes much less than a millisecond to render a single emoji. Ca. 2018 I wrote some bad OpenGL code which could render a swarm of millions of poop emoji on a rather large display at 60 fps, so that was less than ~16e-6 ms per emoji.
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 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.
It's not surprising that JS would out you, what I am wondering if whether or not volunteering OS information is foolish when it may not be possible to determine without JS.
Why give up information when you don't have to? Some people disable JS at least some of the time.
Yeah, I generally agree with that viewpoint, but you are giving up that information, even without JS.
Your TCP stack can be fingerprinted through long enough observation. Windows, Mac, and Linux all look different on a network level. It's not as simple `if XYZ then OS = Windows`, it's more holistic/probabilistic, but it's possible nonetheless.
e.g. One thing that bugs me about arch linux is that they recently changed the kernel default TCP keepalive time to be shorter (much shorter[1]), making arch users stand out a lot. So, not only can a fingerprinter identify your OS, they might be able to pin down your exact distro based on TCP behavior alone.
I guess my point is that hiding the OS would be a massive amount of effort to plug a hole that cannot be plugged without effectively controlling the entire OS. TB/MVB is limited in what it can do by itself.
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.
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?
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.
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.
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.
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
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.
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.
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.
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.
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 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?
> Why should it be illegal for me to recognize the way you walk into my store
If you did it in just your store, that wouldn't be a problem. The correct analogy, however, is "why should it be illegal for me to attach a perfectly traceable and invisible air-tag to you when you enter my store, without your explicit consent, and subsequently follow and document your every movement no matter where you go, as long as that location has a business relationship with my store, and also my store is the most popular chain on the planet that has business relationships with basically any relevant business that exists." And I don't think the answer to this one shouldn't be particularly difficult to arrive at.
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.
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.
Holy slippery slope, Batman. Just because you don't have a right to know everything about you, follow you home, and see what you bought elsewhere, doesn't mean I'm not allowed to observe how your [thing claiming to be a browser] behaves when it connects to my website.
If you want to make it harder to guess whether you're human or a malicious bot, you're going to find yourself clicking on more than just traffic lights and bicycles in the near future.
There's nothing wrong with websites choosing to comply with particular privacy standards. This should be voluntary and used as a trust signal. A website that promises to follow certain standards should be legally accountable if it breaks that promise, but it should not be mandatory to make such promises.
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.
> 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.
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.
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 stand by it
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
seems like the "they" you meant was really "I".
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.
Isn’t “just post the prompt” a joke? That only works if the content was one-shot, and I bet that (much like code) most isn’t.
Do what people did before there were LLMs: Just post the data and some quick notes. It's fine, people appreciate the brevity.
Disclosing is great, but not as good as just using your own human voice.
> otherwise I would never publish an article due to lack of time, and I assume
Didn't even have time to finish their HN reply.
The LLM has a good point. I personally don't care what or who wrote it if it's true.
> 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.
It's sometimes easier to lie than to tell the truth, and being on Linux telling the truth gets me more scrutiny than those pretending to be legit.
Same as sites the block "wget" as a user agent, but then you can pass in a -U "Cheetos/10" and sail right in.
I'd be fine if they throttled the connection, or a contact page. Every little bit helps build a high trust society.
The HTTP User-Agent header was a mistake from the beginning. There is no legitimate need for the server to know what software the client is (or claims to be) running.
It certainly wasn't a mistake in the beginning, but it's certainly a mistake now.
It was a mistake in the beginning too. If you want to serve different content to different people, you use two different URLs. There's never a valid case for doing it while hiding it from the user.
No, that misses the whole point of content negotiation (for language, et al). In the age of search engines though, different urls are often perferable.
"The HTTP User-Agent header was a mistake form the beginning."
User-Agent spoofing was added to NCSA Mosaic in 1996. The public www was three years old and text-only clients were still in widespread use
https://raw.githubusercontent.com/alandipert/ncsa-mosaic/mas...
NCSA Mosaic is the early graphical browser that begat Netscape Navigator that begat Firefox. Later came Internet Explorer, Safari, Chrome and so on
What was the point of spoofing in 1996
Maybe it was just for fun, judging by the examples in the "mosaic-spoof-agents" file
As a matter of practice, by default I do not send a user-agent header. I only send the minumum headers required. For me, that's almost always 1-2 for GET and 4 for POST
For the vast majority of websites I have accessed,^1 this header minimisation has zero effect on the success of the HTTP request
1. For example, I have used a database of sites submitted to HN as way to test if header minimisation affects HTTP request success
Generally I do not use a web browser to make HTTP requests. I perform text processing on the HTML, JSON or whatever is returned, using custom utilities. I store information in SQLite. I read this information as plain text, preferably 7-bit ASCII. I dislike UTF-8
Onlilne debates about "browser fingerprinting" always seem to focus on trying to "blend in", e.g., via "spoofing"
As such, because browser continue to get more bloated with "features", online commenters argue in favor of sending more and more data points to servers that can be used to create a fingerprint instead of reducing the amount of data sent
Because, according to their reasoning (or lack thereof), sending less data would "stand out"
True, but it's generally easier to "spoof" a client that sends less data than one that sends more. And the number of sites that require a user-agent header is still smaller than the number that don't
There is actually/obviously. It lets you identify bugs in well meaning clients. e.g. you can identify if IE v1.2.3 isn't handling form submissions correctly. It lets you serve content that works for clients with known issues or limitations.
When distributing software, it’s very useful to know which OS and which architecture the user is on in order to present them with the appropriate file.
I feel like this is with 2026 view where browsers are so mutually compatible.
In the bad old days there were so many differences between html, css and js behaviors that if you wanted your site to be nice you had to change it for the browser. The way css padding worked wasn't even the same. Feature detection was rarely viable for any of this.
No user agent would probably have only entrenched IE6 dominance even more by blocking you from deliberately making a site that works at all on other browsers (including IE7 for that matter)
I'm aware of that history and the User-Agent header was a mistake even back then. It took the pressure off of browser vendors and gave them an excuse to not fix their bugs.
road to hell is paved with good intentions. one could argue it would've made browser vendors fix their bugs, but with the side-effect that any behavior that isn't bug-compatible with IE becomes a bug. this would've ironically entrenched IE permanently.
The mistake was not claiming features rather browser client versions...
JS devs were kinda able to patch around the nonsense because they were able to feature-detect - part of the reason this stuck around was because no legitimate user or dev cared (or should care). But the header was mostly (useless) noise, and the people spoofing were dealing with the couple bad apples of the time.
Of course, defining features is easier said than done, and a standards body is a challenging environment to define these in...
I get why people are fingerprinting bots and others are working around it, but neither are "legitimate" applications - if your content is public, it's public, end of story. And working around these controls to sell botnet access to sites is equally illegitimate - nobody has a right to resell content they do not own...
I just can't see how it could make sense to define features when a ton of the the behavior wasn't even intentional but just tons of bugs. I recall debugging issues that only reproduced in "IE7 compatibility mode of IE8" which didn't reproduce in either IE7 or IE8. And that was already after the standards were taken at all seriously
And you can see how well that worked by how many user-agents are such a sane, terse description of the browser rather than a hodgepodge of random words that give the impression that they're trying to seem like every browser at once.
> I feel like this is with 2026 view where browsers are so mutually compatible.
I wish this was the case. Unfortunately, companies that work on non-Chromium browsers need to employ dedicated web compatibility teams to either a) help website users fix non-standard (i.e. Chrome only) HTML/CSS/JS, or b) replicate Chromium-like behaviour for specific (very popular) websites so that they work "correctly".
There's also the websites that deliberately block certain browsers which is what tools like "chrome-mask"[1] are built to solve.
[1] https://addons.mozilla.org/en-GB/firefox/addon/chrome-mask/
Infinite captcha welcomes those who are using FF and linux on stackoverflow. Easier to skip its links in search results than waste time solving it (captcha never finishes).
I get them all the time on Firefox on windows using a vpn.
Overriding useragent to chrome fixes it for some sites.
Some scrape activity happens because I can't obtain the data any other way. I would be thrilled if certain retailers had price and availability data as an API so I could not bother with the bulk of scrape and process.
As much as I would like pricing APIs as well, the economics don’t add up for retail, and it would effectively lead to a scalper’s market.
A regular Joe consumer shouldn’t have to learn python to get thier foot in the door because some arbitrage purchaser has automated a ‘best deal’ purchasing bot based on real time pricing APIs.
This tanh approach won’t tell you if you’re in a VM - it’ll report the guest OS
The Internet is a cesspool of scams now
scraping, however, is not intrinsically a scam.
It is when you're doing it like the LLM companies are: at scale, to the degree that you're taking down my site, without my consent by masking your user-agent, for the purpose of stealing data I didn't authorize you to have.
> at scale, to the degree that you're taking down my site
Fair. Scrapers should be polite and do their utmost to consume the smallest possible amount of resources.
> without my consent by masking your user-agent
Your consent is not required. It's my user agent. I set it to whatever I want.
> for the purpose of stealing data I didn't authorize you to have
Data can't be "stolen", only copied.
You set up an HTTP server that literally sends people the data when they request it. Don't do that if you don't want people to have the data. Secrecy is the only possible defense.
> Data can't be "stolen", only copied
Though, scrapers can certainly steal capacity through conversion for their own use. When they do so, they permanently deprive the site owner and other users the beneficial use of that capacity at that time.
I'm speaking morally, not legally. Though, in the US at least, there are parallels with free newspapers. You're allowed to take one for free. It's not legal to clear the whole rack.
> You set up an HTTP server that literally sends people the data when they request it. Don't do that if you don't want people to have the data.
By the same argument I could say: If I send you an exploit and you execute it, don’t complain that your setup fell for it. Just don’t download and run random data from the internet.
In reality there’s a consent and expectation beyond the pure technicals.
> Just don’t download and run random data from the internet.
I don't. I go out of my way to filter everything. Scraping is but one of the tools I use to do it. I want just the data that I actually care about, not people's javascripted hot mess websites full of malware-vectoring ads, fingerprinting and tracking.
I don't let my computers talk to strangers either. My servers don't respond to just anyone, they only reply to me, and only after I've cryptographically authenticated. When others try to talk to them it's like they're not even there.
But people want their computers to talk to strangers, don't they? They want to serve pages and pages of ads to massive audiences. Unlike your exploitation example, nobody's actively invading their computers and exfiltrating data. Breaking into someone else's computers and dumping their private databases is one thing. We're just requesting the exact same data that they're more than happy to send out to literally anyone who shows up with a browser, through the exact same channels even. So I really have no sympathy.
I documented some crude methods that can stop most of that without a CDN. [1] There will be some false positives so I guess it depends on ones priorities which methods if any to implement or test on a throw-away test site. Not perfect, nothing is. I am watching hundreds of bots sending SYN's and the daemons are oblivious to them. The only method I have not played around with yet is #7 ssl fingerprinting.
There are additional methods I chose not to document such as limiting access to logged in accounts that require double-opting-in to acceptable use policies and terms of use, not that most scrapers would give a toss. That it too much whack-a-mole for me personally. That method requires progressively adding friction to account creation and that comes with some pros and cons.
[1] - https://nochan.net/b/Internet-Crap/20260606-How-To-Block-Som...
I think the key word was "intrinsically".
It's like public photography, it's intrinsically legal, except when it's a Flock camera and then it's suddenly an invasion of privacy.
A Flock camera isn’t an invasion of privacy. Fleets of hundreds or thousands of Flock cameras feeding into a massive dataset is definitely an invasion of privacy, and hardly sudden.
More precisely: pinpointing you at a given place and time does not need a warrant. Collecting many such pinpoints, allowing authorities to reconstruct your exact movements at some point in the future (without needing to flag you or issue a BOLO or whatever), does.
Unfortunately the response to that right now is to nuke everything that isn't within a strict set of constraints. That helps with the bad bulk-scrapers, but hits everyone else as well as collateral damage.
Something like Anubis in front of the server to protect it might be an option. It sucks that we have to resort to that yes, but it seems the least bad option currently (better than the entire internet going through Cloudflare at least).
You can just use one line of JS instead
https://fxgn.dev/blog/anubis
The idiotic "stealing" argument again? At least use "piracy" if you want to be correct...
The moment you openly publish information on the Internet, you have already given consent. There are other solutions to bandwidth usage.
User-agent discrimination should be illegal. All it does is further the control that Big Tech has, and help authoritarian governments with their control too.
As with anything IP-related, the data is licensed under whatever terms you choose to impose. That’s the extent of the consent you’ve provided.
Permission to access is not the same as permission to use.
> User-agent discrimination should be illegal.
Couldn't agree more. Nonsense like remote attestation too. If this discrimination persists, it will lead to the destruction of what little computing freedom we still have.
What data is being stolen? Are you referring to copyright violation or something else? If you don't want LLM companies to scrape a site then just restrict access to authorized users. Simple.
This is the same mindset of criminal in a low trust society btw
"If you didn't want me to do this, you should had a fence/cameras/security guards. You shouldn't have dressed like that. You shouldn't have put your phone in that pocket."
Excusing trillion dollar corporations like low level criminals is embarrassing. Society shouldn't have to lock itself up because bad actors are spreading everywhere. The bad actors should just be removed.
Relax buddy, it's just HTTP requests. They're not stealing your phone.
That's what's being done, isn't it? Fingerprinting technologies and proof of work are trying to authorize people and block bots. Unfortunately, companies like these are trying to bypass the authorization controls.
If these scraping companies would respect some kind of X-Scraping-Permitted header, this whole process would be a lot better, but that's not going to happen in an industry that has already normalized using botnets.
No it's just intrinsically antisocial behavior
Scraping has never "intrinsically" been anti-social behaviour, you just don't like it.
Always was.
Has the internet made the average human’s life better? As someone that lived in both eras I have to say no. If you want to improve humanity greatly and prevent currently 8.3 billion people’s misery and counting, you build a time machine and prevent Tim Berners-Lee from inventing it in the first place. But it wouldn’t help, because someone else would still invent this torture nexus of hyperconnected human minds.
The internet was amazing before the big techs started centralizing everything, before governments started fragmenting it into censored regional networks...
Fun fact that will blow your mind:
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. Identical browser with an extension that overrides the fingerprinting headers and it works perfectly.
Also as an additional note: Cloudflare does TCP fingerprinting, because no cloudflare pages will work (and send you into an infinite loop of unsolvable captchas) when these headers mismatch with the tcp window and other options in the handshake frames.
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 damn web app. That is a completely unjustified waste of hardware resources and should be illegal. But here we are. Wasting one laptop at a time for absolutely no reason.
[1] https://github.com/cookiengineer/chromium-profiles
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 disagree, fingerprinting is necessary to track humans and it will be used regardless of scrapers being there or not.
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.
Do you think this could drive a shift towards more efficient web tech? I.e. more static websites, or websites served by faster software?
> 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?
> Can't the customer rate-limit connections?
Bad guys use a botnet (compromised residential computers and routers) to defeat rate limiting and ip-based blocking.
1) Scrapers often rotate ip per request, rate limiting doesn’t help
Rate limiting requires them to buy more IPs (which are not free) and slows down scraping.
Yes, that’s what the big scrapers are doing (frontier AI labs). They have infinite money for this.
> If the "abuse" in scraping is the number of requests... limit the number of requests?
Step one in doing this is identifying which requests are coming from the same agent. Guess what fingerprinting helps with.
Why is it necessary to track humans? It might be more profitable for advertising but that's not the same as necessary.
Tracking humans isn't necessary. Fingerprinting is necessary to tracking humans.
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)
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.
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.
[1] https://inria.hal.science/hal-04159652v2
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.
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.
Representations other than the standard IEEE-754 can store floats in arbitrary precision.
> And if Math.tanh is on your hot path in JavaScript then you're doing something quite bizarre...
Machine learning? (on a machine with no WebGL/WebGPU, I guess)
Sure, but you'd use a low-precision approximation for that; you don't need full double precision
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.
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.
> 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.
Maybe using a bigger float type is cheating, but it's basically free because of the ubiquitous support for floats.
This only happens with values outside the range of your fixed point type if you use larger floats as mentioned above. I consider that 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. You can get the same thing today just by changing compiler flags. 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
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?
[0] https://fpchecker.org/
> 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.
I'm sure it would, but my argument is centered around the world we actually live in right now.
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. The remaining cases are mostly things you won't do in fixed point. 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.
Fixed-point arithmetic provides uniform absolute precision; floating-point arithmetic provides almost-uniform relative precision, as used by scientists and engineers for literally centuries (“significant digits” except the binary version is more uniform than the decimal one customary with pencil and paper).
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.
Correct transcendentals are also difficult in fixed point. When pigweed was implementing them for their fixed impl, they got help from from an ex. Mathworks 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
it's very common to have to implmeent algorithms on microcontrollers with no floating point or on FPGAs...
Tangential, but wow do they really register a new domain for each year and renew it in perpetuity?
arith2027.org taken, arith2028.org available.
Well, there's an arbitrage opportunity if I ever saw one
I go to the conference frequently and know the organizing committee. It depends on the year (2025 and 2026 did it, but not 2024). And if someone decides to register arith20xx.org, I doubt the conference would buy it.
They would just choose a different domain name, it's not that important and the previous years tend to forward link anyway.
Thanks for the writeup, claude
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:
> 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/
They are quite ‘innovative’, I’ll give them that.
It’s time to sign up with a virtual card, point it at my website, and see how to block them ;)
Please share with the class :)
Yeah, interesting finding in the headline, the rest is just Claude.
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.”
Ooh, the disclaimer is new, it wasn't there originally: https://web.archive.org/web/20260712212920/https://scrapfly....
Damn I literally came here to say "it's nice to see an actual disclaimer!"
And the other half of the community seems fixated on upvoting AI slop.
Sounds needlessly divisive.
Why not criticize the content instead of the source or medium?
The medium is the message, which is especially true when it exists as content-marketing for their anti-anti-scraping product for AI companies to use to improve their ability to emulate blogs, among other things.
Those are closer to real objective analysis. Much better than hand waving near LLMs and dismissing the content without articulating why. My guess is that a comment that directly says that doesn't get as much traction and depending on how straight-faced it was could be violating the guidelines on accusing someone of manipulating HN, etc.
I'm happy with how much I said in my original comment, too. It's mostly subtext.
Why's that bad? It's valuable to discuss whether a presentation should have been a blog post, a video, or a tech talk. The same logic applies to LLM text.
If people consistently describe LLM text as having low information density or irritating to read, perhaps there's something to it?
"The content is AI slop and not worth reading"
None of that is specific to the actual content. Might as well just say "I don't like it" which is also not objective analysis.
This article was about math functions, chrome, etc. If the author got something wrong, mention that, or if you don't like the pacing or how the content was divided into pieces, etc.
All of the issues with AI generated content can be explained further and in-depth because it has such a unique fingerprint in the pacing, verbosity, long-winded explanations, etc.. It also shows lack of effort. Just give me the prompt and the findings, I can write the article.
AI slop is a category and is categorically irritating to read, and not worth reading.
We all want signal and no noise, but complaining about whether or not it's noise is just more noise.
It's a signal to those who haven't read it yet that it isn't worth reading
My 8 year old nefew can come into random HN threads and post "this is trash yo" and that would also be the same signal I suppose.
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.
Hopefully it takes much less than a millisecond to render a single emoji. Ca. 2018 I wrote some bad OpenGL code which could render a swarm of millions of poop emoji on a rather large display at 60 fps, so that was less than ~16e-6 ms per emoji.
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 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.
[1] https://forum.torproject.org/t/linux-is-it-alright-to-run-th...
It's not surprising that JS would out you, what I am wondering if whether or not volunteering OS information is foolish when it may not be possible to determine without JS.
Why give up information when you don't have to? Some people disable JS at least some of the time.
> Why give up information when you don't have to?
Yeah, I generally agree with that viewpoint, but you are giving up that information, even without JS.
Your TCP stack can be fingerprinted through long enough observation. Windows, Mac, and Linux all look different on a network level. It's not as simple `if XYZ then OS = Windows`, it's more holistic/probabilistic, but it's possible nonetheless.
e.g. One thing that bugs me about arch linux is that they recently changed the kernel default TCP keepalive time to be shorter (much shorter[1]), making arch users stand out a lot. So, not only can a fingerprinter identify your OS, they might be able to pin down your exact distro based on TCP behavior alone.
I guess my point is that hiding the OS would be a massive amount of effort to plug a hole that cannot be plugged without effectively controlling the entire OS. TB/MVB is limited in what it can do by itself.
[1] https://rfc.archlinux.page/0051-tcp-keepalive/
> TCP stack can be fingerprinted
How does that apply to Tor? It uses custom packets. The entry node may be able to obtain a TCP fingerprint but that's all.
It doesn't. This case applies more to MVB.
Tor Browser straight up does not even modify navigator.platform at all, so it's incredibly easy to see when you're not using e.g. Windows.
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 hope this eventually ends up in https://coveryourtracks.eff.org/ so I can see how unique my math functions are relative to a larger population.
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?
just inject this with your favorite JS injection plugin
it's elegant, but i prefer:
since tanh is probably being used as a sigmoid, it's probably better to replace with just randomly changing the sign.
The article addresses this: search for "No noise".
Multiple anti-bot vendors will detect that replacement and use it as part of their fingerprinting process.
Great, now you'll be outed as "hides fingerprint", which is probably more identifying than if you returned a normal value.
https://xkcd.com/1105/
If this becomes common, it's trivially detectable with good ol' toString().
It's trivial to replace toString() as well
Maybe the right solution is an LLM that reads the fingerprinting code and adapts the counter-measure accordingly in real time.
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.
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.
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.
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
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.
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.
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.
This is interesting, but even without relying on JS, most users are already fingerprintable by the combination of IP + user agent.
Yes, but it's important that people who care about not being tracked have options, even if it's not most people.
What about TOR or VPNs + faking user agents?
Can't we make fingerprinting illegal, as in, jailtime illegal?
Would not solve everything but still help a lot.
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.
Yeah, the problem is how the data is kept and abused afterwards.
I don't think it'd be possible to define fingerprinting narrowly enough to not also outlaw perfectly normal and legitimate usecases.
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 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?
> Why should it be illegal for me to recognize the way you walk into my store
If you did it in just your store, that wouldn't be a problem. The correct analogy, however, is "why should it be illegal for me to attach a perfectly traceable and invisible air-tag to you when you enter my store, without your explicit consent, and subsequently follow and document your every movement no matter where you go, as long as that location has a business relationship with my store, and also my store is the most popular chain on the planet that has business relationships with basically any relevant business that exists." And I don't think the answer to this one shouldn't be particularly difficult to arrive at.
Well it's not really an airtag, I don't "attach" anything to your browser when I check what its GPU can do.
That's just a description of you that I share with my other stores. Casinos, Target, Burger King, etc all do this when you get 86'd, for example.
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.
Yes, and we need a name for the fallacy of GP. It's a recurring theme.
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.
Because you don't have a right to know everything about me, follow me to my home, my purchasing preferences, and so on and so forth.
Holy slippery slope, Batman. Just because you don't have a right to know everything about you, follow you home, and see what you bought elsewhere, doesn't mean I'm not allowed to observe how your [thing claiming to be a browser] behaves when it connects to my website.
If you want to make it harder to guess whether you're human or a malicious bot, you're going to find yourself clicking on more than just traffic lights and bicycles in the near future.
> 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?
If you have that right, the public should have the right to know you're doing this before they enter your store, so they can avoid it.
Same with the websites, they should, legally, have to say they're about to fingerprint you so that you can close your browser tab and never come back.
There's nothing wrong with websites choosing to comply with particular privacy standards. This should be voluntary and used as a trust signal. A website that promises to follow certain standards should be legally accountable if it breaks that promise, but it should not be mandatory to make such promises.
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.
The thing is that's not done on purpose and too hard to figure out how this has an impact underneath, if you read the v8 commit https://chromium.googlesource.com/v8/v8/+/c1486295ae5bcb0f8f... it's on a complete good faith
With companies like these, "plausible deniability" is more likely.
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.
JavaScript was a mistake.
Who was it that said: "worse is better"?
This guy: https://dreamsongs.com/WorseIsBetter.html
Goes back in time. Uninvents JS. Everyone using Shockwave Flash blob to run their code. Enjoy!
I am not the NSA, but on an unrelated note, this delights me!
This is AI slop, written for a company that is contributing to the enshittification of the web.
I think the screen resolution is also fingerprintable. That is why a browser should resize your window to a random size each time you visit a website.
browser report where your browser window (not position in tab) is even page itself never need to use it.
https://developer.mozilla.org/zh-CN/docs/Web/API/Window/scre...
how hardened are modern browsers with respect to detecting underlying os? seems like there would be loads of gaps?
There are boatloads of gaps.
Sounds almost like allowing web pages to run scripts was a mistake.
Interesting reporting, marred by obvious llm-slop-sounding writing. "You are not building..., you are ..."
Why "slop-sounding"? It's definitely LLM slop.
Man, why the fuck don't they just make a powerpoint with bullet points if all the sentences are like that.