I think it's great that Firefox is finally doing more to combat fingerprinting. For a long time, they lagged a bit behind Brave in this regard. That said, unfortunately, neither browser has been able to do anything about Cloudflare Turnstile yet. Kagi, for example, uses it to fingerprint users.
To make your data more accessible AND reduce server load. More and more people are using AI, so there will be more and more bots as the trend seems to be accessing data with your AI, and maybe, only sometimes, actually reviewing what it found. I'm afraid that if you don't at least start to consider how we might accommodate the bots, you'll be walling off more and more real users going forward.
A wide portion of the Internet is not ad supported. Consider a user searching for product support: the company benefits from the user self-solving the issue without having a ticket filed.
This, may, however be to the detrimental of discussion platforms, but if that drives people to self hosted discussion platforms instead of relying on reddit, then it is a net positive.
Discourse's most recent blog delves into this and is an interesting read, I will submit that I think.
> To make your data more accessible AND reduce server load.
Wait, how do you reduce server load by allowing traffic from bots?
> More and more people are using AI, (...)
That's specious reasoning. Sites provide data for their users to consume, and in some cases their business model relies on real people consuming their content.
If you replace "bots" with "scrapers", which is a specific kind of bot, what conclusions do you draw?
> I'm afraid that if you don't at least start to consider how we might accommodate the bots, (...)
Wait, you think this problem is new? What do you think companies do with crawlers and scrapers?
All repositories on git.zajc.tel can be git clone'd from their URL. The clone URL is also listed on every repository's summary page. Unlike the HTML pages, the clone endpoints are not ratelimited, have no bot check, and give you the entire repository with all history without having to crawl billions of pages.
this is bad faith argument. You are well aware that the majority of bots are used for negative purposes, at best, those purposes are neutral.
The situation you describe is certainly legitimate and useful, but is not the norm. Separating legitimate bots from the rest is currently not possible reliably.
Can you please tell whoever it is at Mozilla to stop working on that.
This feedback isn't directed at any one person but that proposal impressively suffers from the simultaneous problems of Being Way Too Fucking Complicated and Proposing to Make the Web Better but Actually Making it Way Worse (for Everyone Except Entrenched Megacorps). It's the exact same problem that Google's "anonymous ad attribution" attestation swarms suffered, and luckily that never came to pass.
From looking at the pictures in that article, it seems like in order for me to be able to browse "protected" sites (aka, most of the corporate-owned web, once they are aware that this exists and turn it on because "bots bad") my browser is going to have to negotiate for some scant amount of "allowed access" tokens or other such thing, through some complicated protocol that halts any chance of us realizing a future for the web that looks any much different from "locked down approved browsers visiting approved sites in an approved way."
The further we allow the Web to stray from cURL http://example.com Just Working, the worse off we all are. So to reiterate, this proposal looks insane and not at all aligned with Mozilla's mission...
Unfortunately my pay grade isn't high enough to tell people what to work on, haha. That said, I am fairly sure that whoever is working on it would also prefer `cURL http://example.com` to Just Work.
But keep in mind that not doing anything isn't going to stop the rise of CAPTCHAs. If you've got specific alternative approaches in mind, especially ones that keep in mind the trade-offs mentioned in that blog post, then I'm sure it's possible to reach out to the author.
Does Kagi use the turnstile for paid users? As a Kagi early adopter who's been a paid member from the beginning, I'm not sure I ever noticed anything Cloudflare related when using it.
Currently, it's mainly used to track the 50 searches that you can perform without signing up. But for me, that makes it hard to trust them. Fingerprinting without explicit notice and consent is not something a service that claims to support privacy should be doing. They should either go back to requiring an account, as they did before, or clearly state that they use Turnstile and ask for consent and otherwise deny the search.
I feel like I am commenting this under every post mentioning fingerprinting, but is there a technical reason access to fingerprinting information (screen resolution, battery level, etc) couldn't be made to "taint" the data/code, where the browser would then refuse to send off that data? Or anonymise it and replay the code before sending the request.
Of course, there are legitimate use-cases: downloading specific assets based on client device, etc. And that's a whole can of worms of side channels to open, but that would feel like a useful additional layer of defense, and the paranoia level could be configured. The price might be subtle bugs, and/or a permission dialog that most people will ignore.
I am asking this as, from what I've seen, most websites do not need complex interactions: the battery level will be used to render a battery indicator, etc. XHRs do not usually depend on such data.
If by "tainting" the data you mean subtly changing it in a way that preserves functionality while making it harder to use for fingerprinting, then this is what we do at Brave browser for many of our anti-fingerprinting protections: https://brave.com/glossary/fingerprinting/#how-can-i-prevent...
I think the idea is that a given JavaScript variable/context would be “tainted” the moment it accesses those APIs; taint tracking would then be used to guarantee that tainted data couldn’t be attached to any network request. The idea here is that fingerprint-capable APIs could be used but only locally.
There’s some parallels to canvas tainting: JS is blocked from reading the pixels of any canvas that has had a cross-origin image rendered to it. This is done to enforce the same-origin policy while allowing canvases to use cross-origin images like the <img> tag can.
Unfortunately, when you can run arbitrary JS, even doing strictly local computations can likely be used to leak tainted data to a cooperating untainted context. Since you’d want the JS to still be able to do something useful with the tainted data, that resulting changes could be measured to leak the data. A more draconian measure could be to just block fetch() and similar APIs entirely after you call a fingerprinting API, but that would probably break too many sites.
Indeed, this is what I have in mind: metadata attached to variables and js contexts, "contaminating" everything it interacts with.
There would indeed be many holes to plug, especially when considering side-channel attacks.
Thank you for the answer, this is interesting, and fuels my reflection. I had not considered some of the most common leak vectors. It seems that the main risk is that almost every API surface may get tainted fairly quickly.
To take an example: Changes to the DOM could taint that part of the DOM, and if these specific elements are accessed by another context, that would taint the context. But to reduce the collateral damage, one would need deep integration: only adding or removing elements should affect the length attribute, only the changed part of a str could be tainted, etc. That said, it might not be that complex to implement: assuming an attribute is computed by walking a list, the taint should be applied when crossing the modified boundary. If it's stored when the change occurs, it should be tainted directly.
I guess that only a prototype + corpus would give definitive answers.
The second idea I had in mind was more complex: when detecting that a tainted context is about to perform a network request, replay the context using non-fingerprinting data. Obviously it would have a performance cost. An alternative could be: every time a context get tainted, "fork" it and perform changes both in the real context and in a "parallel universe" with dummy data: use this dummy context when sending back data.
Anyway, they are just ideas. I am not in the browser space but if I was, I'd probably ask an agent to run some experiments with this.
Boundaries on such a model would be very hard to enforce. If any element of the page "moves around other elements", all other elements must be tainted as they'd leak information on the tainted DOM node. Presence or absence of a DOM node can leak information about a tainted context.
The second idea would be vulnerable as long as you can exfiltrate tainted data to untainted context.
As I understand it, almost all anti-fingerprinting protections are some measure of this, balanced against the level of breakage to accept. For example, Firefox is able to "letterbox" your viewport, i.e. restrict its size to one of a number of preset ones, filling up the remaining space with grey. That reduces entropy, but makes the user experience considerably worse, so it's not enabled by default in Firefox. Something like Tor Browser has a higher tolerance for breakage, so it does enable it.
It's very difficult to prevent JavaScript from using your screen size to affect which elements are displayed on the screen (which is detectable since you'll only click something that's visible) and still make websites work.
Konform Browser has implemented fix for this, fwiw. Would be nice to get it addressed upstream so we don't have to generate fake origins in order to not stick out.
One caveat I’ve experienced with Firefox branches that focus on privacy is I get “punished” with captchas from hell because I refuse to let websites siphon and prey on every last bit of private info. Hopefully this doesn’t succumb to the same issue.
I'm tired of identifying buses or stoplights or motorcycles up to five times a day just for Google searches. I'm slowly moving myself over to LLM queries instead.
I get them all the time in DDD, in fact, so much that I changed to Google, who makes me point motorcycles or bridges much less.
I think it's because DDG defaults to AI at the top for new visitors, and I always start new web searches in a private window. I think it's trying to prevent automated abuse of free tokens, something that wouldn't be needed if they defaulted to no AI in the first place.
I understand that bots would enable AI anyway, but at that point they could show the captchas to them and not to everyone.
Why do you want to use services that use such captchas? It’s like going to a club and complaining about the door policy. Don’t go if you don’t like it.
I'd like to have some of the APIs that read the data used to fingerprint browsers be behind a confirmation dialog per site similar to allowing popups or microphone/video access.
> Oh, I see that you'd like to read the canvas pixel data, let me check if that's okay with the user first.
I'm on desktop Firefox v160.0 and I've never seen a permission dialog like that and under settings I see:
Permissions
Manage what websites can access, control, or trigger.
Location
Camera
Device apps and services
Local network devices
Microphone
Speaker
Notifications
Autoplay
Virtual reality
None of those seem to be for accessing canvas data.
Not sure what my settings are but I've definitely seen the pop up at browse time "Website wants to access canvas data" or similar with a decline option. It might be under the umbrella of settings changed by setting Enhanced Tracking Protection to Strict.
Some people seem to be under the false illusion that the free and open web will continue to function without fingerprinting.
For those of us actually on the front line combatting previously unseen volumes abuse from bots, the thought of losing even more access to important signals sounds cursed.
Privacy may have to take a back seat so we can keep services online until we can figure out anonymous proof of humanity.
Unless I'm misreading the post mentions that the most recent change was added to version 145 which released last year. Personally I haven't had any issues with cloudflare as a firefox user since then with strict mode enabled.
Are you talking about a return to a web of one-to-one connections, no broadcasts?
Actually the problem isn't broadcasts but reverse broadcasts. A broadcast sends one signal to all interested listeners - the problematic mode of the web is one listener getting all interested signals, which allows spam and propaganda (which are the same thing) to flood that set. Is there a word for this reverse broadcasting idea?
Maybe you can use your second-order thinking to consider how people might react to a sentence that starts “if you are among those capable of 3rd order thinking.”
-1 it's perhaps offensive but I agree with OP: 3rd order is *very* difficult to reason about, and even really smart, really experienced people have colossal failures at that level of reasoning-depth. It's not just probabilistic (e.g. chess, go), but in addition the way a decision-tree-branch is followed often deeply affects downstream decisions...
See, this is more along what I expect from a place that titles itself "Hacker News".
The reason I mentioned 2nd order and 3rd order cognitive abstraction, is because to fix the web we need to make some tough decisions.
When technical enthusiasts such as people who call themselves "engineer" but aren't real engineers hear these things the response is "nobody is going to do $thing lol". Yet the more big brains are indeed talking about doing thing or lamenting the mal-growth we have collectively experienced, including the recognized inventor of the WWW.
The below is just off the top of my head, "in passing". Some people have done some work on parts of this picture already. Maybe I could post something more "formal" somewhere later on.
Before jumping in with "omg but then how would X/Y/Z work lol", use whatever 2nd order or 3rd order abstraction thinking you might have, and consider that those things were already considered by people working on these problems (or at least attempting to) and yes there are full answers or at least a couple of half-answers for those concerns.
Among those is content-addressing. This eliminates, by avoiding outright through design, most of the Cloudflare/Akamai, "verifying your connection", and captcha bullshit. This also means user metrics are opt-in, which maybe they could be by default unless a user turns it off, but then they would be easy to spoof (which they already are).
The major thing is no more untrusted Javascript and no more untrusted WASM unless loaded in a pop-up window as "external program". See the Free Software Foundation's stance on non-free Javascript. This stance isn't so "out there" to legitimate hackers.
Due to decisions made early on with processors and the feedback loop optimizing for certain styles of programming, our CPUs do speculative execution. Some developments have helped, but the only safe option for CPUs people actually use, which are not the second or third latest generation (often for chipset security concerns), require disabling Javascript JIT and WASM or Javascript all together.
Almost all of the widgets and doodads we need for the web have been figured out by now. We need a trusted collection of libraries for these things. This should include all of the extra fonts we want.
Any GPU/canvas stuff needs to be truly deterministic so as to be useless for fingerprinting.
No more User Agent string.
No more sending screen dimensions. Yes, how to contend with this has been thought of already.
Not every website should be "mobile friendly". Yes, you do need a fucking laptop/desktop to get by in the world. "I can do everything on my phone" is NGMI.
The whole CA thing needs a complete overhaul.
Cookies need to be handled in a way that users can hover over a browser tab and see what cookies are visible to the remote end of that browser tab, and cross-domain cookies must be explicitly allowed by a user.
There are very tough decisions and things that do require serious talent to innovate correctly in a way intuitive to users, that need to happen to eliminate
fingerprinting.
It's not those incapable of 3rd order cognitive abstraction who are going to dig us out of this mess. It's people who actually give a shit and think about these things a lot who will quietly implement the fixes and will never be renowned or heard of by the crab bucket mentality monkeys unless someone in authority tells them too.
I’ll spell it out for you: it comes across as condescending. Long-term, especially if you do this in real life too, that means people are less likely to listen to what you have to say, and makes you less effective at tasks that require other people’s cooperation.
Systemically, you might be thinking too much about rationalism, and feeling superior, and not enough about how your choices make other people feel. Feelings aren’t rational; in fact, studies of the brain show that feelings come first and the rational explanation comes later. The only way to elicit a rational response from people is to talk in a way that makes them feel interested in what you have to say, at that comes from how you say it as much as what you say.
I think it's great that Firefox is finally doing more to combat fingerprinting. For a long time, they lagged a bit behind Brave in this regard. That said, unfortunately, neither browser has been able to do anything about Cloudflare Turnstile yet. Kagi, for example, uses it to fingerprint users.
I believe the relevant work to mitigate that is https://hacks.mozilla.org/2026/06/pact-anonymous-credentials...
(I do work at Mozilla but not on any of this.)
There's a third option: allow bots and give them access as efficiently as possible.
As Reddit's API used to.
Don't want to? Tough, they'll do it the hard way and put more load on your servers and your countermeasures will drive away more humans than bots.
Of course our current bot plague doesn't understand this and seems to be optimizing for maximum server load, which is still bad.
> There's a third option: allow bots and give them access as efficiently as possible.
Why?
To make your data more accessible AND reduce server load. More and more people are using AI, so there will be more and more bots as the trend seems to be accessing data with your AI, and maybe, only sometimes, actually reviewing what it found. I'm afraid that if you don't at least start to consider how we might accommodate the bots, you'll be walling off more and more real users going forward.
what does the site get out of ai users? it doesn't seem like they have a strong incentive to let you not actually visit the site
shopping makes some sense if the bot can still buy things at least, but a lot of other ad dependent sites really have little reason
A wide portion of the Internet is not ad supported. Consider a user searching for product support: the company benefits from the user self-solving the issue without having a ticket filed.
This, may, however be to the detrimental of discussion platforms, but if that drives people to self hosted discussion platforms instead of relying on reddit, then it is a net positive.
Discourse's most recent blog delves into this and is an interesting read, I will submit that I think.
I'll look for that - I'm thinking about small forums and community sites a lot lately with ai stuff.
I'm with ya, but I'm not sure what the solution is. Just pointing out a reality the internet's going to have to cope with.
My cynical take is we'll just start putting ads into the text that targets agents.
> To make your data more accessible AND reduce server load.
Wait, how do you reduce server load by allowing traffic from bots?
> More and more people are using AI, (...)
That's specious reasoning. Sites provide data for their users to consume, and in some cases their business model relies on real people consuming their content.
If you replace "bots" with "scrapers", which is a specific kind of bot, what conclusions do you draw?
> I'm afraid that if you don't at least start to consider how we might accommodate the bots, (...)
Wait, you think this problem is new? What do you think companies do with crawlers and scrapers?
I just told you why.
> I just told you why.
No, not really. Is your opinion too hard to defend?
All repositories on git.zajc.tel can be git clone'd from their URL. The clone URL is also listed on every repository's summary page. Unlike the HTML pages, the clone endpoints are not ratelimited, have no bot check, and give you the entire repository with all history without having to crawl billions of pages.
Guess which option the bots pick.
yep, current bits are extremely stupid or intentionally malicious - never attribute to stupidity that which can be adequately explained by malice
Also never say never :>
Or just block all bots and give them a big F U :)
Why shouldn't bots (who work on behalf of users after all) not get access to information?
I just found something via LLMs and bought it from a website that I would have never found with traditional search engines (because I didn't).
this is bad faith argument. You are well aware that the majority of bots are used for negative purposes, at best, those purposes are neutral.
The situation you describe is certainly legitimate and useful, but is not the norm. Separating legitimate bots from the rest is currently not possible reliably.
Am I a bot? How do you know?
I reject your false dichotomy.
You reject the law of the excluded middle - you reject that either I am a bot or I am not a bot?
This is HK. We here are all bots at heart.
Can you please tell whoever it is at Mozilla to stop working on that.
This feedback isn't directed at any one person but that proposal impressively suffers from the simultaneous problems of Being Way Too Fucking Complicated and Proposing to Make the Web Better but Actually Making it Way Worse (for Everyone Except Entrenched Megacorps). It's the exact same problem that Google's "anonymous ad attribution" attestation swarms suffered, and luckily that never came to pass.
From looking at the pictures in that article, it seems like in order for me to be able to browse "protected" sites (aka, most of the corporate-owned web, once they are aware that this exists and turn it on because "bots bad") my browser is going to have to negotiate for some scant amount of "allowed access" tokens or other such thing, through some complicated protocol that halts any chance of us realizing a future for the web that looks any much different from "locked down approved browsers visiting approved sites in an approved way."
The further we allow the Web to stray from cURL http://example.com Just Working, the worse off we all are. So to reiterate, this proposal looks insane and not at all aligned with Mozilla's mission...
Unfortunately my pay grade isn't high enough to tell people what to work on, haha. That said, I am fairly sure that whoever is working on it would also prefer `cURL http://example.com` to Just Work.
But keep in mind that not doing anything isn't going to stop the rise of CAPTCHAs. If you've got specific alternative approaches in mind, especially ones that keep in mind the trade-offs mentioned in that blog post, then I'm sure it's possible to reach out to the author.
> The further we allow the Web to stray from cURL http://example.com Just Working, the worse off we all are.
The problem is we don't hold bad actors accountable. That's how we ended up losing open SMTP decades ago.
Does Kagi use the turnstile for paid users? As a Kagi early adopter who's been a paid member from the beginning, I'm not sure I ever noticed anything Cloudflare related when using it.
Currently, it's mainly used to track the 50 searches that you can perform without signing up. But for me, that makes it hard to trust them. Fingerprinting without explicit notice and consent is not something a service that claims to support privacy should be doing. They should either go back to requiring an account, as they did before, or clearly state that they use Turnstile and ask for consent and otherwise deny the search.
Brave has never been secure (still not today) regarding Fingerprinting.
Does Cloudflare Turnstile use WebRTC to trace IP?
I feel like I am commenting this under every post mentioning fingerprinting, but is there a technical reason access to fingerprinting information (screen resolution, battery level, etc) couldn't be made to "taint" the data/code, where the browser would then refuse to send off that data? Or anonymise it and replay the code before sending the request.
Of course, there are legitimate use-cases: downloading specific assets based on client device, etc. And that's a whole can of worms of side channels to open, but that would feel like a useful additional layer of defense, and the paranoia level could be configured. The price might be subtle bugs, and/or a permission dialog that most people will ignore.
I am asking this as, from what I've seen, most websites do not need complex interactions: the battery level will be used to render a battery indicator, etc. XHRs do not usually depend on such data.
If by "tainting" the data you mean subtly changing it in a way that preserves functionality while making it harder to use for fingerprinting, then this is what we do at Brave browser for many of our anti-fingerprinting protections: https://brave.com/glossary/fingerprinting/#how-can-i-prevent...
I think the idea is that a given JavaScript variable/context would be “tainted” the moment it accesses those APIs; taint tracking would then be used to guarantee that tainted data couldn’t be attached to any network request. The idea here is that fingerprint-capable APIs could be used but only locally.
There’s some parallels to canvas tainting: JS is blocked from reading the pixels of any canvas that has had a cross-origin image rendered to it. This is done to enforce the same-origin policy while allowing canvases to use cross-origin images like the <img> tag can.
Unfortunately, when you can run arbitrary JS, even doing strictly local computations can likely be used to leak tainted data to a cooperating untainted context. Since you’d want the JS to still be able to do something useful with the tainted data, that resulting changes could be measured to leak the data. A more draconian measure could be to just block fetch() and similar APIs entirely after you call a fingerprinting API, but that would probably break too many sites.
Indeed, this is what I have in mind: metadata attached to variables and js contexts, "contaminating" everything it interacts with.
There would indeed be many holes to plug, especially when considering side-channel attacks.
Thank you for the answer, this is interesting, and fuels my reflection. I had not considered some of the most common leak vectors. It seems that the main risk is that almost every API surface may get tainted fairly quickly.
To take an example: Changes to the DOM could taint that part of the DOM, and if these specific elements are accessed by another context, that would taint the context. But to reduce the collateral damage, one would need deep integration: only adding or removing elements should affect the length attribute, only the changed part of a str could be tainted, etc. That said, it might not be that complex to implement: assuming an attribute is computed by walking a list, the taint should be applied when crossing the modified boundary. If it's stored when the change occurs, it should be tainted directly.
I guess that only a prototype + corpus would give definitive answers.
The second idea I had in mind was more complex: when detecting that a tainted context is about to perform a network request, replay the context using non-fingerprinting data. Obviously it would have a performance cost. An alternative could be: every time a context get tainted, "fork" it and perform changes both in the real context and in a "parallel universe" with dummy data: use this dummy context when sending back data.
Anyway, they are just ideas. I am not in the browser space but if I was, I'd probably ask an agent to run some experiments with this.
Boundaries on such a model would be very hard to enforce. If any element of the page "moves around other elements", all other elements must be tainted as they'd leak information on the tainted DOM node. Presence or absence of a DOM node can leak information about a tainted context.
The second idea would be vulnerable as long as you can exfiltrate tainted data to untainted context.
As I understand it, almost all anti-fingerprinting protections are some measure of this, balanced against the level of breakage to accept. For example, Firefox is able to "letterbox" your viewport, i.e. restrict its size to one of a number of preset ones, filling up the remaining space with grey. That reduces entropy, but makes the user experience considerably worse, so it's not enabled by default in Firefox. Something like Tor Browser has a higher tolerance for breakage, so it does enable it.
It's very difficult to prevent JavaScript from using your screen size to affect which elements are displayed on the screen (which is detectable since you'll only click something that's visible) and still make websites work.
Too bad they still generate a random unique ID for each installed extension that can expose a trackable UUID...
https://bugzilla.mozilla.org/show_bug.cgi?id=1717671
Konform Browser has implemented fix for this, fwiw. Would be nice to get it addressed upstream so we don't have to generate fake origins in order to not stick out.
https://codeberg.org/konform-browser/source/src/branch/main/...
What response did you get when you submitted that patch upstream?
One caveat I’ve experienced with Firefox branches that focus on privacy is I get “punished” with captchas from hell because I refuse to let websites siphon and prey on every last bit of private info. Hopefully this doesn’t succumb to the same issue.
I'm tired of identifying buses or stoplights or motorcycles up to five times a day just for Google searches. I'm slowly moving myself over to LLM queries instead.
tbf that's on you for still using google
In my limited experience, you'll get different captchas in other search engines too.
Never saw one in duckduckgo, and I (used to) get them on G all the time.
I get them all the time in DDD, in fact, so much that I changed to Google, who makes me point motorcycles or bridges much less.
I think it's because DDG defaults to AI at the top for new visitors, and I always start new web searches in a private window. I think it's trying to prevent automated abuse of free tokens, something that wouldn't be needed if they defaulted to no AI in the first place.
I understand that bots would enable AI anyway, but at that point they could show the captchas to them and not to everyone.
Why do you want to use services that use such captchas? It’s like going to a club and complaining about the door policy. Don’t go if you don’t like it.
Thanks for reminding me that Elon Musk got rejected from Berghain.
[flagged]
No, it's in Berlin, which is the capital city of Germany.
Yes, it's in Berlin [0]
[0] https://www.dpolg.berlin/aktuelles/news/schusswaffenkriminal...
I'd like to have some of the APIs that read the data used to fingerprint browsers be behind a confirmation dialog per site similar to allowing popups or microphone/video access.
> Oh, I see that you'd like to read the canvas pixel data, let me check if that's okay with the user first.
HTML5 canvas data access has been behind such a permission dialog on Firefox (at least on desktop) for a long time now.
I'm on desktop Firefox v160.0 and I've never seen a permission dialog like that and under settings I see:
None of those seem to be for accessing canvas data.Not sure what my settings are but I've definitely seen the pop up at browse time "Website wants to access canvas data" or similar with a decline option. It might be under the umbrella of settings changed by setting Enhanced Tracking Protection to Strict.
[flagged]
Some people seem to be under the false illusion that the free and open web will continue to function without fingerprinting.
For those of us actually on the front line combatting previously unseen volumes abuse from bots, the thought of losing even more access to important signals sounds cursed.
Privacy may have to take a back seat so we can keep services online until we can figure out anonymous proof of humanity.
Unpopular opinion, I know.
[flagged]
Am I the only expecting it to completely break the sites behind cloudflare on Firefox?
Unless I'm misreading the post mentions that the most recent change was added to version 145 which released last year. Personally I haven't had any issues with cloudflare as a firefox user since then with strict mode enabled.
It links to this post when talking about it: https://blog.mozilla.org/en/firefox/fingerprinting-protectio...
Was also thinking this, would like an answer.
Your move, Apple.
[flagged]
Are you talking about a return to a web of one-to-one connections, no broadcasts?
Actually the problem isn't broadcasts but reverse broadcasts. A broadcast sends one signal to all interested listeners - the problematic mode of the web is one listener getting all interested signals, which allows spam and propaganda (which are the same thing) to flood that set. Is there a word for this reverse broadcasting idea?
Maybe you can use your second-order thinking to consider how people might react to a sentence that starts “if you are among those capable of 3rd order thinking.”
-1 it's perhaps offensive but I agree with OP: 3rd order is *very* difficult to reason about, and even really smart, really experienced people have colossal failures at that level of reasoning-depth. It's not just probabilistic (e.g. chess, go), but in addition the way a decision-tree-branch is followed often deeply affects downstream decisions...
See, this is more along what I expect from a place that titles itself "Hacker News".
The reason I mentioned 2nd order and 3rd order cognitive abstraction, is because to fix the web we need to make some tough decisions.
When technical enthusiasts such as people who call themselves "engineer" but aren't real engineers hear these things the response is "nobody is going to do $thing lol". Yet the more big brains are indeed talking about doing thing or lamenting the mal-growth we have collectively experienced, including the recognized inventor of the WWW.
The below is just off the top of my head, "in passing". Some people have done some work on parts of this picture already. Maybe I could post something more "formal" somewhere later on.
Before jumping in with "omg but then how would X/Y/Z work lol", use whatever 2nd order or 3rd order abstraction thinking you might have, and consider that those things were already considered by people working on these problems (or at least attempting to) and yes there are full answers or at least a couple of half-answers for those concerns.
Among those is content-addressing. This eliminates, by avoiding outright through design, most of the Cloudflare/Akamai, "verifying your connection", and captcha bullshit. This also means user metrics are opt-in, which maybe they could be by default unless a user turns it off, but then they would be easy to spoof (which they already are).
The major thing is no more untrusted Javascript and no more untrusted WASM unless loaded in a pop-up window as "external program". See the Free Software Foundation's stance on non-free Javascript. This stance isn't so "out there" to legitimate hackers.
Due to decisions made early on with processors and the feedback loop optimizing for certain styles of programming, our CPUs do speculative execution. Some developments have helped, but the only safe option for CPUs people actually use, which are not the second or third latest generation (often for chipset security concerns), require disabling Javascript JIT and WASM or Javascript all together.
Almost all of the widgets and doodads we need for the web have been figured out by now. We need a trusted collection of libraries for these things. This should include all of the extra fonts we want.
Any GPU/canvas stuff needs to be truly deterministic so as to be useless for fingerprinting.
No more User Agent string.
No more sending screen dimensions. Yes, how to contend with this has been thought of already.
Not every website should be "mobile friendly". Yes, you do need a fucking laptop/desktop to get by in the world. "I can do everything on my phone" is NGMI.
The whole CA thing needs a complete overhaul.
Cookies need to be handled in a way that users can hover over a browser tab and see what cookies are visible to the remote end of that browser tab, and cross-domain cookies must be explicitly allowed by a user.
There are very tough decisions and things that do require serious talent to innovate correctly in a way intuitive to users, that need to happen to eliminate fingerprinting.
It's not those incapable of 3rd order cognitive abstraction who are going to dig us out of this mess. It's people who actually give a shit and think about these things a lot who will quietly implement the fixes and will never be renowned or heard of by the crab bucket mentality monkeys unless someone in authority tells them too.
[flagged]
I’ll spell it out for you: it comes across as condescending. Long-term, especially if you do this in real life too, that means people are less likely to listen to what you have to say, and makes you less effective at tasks that require other people’s cooperation.
Systemically, you might be thinking too much about rationalism, and feeling superior, and not enough about how your choices make other people feel. Feelings aren’t rational; in fact, studies of the brain show that feelings come first and the rational explanation comes later. The only way to elicit a rational response from people is to talk in a way that makes them feel interested in what you have to say, at that comes from how you say it as much as what you say.
[flagged]
[flagged]
Your account appears to be created for the sole purpose of making spammy keyboard-mash comments. May I ask why?
[flagged]