Weird screen sizes reported by Panopticlick
When I go to https://panopticlick.eff.org/index.php with TorButton (1.4.5.1) Panopticlick reports (among other things):
Screen Size and Color Depth 1150x600x24
bits of identifying information 14.67
one in x browsers have this value 26138.95but if I go without TorButton it reports:
Screen Size and Color Depth 1280x800x24
bits of identifying information 3.9
one in x browsers have this value 14.94I would suggest that the default settings for the non TorButton report are far more anonymous than the TorButton report.
I would suggest changing TorButton to use the default screen size and resolution rather than a modified version.
I have already started work on this.
Trac:
Username: erikd
Activity
Trac:
Username: erikd0001-Bug-4810-Weird-screen-sizes-reported-by-Panopticlick.patch
Ok, so first off, this is not as big an issue as it seems: https://blog.torproject.org/blog/effs-panopticlick-and-torbutton
However, enough people seem to be going to Panoptlick and becoming concerned that we should try to do something to combat the FUD.
Right now, what torbutton does is to pick an initial window size in 200x100 increments based on your desktop resolution. This should only result in a handful combinations for most monitor sizes. It then reports this browser resolution as your desktop resolution. The problem with this wrt Panopticlick is that the resulting values are not popular desktop resolutions.
The problem for us is that providing different values that are in any way related to your real desktop resolution will actually leak more information than what we do currently.
However, there may be a solution where we either alter the set of initial window sizes to be actual common-ish desktop resolutions that happen to be smaller than your current desktop, or 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).
This fixed-mapping approach should result in the same total joint entropy, because there are exactly the same number of possible values, but the desktop sizes happen to look nicer to panopticlick because they are more common. I think it is worth doing this to reduce the FUD about Torbutton and TBB.
The code that sets the initial window size is in torbutton_set_window_size(): https://gitweb.torproject.org/torbutton.git/blob/master:/src/chrome/content/torbutton.js#l4063
Note that this code is at a different privilege level than the code in jshooks4.js. You can only get values into jshooks4.js by smuggling them in the torbutton_hookdoc() function: https://gitweb.torproject.org/torbutton.git/blob/master:/src/chrome/content/torbutton.js#l4459
Does this make sense?
Trac:
Cc: N/A to pde
Status: assigned to needs_revision-
Trac:
Username: erikd -
#2907 (closed) was dupped to this bug.
-
The real answer here might actually be to run our own Panopticlick, to measure only intra-TBB entropy. I created #6119 (moved) for that.
Going to leave this open though, in case there might be compelling reasons to blend TBB users in with the crowd more in the future.
-
I filed the same bug as #10833 (closed). I've proposed exactly the same fix there:
- Hardcode a set of a common screen resolutions. Then, pick the smallest that can fit the current window size.
Concretely:
actual screen size | window size | screen size cur | screen size proposed 1920x1200 | 1057x909 | 1057x909 | 1920x1080 1920x1200 | 1057x1100 | 1057x1100 | 2880x1800 1280x720 | 1270x685 | 1270x685 | 1920x1080 1280x720 | 1000x600 | 1000x600 | 1920x1080 1280x720 | 800x400 | 800x400 | 1920x1080- 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.
This would be strictly better (some cases better, no case worse) than the current solution.
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.
Unusual window sizes are still a problem, but that's for another ticket to solve. Unusual screen sizes stand out a lot more, though - //even for websites that do not specifically target Tor users//.
Reproduction:
- Start browser
- Resize window manually to a size that pleases me
- Go to <http://browserspy.dk/screen.php> and <http://browserspy.dk/window.php>
Actual result standard Firefox: window size: 1057x909 screen size: 1920x1200
Actual result Tor browser: window size: 1057x909 screen size: 1057x909 (that's the "bug")
Expected result Tor browser: window size: 1057x909 screen size: 1920x1080 (that's the fix)
Trac:
Username: ben 
Replying to ben:
Unusual window sizes are still a problem, but that's for another ticket to solve.
While that is true, I'd argue that this problem is the main problem we need to solve here and that we don't treat it as an unrelated one. If we achieve that (and #7256 (moved) is one idea to explore) then it does not matter much by which way an attacker does not get to know anything about the actual desktop size (be it with the current approach, binding the screen size to the window size, or be it the one this bug proposes). In the end, if we solve the problem with the unusual window sizes (which we need to solve anyway) we might even end up with less coding effort if we bind the reported screen size to the window size as we already have that code working.
-
Guys, this is ridiculous. This patch should have been applied two years ago while the proper fix was discussed and implemented. Hell, even forcing the TBB window to one static size and disallowing resizing is more acceptable than leaving this for so long.
This might not be as serious an infoleak vulnerability as, say, enabling Flash by default, but it is a serious infoleak vulnerability nonetheless. Let's please do something about this now, rather than later.
With that said, both screen size and window size should be masked. For me, the ideal solution is to only ever report, say, two sizes (depending on the user's actual chosen window size) and automatically zoom the view to compensate for the difference between reported and actual size. TBB already presents some usability problems with plugins, etc.; screwing up some sites' layouts and making them appear ugly is a small price to pay for mitigating such an obvious de-anonymization vector.
Trac:
Username: v3glvnCJK7NRg1kK A solution also has to consider, that people zoom. My zoom level is 190% at the moment for example. So browerspy a shows pretty low and (I assume) uncommon window and screen size.
http://ip-check.info shows the resolution in real-time (without reloading the page) and i noticed there, that i can just zoom the text size instead of zooming the whole content. That leaves the reported screen-/windowsize intact. I'm using the NoSquint extension.
-
I'm using a pretty uncommon* window size (due to unique placement of my Tor and Firefox windows), so wouldn't it be very easy for an attacker to correlate my Tor-traffic with my non-Tor-traffic (coming through browsers with the exact same window sizes)? I'm not an expert but this seems to be a pretty major issue!
Shouldn't you (at least) warn all Tor-users not to use Tor without having NoScript activated?
- = unique according to panopticlick
Trac:
Username: XhFpUeif0uIOCaq8HDlpZWBZMQXkjOSi -
Its worth noting that the github version of "Random agent spoofer" has implemented screen and window size spoofing. I think both projects should use same or similar spoofing strategies which would help a lot to reduce the fingerprint of all users. RAS allows users to select either random or some specific screen resolution which also enables window size spoofing (which needs some fine tuning but is a good start). Here is some more info https://github.com/dillbyrne/random-agent-spoofer/issues/54
I am not sure if TorButton is safe to use together with RAS?
Trac:
Username: rndusr8e -
random agent spoofer is not a good idea for window size spoofing because it can only fake resolution for javascript. window size detected via css cannot be faked so a well equipped website could gather more information with enabled RAS than without.
Instead of snapping the window size to multiples of a fixed amount of pixels it should snap to common(common for firefox) window sizes reported by panopticlick. wether to use window resolutions from maximized windows depends on wether to use static or dynamic screen size if it is important that javascript cannot see the screensize change.
Trac:
Username: elypter
Sponsor: N/A to N/A -
Why is this ticket still open 5 years after being reported, given an utterly sensible solution (snap reported desktop resolution to one of two values that will fit client window) has been proposed?
Why is there not consensus that reporting a desktop resolution that no physical monitor has ever had is a serious flaw, resorting to a deeply suspect argument 'we only need tor browser bundle users to be indistinguisable from each other'. The proposed fix would maintain that ability, while simultaneously removing the ability for a few lines of javascript to pick out a tor browser user from a non tor browser user.
Seriously guys, it would take 5 minutes to patch this. Change getDesktopWidth() from { return window.width; } to { return window.width < 1920 && window.height < 1080 ? 1920 : 2880; } and getDesktopHeight() from { return window.height; } to { return window.width < 1920 && window.height < 1080 ? 1080 : 1800; }
See? Simple.
So stop bloody prevaricating and arguing about this and just do it, or explain why it's taking so long.
Trac:
Username: trippylizard
Reviewer: N/A to N/A 
+1 for closing this
- It's old: nothing really added for 5 years
- We have now use the RFP patch from Tor Uplift for resizing the chrome, and #27845 (moved) is open as well as upstream at Mozilla to fix that issue. Anything in this ticket is well out of date and irrelevant
- We also have RFP's new letterboxing in FF67+ to consider come ESR68. Currently it is independent to the chrome resizing, but will (I'm sure) replace that.
mentioned in issue #6119 (moved)
mentioned in issue #10833 (closed)
mentioned in issue #10833 (closed)
mentioned in issue #13636 (moved)
mentioned in issue #17328 (moved)
mentioned in issue #24009 (moved)
mentioned in issue tpo/applications/tor-browser-bundle-testsuite#6119 (closed)
mentioned in issue tpo/applications/tor-browser#24009 (closed)
