Opened 9 years ago

Closed 14 months ago

#4810 closed enhancement (worksforme)

Weird screen sizes reported by Panopticlick

Reported by: erikd Owned by: mikeperry
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-resolution
Cc: pde, gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


When I go to with TorButton ( 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.95

but 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.94

I 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.

Child Tickets

Attachments (3)

0001-Bug-4810-Weird-screen-sizes-reported-by-Panopticlick.patch (2.9 KB) - added by erikd 9 years ago.
Patch to fix this bug
panopticlick-screen-resolution-detection.txt (116.1 KB) - added by erikd 9 years ago.
Statistics of screen resolutions captured by panopticlick. Thanks PDE.
Screenshot - 251017 - 23:34:16.png (109.1 KB) - added by cypherpunks 3 years ago.

Download all attachments as: .zip

Change History (24)

Changed 9 years ago by erikd

Patch to fix this bug

comment:1 Changed 9 years ago by erikd

Status: newneeds_review

comment:2 Changed 9 years ago by mikeperry

Component: TorbuttonTorBrowserButton
Owner: changed from erikd to mikeperry
Status: needs_reviewassigned

comment:3 Changed 9 years ago by mikeperry

Cc: pde added
Status: assignedneeds_revision

Ok, so first off, this is not as big an issue as it seems:

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():

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:

Does this make sense?

Changed 9 years ago by erikd

Statistics of screen resolutions captured by panopticlick. Thanks PDE.

comment:4 Changed 8 years ago by mikeperry

Milestone: TorBrowserBundle 2.3.x-stable

comment:5 Changed 8 years ago by mikeperry

#2907 was dupped to this bug.

comment:6 Changed 8 years ago by mikeperry

Component: TorBrowserButtonFirefox Patch Issues
Priority: normalmajor
Type: defectenhancement
Version: Torbutton:

comment:7 Changed 8 years ago by mikeperry

The real answer here might actually be to run our own Panopticlick, to measure only intra-TBB entropy. I created #6119 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.

comment:8 Changed 7 years ago by ben

I filed the same bug as #10833. 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.


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
  1. 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.
  2. 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.


  1. Start browser
  2. Resize window manually to a size that pleases me
  3. Go to <​​> and <​​>

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)

comment:9 in reply to:  8 Changed 7 years ago by gk

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 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.

comment:10 Changed 7 years ago by gk

Cc: gk added

comment:11 Changed 7 years ago by v3glvnCJK7NRg1kK

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.

comment:12 Changed 6 years ago by cypherpunks

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. 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.

comment:13 Changed 6 years ago by XhFpUeif0uIOCaq8HDlpZWBZMQXkjOSi

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

comment:14 Changed 6 years ago by rndusr8e

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

I am not sure if TorButton is safe to use together with RAS?

comment:15 Changed 5 years ago by elypter

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.

comment:16 Changed 5 years ago by bugzilla

Component: Firefox Patch IssuesTor Browser
Keywords: tbb-fingerprinting-resolution added
Milestone: TorBrowserBundle 2.3.x-stable
Severity: Normal

comment:17 Changed 4 years ago by trippylizard

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.

Last edited 4 years ago by trippylizard (previous) (diff)

Changed 3 years ago by cypherpunks

comment:18 Changed 3 years ago by cypherpunks

i was a bit concerned recently using an LXDE desktop on debian

the TBB windows is clearly smaller than on other window managers like gnome

on a 1366w 15.6" laptop

see screen shot just upoaded

is this an issue ?

comment:19 Changed 3 years ago by cypherpunks reports 1500x1000

comment:20 Changed 17 months ago by Thorin

+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 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.

comment:21 Changed 14 months ago by mikeperry

Resolution: worksforme
Status: needs_revisionclosed

Thanks Thorin. I agree that this bug is old and does not represent any current issues, even if more exist. The underlying implementation has completely changed.

Note: See TracTickets for help on using tickets.