|
|
|
|
|
|
by bluGill
1161 days 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. |
|
|
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.