I thought none of them were good for privacy because you're deviating from the default page render. But I would like to learn more about it.
this post was submitted on 15 Apr 2025
19 points (100.0% liked)
Privacy
1986 readers
446 users here now
Welcome! This is a community for all those who are interested in protecting their privacy.
Rules
PS: Don't be a smartass and try to game the system, we'll know if you're breaking the rules when we see it!
- Be civil and no prejudice
- Don't promote big-tech software
- No reposting of news that was already posted
- No crypto, blockchain, NFTs
- No Xitter links (if absolutely necessary, use xcancel)
Related communities:
Some of these are only vaguely related, but great communities.
founded 5 months ago
MODERATORS
Dark reader is only an issue for privacy as it injects CSS into the Dom (like all other extension need to do) and this injected CSS is used for fingerprinting.
and this injected CSS is used for fingerprinting.
Which, if I'm understanding correctly, would be exactly the same as if the viewer had set their browser theme to dark, so it's not like the extension is more a loss of privacy than enabling the setting in the browser?
In the end, what we really need is a browsing mode that allows(maybe?) javascript, but doesn't allow it to read properties of the renderer (viewport size, resolution, colors, fonts, etc). Since having that info stopped being necessary for customizing pages back in, like, CSS 2.1.
Yes.
Yeah, we essentially need to split the renderer from the rest of the browser in a significant manner. But HTML, css, js is a fucking mess so its pretty unreasonable to restrict it much further u can't restrict viewport sizing or resolution cos that will fundamentally break almost every framework. Also I'm sure their would be like 1000 exploits to get that data indirectly by comparing the sizes of CSS relative and absolute components.
Swapping out colours/fonts at the rendering layer is essentially what I was thinking but I go a step further by completely separating the rendering/interaction from the actual web sandbox running any code. U could even do something where u only input keyboard/mouse data to the proxy in a way that obfuscates behavioural analysis. If u also do a vm u can introduce noise into webgl making canvas fingerprinting impossible.
Swapping out colours/fonts at the rendering layer is essentially what I was thinking but I go a step further by completely separating the rendering/interaction from the actual web sandbox running any code.
Do you have a proof-of-concept? What does this run on?
I haven't written any code yet. Just a concept I was playing with. I mean if u wanted a proof of concept then u could probably do it in js with a browser extension and some python code in a docker image.
U use playwrite to send the Dom over a web socket (keeping the content in sync with decent performance might not be the easiest task) and the extension just passes keyboard and mouse back. Then u just put the virtual browser in docker container.
I wrote and run the bot for [email protected] and if u go have a look at its source u can see that its pretty easy to have a virtual browser controlled with playwrite.
This would be quite a bit of a shit experience and would probably break extension like ublock that rely on filtering what pages u can access but it would work as a proof of concept.
only an issue for privacy
So it is an issue for privacy? What's "only" about it?
Well its only an issue for that one specific attack vector.
And in its not unique to dark reader its the same for almost every single browser plugin.
Their is a theoretical solution although I haven't seen much discussion on it. It would be to have a browser that runs 2 instances 1 is a sandbox that is identical across all devices and hardware which runs in the background with all the website code (I'll call it proxy). And one instance that just renders the content of the proxy and passes back clicks and keyboard events (let's call this instance interface). You can then make any modifications to interface that u want without any fear of having it be fingerprintable as all it does is render the Dom of proxy.
Theoretically u could even run proxy on a separate VM or even another computer.
Interesting solution. Although it is hard to know if what you're clicking on the end client is the same thing as on the proxy, because some extensions alter the appearance and positions of elements on the page.
Otherwise it's a very interesting take. 👍
If u where gonna do I u would modify the proxy browser and just pass the click directly to the element itself
I don't understand this.
I imagine that won't feel great on load times compared to my system now though?
Theoretically it should be practically nothing if ur running the VM locally. The ram impact would be a far bigger concern imo.
Ah that makes sense! Ty for insight.
FWIW, you might also consider Firefox's built-in reader view, which can be configured to use a dark theme.
I use the userchrome css file to change background colors of sites i use all the time. Its a much better idea than darkreader but im pretty sure it can be used to fingerprinting data point.
Invert your screen colors. In kde you can invert the colors of a window with a keybind, I use that to get light mode on dark mode only websites
midnight lizard worked great last time I checked it