Opened 4 years ago

Last modified 17 months ago

#7256 needs_information project

Explore zoom-based alternatives to fixed window sizes

Reported by: mikeperry Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-resolution, tbb-bounty, tbb-firefox-patch
Cc: gk, isis, brade, mcs, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Right now, we set the size of new Tor Browser windows such that their content area is a 200x100 multiple. We also lie to content that the entire desktop resolution is this size.

However, this potentially leaks information for users who maximize their browser windows, as such windows will no longer be rounded.

We could play with zooming such that maximized windows do not reveal Firefox decoration sizes. We could also set the zoom level automatically such that we end up with a content window size of a 200x100 multiple as well.

Not sure how complicated this will be. See also #7255 for a potentially simpler stopgap.

Child Tickets

Change History (25)

comment:1 Changed 4 years ago by mikeperry

  • Summary changed from Explore alternatives to fixed window sizes to Explore zoom-based alternatives to fixed window sizes

Similar issues exist for users who leave the "Find" bar open for long periods of time. The find bar existence could be concealed by similar zoom tricks (but this might make using find more jerky due to the page redraw).

comment:2 Changed 4 years ago by mikeperry

  • Keywords tbb-bounty added

comment:3 Changed 4 years ago by gk

  • Cc g.koppen@… added

comment:4 Changed 4 years ago by mikeperry

This may also solve #6146.

comment:5 Changed 4 years ago by cypherpunks

This solution will confuse/frustrate some users of websites such as Yahoo mail, which complains if the screen resolution is below 1024 x 600. It is probably best to warn the user.

comment:6 Changed 4 years ago by mikeperry

It is almost never best to warn the user. The whole point of this feature would be to report a resolution high enough such that sites would happily render, but then scale them either up or down to the actual content window using the "site zoom" code already in Firefox.

comment:7 Changed 4 years ago by cypherpunks

Alternatively, the "virtual" area of the content window could be changed (i.e. the scrollable area could be changed) and the zoom could be left entirely up to the user as usual. I believe the user should be in control of the zoom.

comment:8 Changed 3 years ago by gk

  • Cc gk added; g.koppen@… removed

comment:9 Changed 3 years ago by ben

Please see #10833. It points out that when a user does not maximize and uses an uncommon window size (which is easily possible for me in TorBrowser), the user ends up being unique.

The core issue is that screen size == window content size is a bad idea. Screen size must be one of the common monitor resolutions like 1280x720 or 1920x1080. One simple fix is to just always report 1920x1080, unless the window is larger.

comment:10 Changed 3 years ago by joebt

Now using TBB 3.5.2 (Windows).
I see "odd" (unique) screen sizes reported / detected on browser test sites, in TWO scenarios.
1) When Windows system DPI is set = default 96 DPI.
2) When system DPI is NOT the default value (many users must set it larger, to be able to read screens. Ex.: both Windows' & apps' Help screens, or text in browser screens (TBB).

On or others, with Windows' DPI = 96, AND the TBB UI maximized (full screen), test sites don't show "common" screen (monitor) size. They show something like 1920 x 927 - a very "odd" value.

At same exact time, regular Fx shows "screen size" = 1920 x 1080 x 24.

If Windows' DPI is set > 96 (~ 100 - 110 DPI), screen size detected by test sites is very odd. Then, with TBB UI maximized, test sites show something like 1647 x 661 x 24. An extremely UNIQUE value.

TBB doesn't seem to report a believable, "common" screen size in either scenario: when Windows' is set to default 96 DPI, or when it's set > default (say, 105 DPI), as millions of users must do, in order to read the screen - whether in a browser, other apps, help screens, etc.

Comment #2 at, "gacar's" comment indicates this whole issue may be more complicated than many realize; especially sites using "advanced" scripts to gather data (see link to "fpdetective" software, in the Stackexchange post).

I'd imagine, that under all these quite common scenarios, a consistent, common screen size should be reported.

comment:11 Changed 3 years ago by joebt

Additional comment: note that at the same moment Panopticlick, etc., is showing an odd screen size for TBB 3.5.2 (like 1920 x 966 OR, if refresh page once, perhaps 1920 x 967), a full screen capture of the same maximized browser screen (taking up full monitor), shows 1920 x 1080.

The "966 or 967" TBB screen height (or whatever odd number), turns out to be the height for the part of browser window, beginning just below the browser navigation bar, down to the top of "Addon Bar."

However, in regular Fx with exact same, similarly sized toolbars displayed (as in TBB), the test sites show screen size of the full monitor: 1920 x 1080, not just the "usable display area" of the browser pane (the part of browser window where websites actually display).

This is a fundamental difference what test sites "see" as screen size in TBB vs. Firefox.

In TBB, they see usable display area of the browser window. In Fx, they see the entire monitor.

comment:12 Changed 3 years ago by gk

With a solution to this bug maybe we can somehow prevent other extensions from messing with our fingerprinting defenses, too? See: #11319 for a use case.

comment:13 Changed 3 years ago by joebt

I'm a bit confused by the initial statement,

this potentially leaks information for users who maximize their browser windows, as such windows will no longer be rounded. [emphasis added]

Does this mean that most users don't maximize browser windows, generally? I've rarely seen anyone using any browser in partial screen, on a regular basis. Maybe I missed something, but don't see how maximizing browsers would be the exception rather than the rule.

Bug said

We should display some kind of toolbar message or otherwise warn the user against maximizing their Tor Browser window

I wasn't aware of a general practice of never changing Torbrowser from its initial size.
Never seen it referenced on tor-talk in many yrs.

Question: The initial TBB window size is different for various devices. Unless it opens to use much more screen area on phones than it does on a large monitor, isn't it tiny on many phones? Severely affecting usability?

Is it not possible to report some multiple (based on actual full window size) that's a multiple which would be closer to common (full) screen sizes, vs. spoofing a browser / screen size based on a partial TBB window? Seems like it'd be trading one lie for another, but allowing users benefit of a full window (which seems like most use anyway?).

comment:14 Changed 3 years ago by joebt

Furthering the issue on TBB default opening window size, I visited Panopticlick again today, using both Firefox 30 & TBB 3.6.2, in Windows Vista.
Maybe someone can explain the results & comment on vanilla Fx having fewer bits of identifying info (bits ii) than TBB in default screen size.

I visited Panopticlick from a new identity, in a new TBB session (all browsing data cleared).

1) Even at TBB's opening, default screen size (not maximized) - when Windows' DPI is a non-default value, Panopticlick shows TBB has 43.98 bits ii, when js is disabled. Many sites don't operate well w/o js. (do social media sites?) The EFF says approximately 33 bits are needed to identify a computer.

