Dark mode in Tor Browser

changed the description

Tor Project doesn't dabble in that. Search for help for Firefox on which Tor Browser is based. For example: https://support.mozilla.org/en-US/kb/change-fonts-and-colors-websites-use

I don't know if setting overrides to colors may give you a unique fingerprint. Crazy things have been done with tracking in CSS in the past. Someone else can answer that.

I know changing font style can make me unique, but I think there are already a lot of other things such as canvas and WebGL fingerprints that should be matched together to identify any individual (based on my data on "cover your tracks"). Although I'm still losing around 2 to 3 percent of my privacy, I don't have any other option. So, I'm going to focus on sharing this font style with others so that more and more people can join me, and which will result in less uniqueness.

Although I'm still losing around 2 to 3 percent of my privacy, I don't have any other option. So, I'm going to focus on sharing this font style with others so that more and more people can join me, and which will result in less uniqueness.

It's a little more complicated than that; see what Pants said in this arkenfox issue. It's a bit long, but worth a read. Even using the prefers-color-scheme media query would heavily nerf RFP.

Fingerprinting resistance on the Web depends on very large numbers of adopters, and on grouping many settings together.

OP

RFP enforces all users return prefers light
sites like cover your tracks, amiunique etc are not real world. They're great for getting individual results, but collectively the data sets are small, tainted by those who visit (people tweaking their setups), by repeat visits from said visitors, and by limited tests
the only way to look at it, is by evaluating a known set (such as all TB users) in two ways
- a) how many different results there are per-metric/overall
- b) controlled: one test per profile: to determine the spread of those metrics/overall: e.g. it may be very top heavy with a long tail

@gk I thought there was a ticket for this already, but I couldn't find it. About adding a built-in controlled dark-reader/mode that would alter all/most pages for migraines/light-sensitive

I know those sites are not perfect, but they can at least give you an idea of what can be done with your fingerprint. And they've also said that this data is based on a test taken by people/returner. I've consulted about this issue (having dark mode in Tor) in #tor (IRC) and there were many people who were interested in having a dark mode officially supported by tor browser or maybe Firefox. For instance, I've developed an extension with two supported versions, one dark version and other lighter respectively. And, can you imagine that around double the number of people choose a dark version of it. So having a dark mode officially supported by tor or at least by Firefox is not a bad idea.

Edit: what is RFP?

RFP = privacy.resistfingerprinting pref

Edit: a built-in controlled dark-mode is the answer: extensions like Dark Reader have customizable settings and way too many variables. If it could be done to only reveal a binary result, then that is no worse than allowing prefers dark but would in fact arguably produce better results (all/most pages vs only those that respect prefers-dark)

I know I have an option to use Dark reader and according to their policy, they do not sell our data, but I can't trust anyone's promise as "promises and pie-crust are made to be broken".

Edit: Sorry! I didn't understand your "Edit" as I'm not a native English speaker. Can you please explain that?

by controlled I mean that the user cannot change any settings to make themselves different to the others using it. For example Dark Reader has options to change brightness, contrast, sepia etc. That creates entropy. A controlled built-in one for Tor Browser would make the settings the same for everyone to produce a binary result: either the user is using it or they are not = binary

1591679: Emilio said

So this is about auto-darkening web content, by filtering colors and inverting presumably? ? ... that'll most likely need layout engine support (https://drafts.csswg.org/css-color-adjust/ is where some of these proposals are).

If this were done, then finding a way not to leak its state to the web, or to spoof its state as the default one, would be ideal so as to not increase entropy from the security levels. I wonder if that is implied by Emilio's comment about harnessing the layout engine.

These dark and light color schemes could be adjusted to comply to WCAG (accessibility) guidelines which would be even better. As a starting point, read about all the work that went into tweaking Solarized.

@acat can we add a fingerprinting label please, TIA

I added the fingerprinting label.

added Fingerprinting label

mentioned in issue #41026

added Accessibility label

added Icebox UX labels

added Feature label

added Desktop label

Having to stare at a flashbang every time one visits a website is not just unpleasant — it's an accessibility issue.

Firefox has a setting for this (layout.css.prefers-color-scheme.content-override via about:config), but it does nothing because of RFP. If the dark mode and RFP remain mutually exclusive, then, please, provide a working option/override for users with less extreme threat models.

open a new issue and please provide

