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.
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.
(I do work at Mozilla but not on any of this.)
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.
Why?
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
Guess which option the bots pick.
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).
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.
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...
The problem is we don't hold bad actors accountable. That's how we ended up losing open SMTP decades ago.
[0] https://www.dpolg.berlin/aktuelles/news/schusswaffenkriminal...
> Oh, I see that you'd like to read the canvas pixel data, let me check if that's okay with the user first.
Permissions
Manage what websites can access, control, or trigger.
Location
Camera
Device apps and services
Local network devices
Microphone
Speaker
Notifications
Autoplay
Virtual reality
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.
It links to this post when talking about it: https://blog.mozilla.org/en/firefox/fingerprinting-protectio...
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?
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.
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.