6 ms·

I tried enabling this recently and I immediately noticed that websites started appearing in light mode instead of copying my system settings and displaying in d

I tried enabling this recently and I immediately noticed that websites started appearing in light mode instead of copying my system settings and displaying in dark mode. It seems like in it's efforts to make my fingerprint the same as everyone else's Firefox stops telling websites about my display settings. The issue immediately went away when I changed the setting back to privacy.resistFingerprinting = false.

LikesPwsh 3y ago
That's intentional. Uncommon settings being exposed to websites makes fingerprinting much more reliable.
renewiltord 3y ago
That's how it works. The most common fingerprinting techniques use display settings, e.g. viewport size and this dark mode stuff
pdonis 3y ago
Why does the browser need to tell the website about local display settings? In my case, with privacy.resistFingerprinting = true, the Zoom level resets to 100% every time I navigate to another page on a site. Why can't the browser just remember my zoom level locally and re-apply it? Why does it have to tell the website?
- Spivak 3y ago
  It doesn't have to but if you want websites to follow your system settings for light/dark mode then the browser has to tell the website which one you want at this moment.
  - pdonis 3y ago
    > if you want websites to follow your system settings I don't want websites to follow my settings; I want my browser to follow my settings, overriding or ignoring what the website says if necessary. I don't see why the browser has to tell the website what it's overriding or ignoring.
    - MrJohz 3y ago
      The browser does follow your settings, and it doesn't necessarily directly tell the website what's going on. The problem is that the website can observe a lot of things indirectly. For example, with the dark mode/light mode "attack", the browser will download the necessary HTML and CSS in as unidentifiable a way as possible, but then it needs to render that for your machine. But the CSS file might contain a media query line that says something like "if the user wants dark mode, load this dark image as a background for this element". And to correctly respond to the query, the browser then needs to send another request to the server to download that image, that effectively indicates whether the user is using dark mode or not. This principle can be used to detect a lot of your user settings. For example, your zoom level will effectively change how wide the browser window appears to be from the perspective of a CSS file*, which means that it's possible to use more media queries to detect that. Likewise a lot of accessibility queries like prefers-reduced-motion, while really useful for many people, can be used alongside other information to create your unique browser fingerprint. This is just with HTML and CSS. If you add Javascript to the mix, it's even easier to fingerprint you based on various settings. * there are technically other ways of performing zooming that wouldn't necessarily be visible, but they have poor usability. For example, you could have the classic PDF-style zoom where the PDF is rendered in a fixed size, and the user simply views a small, viewport-sized portion of the file. But this is a pain if you want to read text that's wider than your screen, because now you need to scroll back and forth. The browser approach allows text to be reflowed to match the viewport width, but this reflow will always be observable, and therefore can always contribute to a fingerprint.
      - pdonis 3y ago
        > The problem is that the website can observe a lot of things indirectly. If the browser insists on doing those things, yes. But why does the browser have to do that? For example, if I set privacy.resistFingerprinting = true, why can't the browser just locally have a "light mode" and a "dark mode" that does the best it can to render the site locally in those modes without making any additional requests that it didn't already make for the default version of the page? Yes, I'm sure the website designer has lots of wonderful stuff to customize the look and feel in those modes--and I might like that if I could be sure that the website wasn't also using that stuff to fingerprint me. But if I'm telling my browser to resist fingerprinting, clearly I don't trust that website, so why would I want all of its customizations for light mode/dark mode?
  - bluGill 3y ago
    It shouldn't, CSS should contain both modes. You need some checks to ensure JavaScript doesn't leak, but you can place limits on how much you check and avoid having to solve the halting problem.
    - MrJohz 3y ago
      It does contain both modes. But only one of those declarations will be used, and that declaration can do things like background images, which is behaviour the server can observe. You could potentially try and "execute" all possible declarations at the same time, in effect just loading every URL or image declared in the CSS file at once, so the server can't tell which path was actually used. But (a) this would itself be identifiable as an anti-tracking measure (which can contribute to a fingerprint), and (b) this loads a lot more data in the general case, which is exactly what browsers want to avoid.
      - bluGill 3y ago
        You can verify that in either path the same images are loaded, without loading them. (this is what I was getting at by invoking the halting problem - if you cannot determine easily that it is loaded in both paths they are trying to fool your anit-traking and so you default to assuming it is tracking) The more people identified as having anti tracking on, which should be the default, the less useful that bit of tracking is.
        MrJohz 3y ago
        I don't entirely understand your point, I'm sorry. Could you explain it again? One would generally expect that both paths produce different outcomes, because this is the purpose of media queries, to produce different appearances for different screens. In the example about light mode vs dark mode, a well-designed, non-fingerprinting CSS file might well load different background images for an element to match the user's theme - a dark-background image for dark mode, and a light-background image for light mode. This is the sort of behaviour we are aiming for with this feature. The problem is that this good behaviour is indistinguishable from more malicious behaviour where the images are only used to do fingerprinting. And FWIW, this is the simplest way of doing fingerprinting that I could think of. In the general case, it is not possible to detect whether a given media query would be fingerprintable by a server. For example, a given media query might increase the height of a particular element, pushing a lazy loaded image below the fold and causing it to not be requested immediately, but only after a few seconds when the user scrolls down to it. Or instead of having one "homepage" link on the page, you have multiple, but you only show one depending on which media query fits best. Then, as soon as the user clicks the "homepage" link, you know which link was visible to them and can fingerprint them accordingly. Which is why the nuclear option here is just turning off all possibilities for existing a user's unique preferences, because it's the preferences themselves that are being used to fingerprint the user.
