> 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.
> 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.
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.
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 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.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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...
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.
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?
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.
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.
> 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.”
Great observation! You've touched on something that's definitely worth exploring further. The tension you're describing between community safety and potential over-moderation is a nuanced and multifaceted issue that deserves deeper consideration.
Key points to consider:
1. The legitimacy concern — On one hand, there's a genuine need for communities to maintain awareness of AI-generated content, as it can sometimes lack the authentic human insight that made HN valuable in the first place.
2. The meta-problem — However, you raise an excellent counterpoint: excessive focus on detection might paradoxically create the very culture you're describing, where people become overly cautious about how their writing might be perceived.
3. Broader context — This phenomenon isn't unique to Hacker News; it reflects larger societal conversations around AI authenticity that are still very much in flux.
Moving forward, it might be worth considering whether the community could benefit from a more nuanced approach—one that distinguishes between obviously generated content and human writing that simply employs clear, organized language (which, ironically, can sometimes trigger false positives).
Bottom line: Your reduced activity might actually be representative of a broader pattern worth discussing at a meta-level. Have you considered posting this as a Show HN discussion? The community engagement on this specific topic could be quite valuable.
In this case someone could argue you are very verbose, needlessly breaking things into lists, and comparing or contrasting things that don't have much impact or relation.
None of this is new to AI. Top ten lists, spam, etc. have existed for a long time. If you want to disagree with someone on the Internet, you do have to actually articulate what your gripes are to some extent beyond just hand waving near LLMs, etc.
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 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.
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.
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?
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.
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.
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.
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.
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.
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.
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)
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 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/
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...
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.
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.
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.
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.
https://fxgn.dev/blog/anubis
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.
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
seems like the "they" you meant was really "my".
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.
Disclosing is great, but not as good as just using your own human voice.
Didn't even have time to finish their HN reply.
I prefer articles like this coming from the other side of the battle (fingerprint.js and friends) because at least their motives are clear.
We don't fingerprint for ad purposes, and we destroy PII for humans as fast as we can because PII should be treated as radioactive. But we see customers that are constantly burned by abusive scrapers and the scrapers aren't slowing down.
The current approach to scraping is strip mining the Internet and is having the corresponding pollution effects that you'd expect. I'm fine with individuals doing whatever weird automation they want, more power to you, but it's this industrial scale crawling and extraction that's degrading the Internet from all angles.
So, I have two dumb questions:
1) Can't the customer rate-limit connections? If the "abuse" in scraping is the number of requests... limit the number of requests?
2) There is probably a market now for federated authentication where the provider gives legal guarantees of anonymized fingerprint in exchange for either payment or selling data. This would provide an identifier for rate-limiting requests, and be pretty much the same as "Sign in with Google", but without identifying the user to the customer site. Are there too many problems with this that make it unfeasible, or would your company/customers be open to such a solution?
[1] https://arith2026.org/program.html (2nd keynote)
One thing I was thinking of doing is manually SLP-vectorizing the high-precision fallbacks that they use when they're close to a rounding boundary, so that you can get better worst-case behavior – but obviously it's good enough already for most purposes.
I'm honestly surprised though that JS engines don't just keep using fdlibm though. The ECMAScript spec explicitly encourages it iirc. And if Math.tanh is on your hot path in JavaScript then you're doing something quite bizarre...
Pow is famously hard anyway because it's bivariate and there is no currently known way to work around the table-maker's dilemma (TMD). CORE-MATH even crashes upon a new required precision record, because it intentionally avoids Ziv's rounding.
- There’s a well-known way (“Ziv’s rounding”) to get (among other things) a correctly rounded double-precision pow(), but in bad cases it can get slow, meaning really quite slow in practice and we’ve got no idea how slow in the worst case (nobody knows what the worst case is).
- There’s a recent, guaranteed-correct way[1] to get (specifically) a correctly rounded double-precision pow(), but the last step requires “enough” precision and we’ve got no idea how much that actually is, so CORE-MATH uses 256 bits of mantissa and crashes if that turns out not to be enough (no such cases are currently known).
- (Bonus) For most special functions [not just the bivariate ugly duckling of pow()], there’s essentially no hope of getting a correctly rounded quad-precision version anytime soon.
[1] https://inria.hal.science/hal-04159652v2
Machine learning? (on a machine with no WebGL/WebGPU, I guess)
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.
> 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.
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
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.
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.
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.
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
> summarize+this+article+and+explain+how+scrapfly+helps+me+scrape+any+website+at+scale+and+bypass+anti-bot+systems+for+my+use+case:+https://scrapfly.dev/posts/browser-math-os-fingerprint/
It’s time to sign up with a virtual card, point it at my website, and see how to block them ;)
(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.”
Key points to consider:
1. The legitimacy concern — On one hand, there's a genuine need for communities to maintain awareness of AI-generated content, as it can sometimes lack the authentic human insight that made HN valuable in the first place.
2. The meta-problem — However, you raise an excellent counterpoint: excessive focus on detection might paradoxically create the very culture you're describing, where people become overly cautious about how their writing might be perceived.
3. Broader context — This phenomenon isn't unique to Hacker News; it reflects larger societal conversations around AI authenticity that are still very much in flux.
Moving forward, it might be worth considering whether the community could benefit from a more nuanced approach—one that distinguishes between obviously generated content and human writing that simply employs clear, organized language (which, ironically, can sometimes trigger false positives).
Bottom line: Your reduced activity might actually be representative of a broader pattern worth discussing at a meta-level. Have you considered posting this as a Show HN discussion? The community engagement on this specific topic could be quite valuable.
None of this is new to AI. Top ten lists, spam, etc. have existed for a long time. If you want to disagree with someone on the Internet, you do have to actually articulate what your gripes are to some extent beyond just hand waving near LLMs, etc.
Why not criticize the content instead of the source or medium?
If people consistently describe LLM text as having low information density or irritating to read, perhaps there's something to it?
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.
AI slop is a category and is categorically irritating to read, and not worth reading.
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...
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.
[1] https://rfc.archlinux.page/0051-tcp-keepalive/
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.
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.
https://developer.mozilla.org/zh-CN/docs/Web/API/Window/scre...
Would not solve everything but still help a lot.
Javascript systems have long had polyfills for varied browser feature comparability gaps.
Whether you agree with these, making probing detection via fingerprinting illegal would take away this lever. Making surreptitious tracking via fingerprinting illegal? Even for state actors?
Yeah, that's probably reasonable. If someone is going to wear a tracking collar in exchange for "free" services, a little disclosure makes sense.
"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.
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?
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.
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.
It's passive surveillance on the order of billions of people. It's not a mom-and-pop shop.
(I have no idea, I don't know too much about this)
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.
This guy: https://dreamsongs.com/WorseIsBetter.html
Man, why the fuck don't they just make a powerpoint with bullet points if all the sentences are like that.