your OS + OS theme (e.g. my win11 is dark)
your FF theme: is it system, dark, light (my win11 I use system)
are you using ui.systemUsesDarkTheme (I used this on win7)
any other about:config / theme changes like browser.display.background_color etc
a website example of a flashbang - even better a video
note: if letterboxing matte shows it should match your theme

I have not experienced flashes since back in the FF70's: prefers color was introduced in FF67

I'm talking about Tor Browser's inability to pass the dark-theme preference to websites when privacy.resistFingerprinting is enabled (the browser itself can use dark themes properly). And by "flashbang" I mean pretty much any website that insists on using a light theme by default.

In other words, I'm basically bumping this (seemingly stale) issue. Incidentally, I tried setting ui.systemUsesDarkTheme, and it appears to affect the browser chrome only.

This is by design. What I am saying is that if you have an issue with "FLASHBANGS" then open a new issue instead of repeating everything. I mentioned systemUsesDarkTheme because it is these settings that can affect the background color of a tab/page before the content arrives - thus causing a change from dark-light or light-dark.

If all you want to do is advocate RFP not control this setting, then you are adding nothing new, and hiding behind "accessibility" for a perceived preference/eyesore (not to belittle those who genuinely get affected by light/migraines - IANAE - but this strobing/flash is not the issue HERE). And not to belittle the annoyance of flashing between light-dark - AGAIN, the default color can be controlled. You shouldn't be getting any flashbangs. Are you using a dark reader or some extension? OPEN A NEW ISSUE, thanks

With all due respect (I appreciate your hard work on arkenfox/user.js), you seem to be responding to my comments without actually reading them. Either that, or I'm failing to convey what I mean; I'll try to be more concise this time.

If all you want to do is advocate RFP not control this setting, then you are adding nothing new

I'm asking for an override to prevent RFP from hiding the actual theme preference (light/dark) from websites, assuming that there's no other way to work around this. At the end of the day, not everyone has an extreme threat model requiring full-blown RFP.

and hiding behind "accessibility" for a perceived preference/eyesore

not to belittle those who genuinely get affected by light/migraines

I am one of them.

Are you using a dark reader or some extension?

No, as I would rather use a built-in option than resort to installing additional extensions (which, as you know, is frowned upon).

OPEN A NEW ISSUE, thanks

Was about to, but came across #41895 (closed). For now, adding a thumbs-up to that one instead.

totally read and understood it

You may have been asking for a way to exempt RFP from prefers-color-scheme (not going to happen in TOr Browser), but your logic for it was because flashbangs (light->dark / dark_light on loading websites) ... which is a different issue (and is clearly fixable without turning off RFP, e.g I do not have this problem but I know what you mean because I have seen it years ago) - you shouldn't be getting them (not saying you aren't). If you have an issue with flashbangs then open a new issue with relevant info/STR.

I recall the (extremely annoying) issue you're talking about, but, fortunately, it's not a thing anymore.

And by "flashbang" I mean pretty much any website that insists on using a light theme by default.

So, yeah, it's about a way to exempt RFP from prefers-color-scheme, but because I'd like websites to present the dark theme right away (assuming they support it). #41895 (closed) offers a good solution, so I'm going to follow it from now on, maybe using Dark Reader in the interim.

Thanks!

mentioned in issue #41895 (closed)

So there is obviously a tension here between accessibility and fingerprinting resistance.

@Allium so the difficulty here is that not all fingerprinting vectors have the same entropy associated with them. The best case scenario is that if we allow forcing dark vs light mode in content through the usual channels we split our users in half: one in dark-mode one in light-mode. More realistically the small portion of users with accessibility needs plus the opinionated users will switch to dark-mode while everyone else who doesn't care will stay default. Depending on how much skew away from a 50:50 spit there is this vector in combination with the rest may make you very uniquely identifiable relative to your light-mode bretheren, potentially neutering he point of using Tor Browser to begin with. In the short-term, if the privacy benefits don't matter as much to you because you only care about onion services or censorship-circumvention then you can always go off into undefined-behaviour land and disable RFP so dark-mode works for you.

Now, theoretically there are things that could be done for those with accessibility needs that don't snitch to websites. (@ma1 call me out here if I'm just completely wrong here) What if we modified the root browser element itself using say a css filter? Can website content detect css 'out there'?

IE:

browser {
  filter: invert(100%)
}

The immediate thing that come to mind is that there are almost certainly performance implications of applying a filter to the entire browser element that would be detectable unless we were smart and applied a computationally equivalent but visually no-op set of filters for default users.