I will visit the site again, when the system DPI is @ default 96 & with TBB in starting, non-maximized window size. As long as JS is enabled, not sure if the total will drop < 33 bits ii.

2) Again, if users have the system DPI @ non-default value, multiple browser characteristic detection sites report "odd" screen size for TBB.
TBB opening default screen size was detected @ 1000x867 w/ java script enabled. Earlier today, same scenario, different session & identity, but js disabled, it showed 1000x837. How's that possible? It seems problematic, in itself? Nothing was different about TBB starting size in the 2 scenarios (that I controlled), or displayed toolbars, etc. I've seen the same behavior before.

3) In my previous test (see comment 10 above), with the system DPI @ 96 default value, Panopticlick STILL showed odd screen size for TBB. If Panopticlick is correctly detecting it (what's actually being reported), how can this be the intended TBB behavior?

  • For detected screen size, how is TBB better than vanilla Fx? Unless I'm doing something incorrectly, for screen size, detection sites don't seem to show TBB as less unique than Firefox.
  • So far, I've never seen anything close to a multiple of 200x100, or any other multiple of real world monitor sizes, for TBB on Panopticlick, in any scenario - whether the system is default 96 DPI, or not.

4) Either there's something unusual about my system, or TBB reporting multiples of 200x100 doesn't work on all systems.

There was nothing "unusual" about my previous browser window / toolbars, during the Panopticlick visit described in comment 10.

5) It seems that TBB window size & the GUI (including allowed toolbars & their sizes) need standardizing.

6) In my vanilla Fx 30, in full screen with java script & cookies disabled, same non-default system DPI, it showed 24.08 bits ii.

Same Fx 30 w/ js enabled, but no other changes, it showed 41.71 bits ii (still better than TBB @ its starting size??). All other things being equal, if I were to use JonDo Fox (extension) in Fx, the bits ii are likely lower than TBB in its starting size. Certainly, screen size would be less unique. Note: In this Fx profile - for fingerprint testing, I'm not using special spoofing methods; just disabling js & cookies.

Yes, there are other reasons to use TBB vs. something like JonDo, but that's not the topic of this bug. Fingerprinting & reported screen size are the topics. I'm not touting JonDo Fox over TBB.

comment:15 Changed 3 years ago by erinn

  • Keywords tbb-firefox-patch added

comment:16 Changed 3 years ago by erinn

  • Component changed from Firefox Patch Issues to Tor Browser
  • Owner changed from mikeperry to tbb-team

comment:17 Changed 3 years ago by cypherpunks

Hello, another "cypherpunks" here.

I'm not code-literate enough to know if this would actually work/be feasible, but

