am I crazy for thinking I could clock whether something was rendered in chromium

“I’ll never pass for a firefox render…”

@julia canvas fingerprinting tools / tracking pixels be like: “we can always tell”

@sodiboo @julia canvas fingerprinting, tracking pixels and “that one oomf”

@julia my friend has this talent only because somehow firefox rendering makes her screen tearing awful which gives her insane headaches

-carrie

@julia@eepy.moe A/B/X double blind test ​​

@pancakes not even just that, font rendering is sufficiently different that I think I could spot the difference

@sodiboo canvas fingerprinting tools don't distinguish between browsers though. they just create opaque hashes
@julia

@thermia @sodiboo @julia tip: use uBo (duh), NoScript and alternate frontends

@a_blahaj @julia @sodiboo @thermia for reference, if fingerprinting is the concern, Firefox in the Strict tracking protection mode subtly randomizes canvas readouts without any extensions

there is also resistFingerprinting and addons like CanvasBlocker

@risc @julia @sodiboo @thermia oh, right
do not forget to set privacy.resistFingerprinting in about:config !

@a_blahaj recommending RFP is a brave endeavour
RFP changes/breaks roughly everything in the browser lol

it's also not strictly necessary. RFP is part of Tor Uplift, and was intended for Tor Browser. it's most likely excessive for normal usage
@julia @sodiboo @thermia

@risc @julia @sodiboo @thermia Wdym “it breaks roughly everything”? I’ve been keeping it on for forever and it works perfectly fine.

@a_blahaj forced light theme, canvas readout fuckery

"roughly everything" was an overexaggeration yeah
@julia @sodiboo @thermia

@risc @julia @sodiboo @thermia the light theme, i can deal with dark reader
the canvas redout fuckery, i don’t care. get fucked, you’re a useless piece of “necessary” bloatware.

@a_blahaj canvas being "useless" is certainly a take 🥴

@julia @sodiboo @thermia

@a_blahaj @sodiboo @thermia @risc me when I can’t do anything that manipulates images off screen because it’s “bloat”

@julia omw to use Skia in WebAssembly instead /j
@a_blahaj

@risc @sodiboo @thermia @a_blahaj average NoScript user take

@risc @julia @sodiboo @thermia even though it might be useful, it’s used for more evil things than good

@a_blahaj @julia @thermia @risc isn’t dark reader like way more fingerprintable than a dark theme preference? it injects stylesheets into the page that can be very unique based on your settings. versus like, a standardized media query that like half the world is already using.

resist fingerprinting forcing a light theme is stupid though. I’d rather just give them the bit of entropy than fuck up my browsing experience.

@a_blahaj there are working ways to mitigate the risks without lobotomizing the API lol. which, again, FF does by default already, and Chromium has in the works afaik

RFP is fine, and like, anyone can use whatever they want. but this one doesn't particularly like recommendations of overkill (or even excessive) privacy/security solutions that don't consider the full spectrum of what the solution does, what its side-effects are, how and when it's actually useful, etc

@julia @sodiboo @thermia

@risc @julia @a_blahaj average flutter webbapp be like

@sodiboo @julia @thermia @risc it’s the closest i can get to having dark theme and RFP. might as well look at the alternatives

@sodiboo dark reader is extremely fingerprintable, if someone actually cares to fingerprint it to begin with. individual settings, differences in behavior between extension versions, etc

nobody seriously fingerprints the light/dark theme. the setting is very much mutable for normal users. RFP was made for a single specific purpose: separating Tor Browser users into as few buckets as possible.

@julia @thermia @a_blahaj

@risc @julia @thermia @a_blahaj I don’t get why it must be implemented by forcing a light theme though.

as far as I understand, JavaScript can’t even access the color scheme? CSS is allowed to have different styles based on your browsing history (link visited color). I thought color scheme was treated similarly? only CSS is allowed to read that property?

I know this can still be “read” by say, using a different background image URL per color scheme. you can then detect the color scheme based on which image was downloaded. but surely this applies to browsing history too? can’t it be solved in the same way? I don’t know how it’s solved for that case, but I can imagine another possibility is to just make sure that whenever a media query has a network side effect, you evaluate both branches and make both requests.