A naive 'invert' is also most likely not what we would want to do in this case but one could imagine various colour-space transformations that may make people like @Allium's browsing experience better without sacrificing privacy.

See https://developer.mozilla.org/en-US/docs/Web/CSS/filter for the various filer options available to us.

In the short-term, if the privacy benefits don't matter as much to you because you only care about onion services or censorship-circumvention then you can always go off into undefined-behaviour land and disable RFP so dark-mode works for you.

Wouldn't, say, installing the Dark Reader extension have much less of a privacy impact than disabling RFP altogether?

@Allium difficult to tell precisely without a lot of analysis, but if Dark Reader is modifying the DOM (which presumably it is just glancing at the required permissions) then its usage would be detectable by any adversary that cares to check. Your usage of this extension (even with RFP enabled) would almost certainly make you pretty close to uniquely identifiable if coupled with Tor Browser and a handful of other fingerprinting vectors (since nobody/very few people also have this precise configuration). At which point using RFP would mostly just be making you feel good rather than providing any actual protection.

This sort of thing is why we discourage users from using add-ons and other customisations, since their usage (or combination with other add-ons) can negate the point of RFP entirely unless everyone is also using the add-ons with the same exact same configuration.

These addons work by injecting or altering stylesheets in the page, and are trivially detectable. A good rule of thumb is that if it can trigger a CSP violation in the developer console, it is trivial to detect with JavaScript.

(FWIW: I believe the Tor Browser does disable the Reporting API, so I think some JavaScript will be necessary).

On "safest" mode with remote JavaScript disabled, certain "dark mode" addons might be safe. I think a better long-term solution would be the ability to "freeze" a page: a button or something to prevent the current page from initiating further requests (it's already loaded), running scripts, accessing storage, etc. In this state, a user could use any addons or fingerprinting-compromising settings without risk.

A good point of comparison is Reader Mode: a user's preferred Reader Mode fonts, line-width, color scheme, etc. aren't fingerprinting vectors. It should be able to stop a site from phoning home or writing to client-side storage to allow for similar levels of customization outside Reader Mode.

Other sources of inspiration could be the expected behavior for the scripting: initial-only media query, and Firefox's built-in "Work Offline" setting.

Originally posted on https://seirdy.one/notes/2023/08/28/fingerprinting-and-customization/ (POSSE)

A good rule of thumb is that if it can trigger a CSP violation in the developer console, it is trivial to detect with JavaScript.

Yeah, it operates similarly to XSS, which is also why it causes shadow-bans from Akamai. This confirms that for anyone looking hard enough it is trivial to detect the extension, so yeah be careful when manipulating the DOM.

removed Feature label

added Meta label

marked this issue as related to #22409

So... #41895 (closed) is WONTFIX, Dark Reader is bad, and !754 (merged) has been merged. Now what?

@Allium I'm hoping that we can improve this general problem with a discussion in #42183. Unfortunately, the history of resist fingerprinting has been implemented with ableist effect. I'm sorry about your above experience, and I wish I was looped in earlier. Your above points are valid.

In terms of addressing this specifically, I'm not sure there will be anything in the short term. Resist fingerprinting has not been implemented in a very flexible way in the past, so it would take some work to make exceptions within it.

An extension like DarkReader would give the effect, but as mentioned above it would make you look unique if you are concerned about tracking. Plus, you would need to be responsible for managing the extension yourself and removing it once we have something better in the future.

Otherwise, you may be able to do some color-invesion at the desktop level. I'm not sure what desktop you are using, but there is normally an option to invert the entire screen, and you can sometimes install specific desktop extensions or application that allow you to invert only specific application windows. Its not ideal since it would involve some manual work, and dark images would become light, but perhaps it can be "good enough" for the time being.

+1 to everything @henry has said here particularly to our ableist historical legacy. This is something we want to improve in conjunction with improved privacy and security features.

We're also tracking potential changes to UX customization a fingerprinting-resistant friendly way in #42226

mentioned in issue #42226

marked this issue as related to #42183

can we have something like a "double framebuffer"?

the original page would be rendered to a "public" framebuffer, which is visible to scripts and styles, which produce the public fingerprint

the darkreader-modified page would be rendered to a "private" framebuffer, which is visible only to the user, and which is completely passive, so there is no feedback-channel to the webserver

the private framebuffer would have its own styles, based on the original styles, modified by darkreader

probably a native implementation would make this double-work more efficient

added Apps::Impact::High label

Dark mode in Tor Browser

Designs

Child items ...

Activity