Explore zoom-based alternatives to fixed window sizes

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 (moved) for a potentially simpler stopgap.

added component::applications/tor browser owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-bounty tbb-fingerprinting-resolution tbb-firefox-patch type::project labels

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

Trac:
Summary: Explore alternatives to fixed window sizes to Explore zoom-based alternatives to fixed window sizes

Trac:
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting tbb-bounty added

Trac:
Cc: N/A to g.koppen@jondos.de

This may also solve #6146 (closed).

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.

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.

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.

Trac:
Cc: g.koppen@jondos.de to gk

Please see #10833 (closed). 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.

Trac:
Username: ben

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 browserspy.dk 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 (closed) at https://tor.stackexchange.com/questions/1619/fingerprint-effect-of-changing-tbb-default-font-size, "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.

Trac:
Username: 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 96__7__), 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.

Trac:
Username: joebt

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

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 https://trac.torproject.org/projects/tor/ticket/7255 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?).

Trac:
Username: 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.

Trac:
Username: joebt

Trac:
Keywords: tbb-fingerprinting tbb-bounty deleted, tbb-fingerprinting, tbb-bounty, tbb-firefox-patch added

Trac:
Component: Firefox Patch Issues to Tor Browser
Owner: mikeperry to tbb-team

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.

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!

Possibly related: #13875 (moved)

Trac:
Cc: gk to gk, isis