why did it have to be implemented through enforcing a light color scheme? that makes no sense to me

@risc @sodiboo @julia @thermia fine. what do i use instead then?

@a_blahaj this one's solution was to not use RFP. it used to use CanvasBlocker, but stopped doing even that once fingerprintingProtection became default

currently it uses Helium (Chromium->ungoogled-chromium->Helium). here it just uses the built-in fingerprint poisoning functionality and disables JS by default (which, however, is unrelated to fingerprinting - it just got too annoyed).

@sodiboo

@sodiboo @julia @thermia @risc @a_blahaj it could implement it by setting a dark theme which is harder-impossible to read for some users

@sodiboo matchMedia("(prefers-color-scheme: dark)").matches

JS can access the color-scheme.

@sodiboo @a_blahaj @julia @risc @thermia like it’s not a general purpose option, it’s for tor where the failure of getting the user deanonymized could get them arrested or worse

@risc oh . interesting. I did not know that JavaScript could perform media queries.

still. this is an esoteric ass feature for 99% of websites. it would make way more sense in my opinion for JavaScript media queries to always return light mode, and for CSS media queries to be truthful. why not do it that way?

because again, (I guess specifically media queries are an exception), in general, JavaScript is not allowed to read the result of CSS, because it would in particular be catastrophic if JavaScript could read the colors of links. actually I believe this is wrong. apparently link visited is the exception, not the rule as I had assumed.

@sodiboo @julia @thermia @risc @a_blahaj conceptually, javascript can always* access any information exposed to CSS. even if there's no analogous API to read media query states in a single line, JS is able to manipulate and examine the DOM. Inject some CSS that changes the style of some element based on a media query and then check what it looks like with getComputedStyle

* the exception is link :visited state, which has specific carve-outs in this function where browsers will intentionally return false information. doing the same for arbitrary media queries seems kind of intractable though, and regardless there are certainly legitimate use cases for scripts to know the user's color scheme so this will almost certainly never be changed except in the "user is not allowed to use dark mode" way that you observe

@sodiboo as said by erin, :visited is treated specially
and again, RFP was made for Tor Browser. the fact that it's used by anyone else was never intended

@erin @julia @thermia @risc @a_blahaj hm. but why couldn’t color scheme be treated similarly to visited then? compute styles for light mode always, and JavaScript always observes those, even if that’s not what the page actually looks like. just how visited state also returns lies.

@risc @sodiboo then why is that config option merged from the tor browser to firefox main?

@sodiboo because it isn't as critical as :visited, is used for legitimate stuff (for example: how would you theme a WebGL/WebGPU-based game's interface with CSS?), and is generally benign from a privacy standpoint (again, it's a single bit of very mutable info, and thus has almost zero value).

@risc sure but if this is the argument then it should just. Be Exposed.

you can’t simultaneously hold “the color scheme is problematic so it must be locked to light theme” and “color scheme is insignificant so there’s no point trying to make it non-fingerprintable”. I’m suggesting ways to mitigate the downside of the former and your counterargument is to embrace the latter?

to be clear, I’m suggesting that specifically Tor (or RFP at large) treat color scheme this way, not that it should be the default for web as a whole. I know color scheme is useful for WebGPU games, but like, who the hell is using Tor to play browser games?? JavaScript is disabled by default anyways. these games already don’t work without disabling protections; so what if there’s also a protection that makes them look wrong (as opposed to a stricter protection that makes everything look wrong, even when it doesn’t pass through JS??)

@sodiboo this one thinks that Tor just does not care enough. forcing it is easier and probably doesn't matter for the kind of users they are targeting

@risc

also JS isn’t off by default FYI

wait what?? why not lmao

@sodiboo TB has three security levels. "standard" (literally almost every browser feature on), "safer" (webgl is click-to-play, wasm is off), "safest" (js is off)

the default is "standard". do not ask about the logic lmfao. TB has some questionable (from its POV) decisions