- imran-iq 3y ago
  To add on to this, why can't the browser just lie to the website but retain my local settings as is
- deleted 3y ago
  [deleted]
- hombre_fatal 3y ago
  Zooming basically changes the dimensions of the viewport as JS/CSS see it. Reapplying the zoom level would involve running the same CSS media queries and/or JS so that the website looks good at those dimensions. It's not just an "optical" zoom. But more directly, zooming can put you in very nonstandard width x height dimensions. Carrying those dims across different pages makes for an easy fingerprint which is probably why it's reset.
  - pdonis 3y ago
    > Zooming basically changes the dimensions of the viewport as JS/CSS see it. I don't care what the website's JS/CSS says. At the end of the day the browser has a rendered canvas; I just want to zoom the canvas (and clip it at the window dimensions, providing scrollbars if necessary, if zooming makes it larger than the window dimensions). The browser shouldn't have to re-run anything to do that; zooming and clipping a canvas are graphics operations that have existed in computers for as long as there have been computers with graphics at all.
    - olliej 3y ago
      When people increase their font size/zoom they generally don't want that - what you're describing is the default zoom on phones, etc which is different from increasing the page text size, and you'll note is typically about increasing undersized ui components rather than simply reading text. When people are in a browser and expanding the content they want the content reflowed - having to scroll to read the width of a line is super obnoxious, and makes reading text much harder. This is made even more frustrating when you recall that a lot of time the reason for zooming is to make things easier to read. There are very few times where the correct response to "increase the zoom" is simply an affine transform of the rendered content, from both a usability standpoint or from user intent.
      - pdonis 3y ago
        > When people are in a browser and expanding the content they want the content reflowed Even if this is the case, I don't see why the browser has to re-run anything from the website or tell the website anything. It can just do the reflow operation locally. Yes, the central data structure then is the DOM rather than a rendered canvas, but the DOM is still held locally.
mixmastamyk 3y ago
Dark mode is generally decided at the client via choosing which block of css to use. Are these sites sending different css instead?
seanw444 3y ago
My primary issue is that it limits the refresh rate. It immediately gets choppier when scrolling, which is suuuuper annoying.

LikesPwsh 3y ago

That's intentional. Uncommon settings being exposed to websites makes fingerprinting much more reliable.

renewiltord 3y ago

That's how it works. The most common fingerprinting techniques use display settings, e.g. viewport size and this dark mode stuff

pdonis 3y ago

Why does the browser need to tell the website about local display settings? In my case, with privacy.resistFingerprinting = true, the Zoom level resets to 100% every time I navigate to another page on a site. Why can't the browser just remember my zoom level locally and re-apply it? Why does it have to tell the website?

Spivak 3y ago
It doesn't have to but if you want websites to follow your system settings for light/dark mode then the browser has to tell the website which one you want at this moment.
- pdonis 3y ago
  > if you want websites to follow your system settings I don't want websites to follow my settings; I want my browser to follow my settings, overriding or ignoring what the website says if necessary. I don't see why the browser has to tell the website what it's overriding or ignoring.
  - MrJohz 3y ago
    The browser does follow your settings, and it doesn't necessarily directly tell the website what's going on. The problem is that the website can observe a lot of things indirectly. For example, with the dark mode/light mode "attack", the browser will download the necessary HTML and CSS in as unidentifiable a way as possible, but then it needs to render that for your machine. But the CSS file might contain a media query line that says something like "if the user wants dark mode, load this dark image as a background for this element". And to correctly respond to the query, the browser then needs to send another request to the server to download that image, that effectively indicates whether the user is using dark mode or not. This principle can be used to detect a lot of your user settings. For example, your zoom level will effectively change how wide the browser window appears to be from the perspective of a CSS file*, which means that it's possible to use more media queries to detect that. Likewise a lot of accessibility queries like prefers-reduced-motion, while really useful for many people, can be used alongside other information to create your unique browser fingerprint. This is just with HTML and CSS. If you add Javascript to the mix, it's even easier to fingerprint you based on various settings. * there are technically other ways of performing zooming that wouldn't necessarily be visible, but they have poor usability. For example, you could have the classic PDF-style zoom where the PDF is rendered in a fixed size, and the user simply views a small, viewport-sized portion of the file. But this is a pain if you want to read text that's wider than your screen, because now you need to scroll back and forth. The browser approach allows text to be reflowed to match the viewport width, but this reflow will always be observable, and therefore can always contribute to a fingerprint.
    - pdonis 3y ago
      > The problem is that the website can observe a lot of things indirectly. If the browser insists on doing those things, yes. But why does the browser have to do that? For example, if I set privacy.resistFingerprinting = true, why can't the browser just locally have a "light mode" and a "dark mode" that does the best it can to render the site locally in those modes without making any additional requests that it didn't already make for the default version of the page? Yes, I'm sure the website designer has lots of wonderful stuff to customize the look and feel in those modes--and I might like that if I could be sure that the website wasn't also using that stuff to fingerprint me. But if I'm telling my browser to resist fingerprinting, clearly I don't trust that website, so why would I want all of its customizations for light mode/dark mode?
