This is an obvious way to find out Tor users, and also allows to track them even better than without this change. A screen (!) resolution of 1057x909 must really stand out and allow to track a user easily. This would stay the same across all sessions and sites and even reboots.
A window/content resolution of 1057x909 isn't very common either and problematic, but that problem exists independent of the screen resolution. This issue isn't theoretical: I heard about 5 years ago that even Google tracks users based on non-standard window resolution.
That said, a screen resolution of 1057x909 would appear only among TorBrowser users and thus be fairly unique world-wide.
Trac: Username: ben
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
Hardcode a set of a common screen resolutions. Then, pick the smallest that can fit the current window size. (Downside: It would still lead to changing screen resolutions when the user resizes the window, which could be detected and is also unusual, but the leaking info is only that the user uses Tor, not unique.)
Okay, the height issue will be fixed with #10095 (closed) which is included in the new release coming out in the next days. The weird width is interesting. Could that be an instance of #9268 (moved)?
Are you resizing your Tor Browser window? Both pages give me the same values which are not my non-TorBrowser screen size if I do not touch the window size in any way after start-up.
Could you set "extensions.torbutton.loglevel" to "3" and copy & paste the relevant window resizing debug messages shown into the browser console?
Tor browser does precisely what the design document (quoted in the description) specifies: It makes the screen size be the window content size. Just that this idea is misguided: it causes an identity leak.
How dangerous this is can be clearly seen when you go to https://panopticlick.eff.org and click "Test me". You will most likely be "unique", due to the unusual screen resolution.
Test again with maximized window and watch the "one in x browsers" value for screen resolution go down dramatically.
To further reduce resolution-based fingerprinting, we are investigating zoom/viewport-based mechanisms that might allow us to always report the same desktop resolution regardless of the actual size of the content window, and simply scale to make up the difference.
gk, while #7296 (moved) touches on the same issue, it's not identical.
It speaks about users maximizing windows. This bug here is specifically about users not doing so.
Also, the core issue here is that screen size == window size. While the design doc paragraph you cited agrees that this is bad and says "always report the same desktop resolution regardless of the actual size of the content window", bug #7256 (moved) is not about that.
Lastly, the solutions proposed here are rather simple, in comparison.
Also, the core issue here is that screen size == window size.
It's not issue, it is planned by design.
Resize window to a size that pleases me
That is problem, you have only choice to find way for #7256 (moved) or nothing. Reporting false sizes without zooming content will break proper rendering and usability.
Then, pick the smallest that can fit the current window size.
4:3, 5:4, 14:9, 16:9, 16:10, for which one?
We make our decisions about fingerprinting based on the concept of entropy reduction inside the TBB userbase. It is not possible to both defend against fingerprinting and prevent TBB from being detected as TBB.
Content size is a problem, too, but a different issue.
Then, pick the smallest that can fit the current window size.
4:3, 5:4, 14:9, 16:9, 16:10, for which one?
Doesn't matter. In fact, we can simply //always// report 1920x1080. Unless the window is bigger, and then report some even higher screen res.
First, there are websites out there that will try to resize browser windows to the whole desktop resolution, or to a fraction of the desktop resolution.
Further, reporting multiple resolutions for the desktop actually introduces more fingerprintable entropy. In fact, people with larger than 1920x1080 displays will necessarily stand out with your suggestion.
It is not possible to both defend against fingerprinting and prevent TBB from being detected as TBB.
OK, so detection of Tor is not an issue. Understood.
We make our decisions about fingerprinting based on the concept of entropy reduction inside the TBB userbase.
Right. But a screen resolution of 1057x909 would likely appear only once world-wide.
First, there are websites out there that will try to resize browser windows to the whole desktop resolution
We'd need to prevent that. Even regular Firefox prevents window resize and popups (by default, and almost all websites accepted this limitation). So, I don't think that's an issue. If we would allow that, that would definitely allow tracking: Just resize the window to a unique size, and then later or on another site or session query it. Even if you change the size for new windows, it would allow to match different sessions within the same window.
Further, ... people with larger than 1920x1080 displays will necessarily stand out with your suggestion.
No more than they currently do.
My suggestion can reduce entropy dramatically (from 20+ bits=unique to 2 bits: 2 resolutions within TBB only). Is there a case where it increases entropy compared to now in TBB?
There will only be 2 resolutions within TBB: 1920x1080 and a very high one. This reduces entropy to exactly 1 bit (2 values) within TBB.
The screen size can change for an individual user, which is strange, but it's currently the case with the current fix as well.
We can't allow window resizes //requested by the website// and window size queries anyway, because they allow tagging/matching sessions within the same window.
OK, that was most interesting and relevant. It turns out that erikd created pretty much exactly the patch that I am proposing here (solution 2 in comment:1 here vs. his patch there).
And you confirmed there that this is a good solution, in comment:3:ticket:4810:
However, there may be a solution where we ... just assign a fixed mapping from each of these window sizes to a fake desktop size that is larger (but ideally within a sane bound of the current desktop).