Open research, stronger privacy: Making Firefox users harder to fingerprint
blog.mozilla.org
blog.mozilla.org
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.
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.
(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.
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.
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
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.
Guess which option the bots pick.
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...