- bluGill 3y ago
  It shouldn't, CSS should contain both modes. You need some checks to ensure JavaScript doesn't leak, but you can place limits on how much you check and avoid having to solve the halting problem.
  - MrJohz 3y ago
    It does contain both modes. But only one of those declarations will be used, and that declaration can do things like background images, which is behaviour the server can observe. You could potentially try and "execute" all possible declarations at the same time, in effect just loading every URL or image declared in the CSS file at once, so the server can't tell which path was actually used. But (a) this would itself be identifiable as an anti-tracking measure (which can contribute to a fingerprint), and (b) this loads a lot more data in the general case, which is exactly what browsers want to avoid.
    - bluGill 3y ago
      You can verify that in either path the same images are loaded, without loading them. (this is what I was getting at by invoking the halting problem - if you cannot determine easily that it is loaded in both paths they are trying to fool your anit-traking and so you default to assuming it is tracking) The more people identified as having anti tracking on, which should be the default, the less useful that bit of tracking is.
      - MrJohz 3y ago
        I don't entirely understand your point, I'm sorry. Could you explain it again? One would generally expect that both paths produce different outcomes, because this is the purpose of media queries, to produce different appearances for different screens. In the example about light mode vs dark mode, a well-designed, non-fingerprinting CSS file might well load different background images for an element to match the user's theme - a dark-background image for dark mode, and a light-background image for light mode. This is the sort of behaviour we are aiming for with this feature. The problem is that this good behaviour is indistinguishable from more malicious behaviour where the images are only used to do fingerprinting. And FWIW, this is the simplest way of doing fingerprinting that I could think of. In the general case, it is not possible to detect whether a given media query would be fingerprintable by a server. For example, a given media query might increase the height of a particular element, pushing a lazy loaded image below the fold and causing it to not be requested immediately, but only after a few seconds when the user scrolls down to it. Or instead of having one "homepage" link on the page, you have multiple, but you only show one depending on which media query fits best. Then, as soon as the user clicks the "homepage" link, you know which link was visible to them and can fingerprint them accordingly. Which is why the nuclear option here is just turning off all possibilities for existing a user's unique preferences, because it's the preferences themselves that are being used to fingerprint the user.
imran-iq 3y ago
To add on to this, why can't the browser just lie to the website but retain my local settings as is
deleted 3y ago
[deleted]
hombre_fatal 3y ago
Zooming basically changes the dimensions of the viewport as JS/CSS see it. Reapplying the zoom level would involve running the same CSS media queries and/or JS so that the website looks good at those dimensions. It's not just an "optical" zoom. But more directly, zooming can put you in very nonstandard width x height dimensions. Carrying those dims across different pages makes for an easy fingerprint which is probably why it's reset.
- pdonis 3y ago
  > Zooming basically changes the dimensions of the viewport as JS/CSS see it. I don't care what the website's JS/CSS says. At the end of the day the browser has a rendered canvas; I just want to zoom the canvas (and clip it at the window dimensions, providing scrollbars if necessary, if zooming makes it larger than the window dimensions). The browser shouldn't have to re-run anything to do that; zooming and clipping a canvas are graphics operations that have existed in computers for as long as there have been computers with graphics at all.
  - olliej 3y ago
    When people increase their font size/zoom they generally don't want that - what you're describing is the default zoom on phones, etc which is different from increasing the page text size, and you'll note is typically about increasing undersized ui components rather than simply reading text. When people are in a browser and expanding the content they want the content reflowed - having to scroll to read the width of a line is super obnoxious, and makes reading text much harder. This is made even more frustrating when you recall that a lot of time the reason for zooming is to make things easier to read. There are very few times where the correct response to "increase the zoom" is simply an affine transform of the rendered content, from both a usability standpoint or from user intent.
    - pdonis 3y ago
      > When people are in a browser and expanding the content they want the content reflowed Even if this is the case, I don't see why the browser has to re-run anything from the website or tell the website anything. It can just do the reflow operation locally. Yes, the central data structure then is the DOM rather than a rendered canvas, but the DOM is still held locally.

mixmastamyk 3y ago

Dark mode is generally decided at the client via choosing which block of css to use. Are these sites sending different css instead?

seanw444 3y ago

My primary issue is that it limits the refresh rate. It immediately gets choppier when scrolling, which is suuuuper annoying.