I've been thinking for some time that maybe a better approach to the window size issue would be to increase the amount of "noise" in the user data, rather than trying to shoehorn all users' data into a "uniform" template.
What I'm thinking of is varying the window size by a certain margin/formula on each startup / 'New Identity' (torbutton). Now obviously the variation can't be too great or it will be an anti-feature, but i'd think something around the size/s of the various toolbars/scrollbars/etc. (ca. 25-50px?) wouldn't be too intrusive, and as a bonus would obfuscate what bars individual users have visible (and also i guess window decorations in case those matter?)

Additionally, window size could perhaps be tied more flexibly to available full screen size, instead of the current slightly heavy-handed formula. What about something along these lines?

actual screen area * 95% [optimal percent might be different?]
 +/- random vertical 'margin' [e.g. 25px*(random float between -3 and 3) ]
 +/- random horizontal 'margin' [as above]

Tying the size roughly to full screen size should(?) give acceptable sizes for the majority who are accustomed to full-screen web browsing, while still providing some randomization/obfuscation. Thus it could be "advisable" for users to leave the window size to whatever the browser makes it, but it wouldn't be a huge deal if you toggle fullscreen on/off, fiddle with toolbar and similar settings, etc. - it would all be mostly within the 'noise' margin for that (hopefully fairly common) screen size, and thus not that identifying data.

I guess there could also be an upper limit in the formula - owners of larger than average screens can spare the real estate (alternatively the formula could scale somehow, i guess), whereas users with smaller screens need to make use of the whole screen, or at least most of it. (BTW, with the current formula, i have to manually resize the window all the time because the default 'rounding' results in an absolutely stupid size on my smallish screen). Also, smaller, nonstandard screen sizes are increasingly common, so it makes sense to make more data noise/obfuscation at that end - and as a bonus, this probably would also benefit those who deliberately use partial-screen sizes for whatever reasons.

comment:18 Changed 3 years ago by gk

Hey folks! Thanks for your input but this ticket is about "Explore zoom-based alternatives to fixed window sizes" as its title says. Please, don't spam it as this makes it hard to work with it. I'd suggest our mailing lists (especially tor-talk) for discussing more general issues. Thanks!

comment:19 Changed 2 years ago by isis

  • Cc isis added

Possibly related: #13875

comment:20 Changed 2 years ago by mikeperry

  • Keywords tbb-fingerprinting-resolution added; tbb-fingerprinting removed

comment:21 Changed 2 years ago by mcs

  • Cc brade mcs added

comment:22 Changed 2 years ago by arthuredelstein

  • Cc arthuredelstein added

comment:23 Changed 2 years ago by arthuredelstein

  • Status changed from new to needs_information

Here's a variant of my #14429 patch that doesn't do window autoresizing at all, but instead zooms the window contents to keep dimensions to multiples of 200x100. Margins also appear, but these are more or less minimized by zooming.

Problems with autoresizing seen in #14429:

  • Users are disconcerted by not being able to maximize or resize as they wish.
  • Autoresizing correctly is very difficult on various Linux window systems and the current implementation causes weird symptoms.
  • The menu bar appearing (in Linux) causes the window to shrink.

It would be helpful if anyone would like to test this proof of concept for usability on their favorite OS. Note that manual zooming of the window is not yet implemented.

Edit: This version is now superseded by

Last edited 2 years ago by arthuredelstein (previous) (diff)

comment:24 Changed 2 years ago by mikeperry

As I said in #14429, you might get more feedback if you post snapshot XPIs as attachments or in your homedir on, and provide sha256sums and detached gpg sigs (with gpg -abs).

I think I have a slight preference for using, with the sha256sum posted on trac. That way at least people who don't check GPG sigs can still verify that two different torproject systems both agree on the same instance of the file.

comment:25 Changed 17 months ago by 0123peter

  • Severity set to Normal

OK the word "explore" is in the title, so here are some idle thoughts from an ignorant outsider.

Compile a list of common screen sizes from quarter VGA to Full HD. (Would anything smaller than quarter VGA be usable?) Trim sizes that are bigger than the real size from the list.

Randomly open new windows with a size from that list, perhaps biasing the choice to the most common or largest.

Allow the user to resize the window in various ways;
1) a drop down menu, View -> Window size, arranged from most common to least common (include full screen),
2) mouse over click and drag a corner, with "stickiness" around common sizes (weight the stickiness with the frequency of the screen size),
3) mouse over click on an edge - display a warning to use a corner -
4) when the user clicks on the "full screen" icon display a drop down list (and a warning).

It is not obvious (to me) what to do in response to <control><plus>. The current (5.0.4) behavior is bizarre. Go to panopticlick, <control><plus>, and reload. TBB probably should report the unscaled window size as the screen size. Possibly it could increase the window size (limited by the real screen size) and scale the contents while reporting the original size.

Also, current behavior at full screen size is to report ONE pixel less than the real screen size, which is a VERY odd size.

Note: See TracTickets for help on using tickets.