Re: [tor-bugs] #32253 [Applications/Tor Browser]: Zooming and letterboxing

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#32253: Zooming and letterboxing
-------------------------------------------+--------------------------
 Reporter:  cypherpunks                    |          Owner:  tbb-team
     Type:  defect                         |         Status:  new
 Priority:  Medium                         |      Milestone:
Component:  Applications/Tor Browser       |        Version:
 Severity:  Normal                         |     Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID:                                 |         Points:
 Reviewer:                                 |        Sponsor:
-------------------------------------------+--------------------------

Comment (by Thorin):

 Replying to [comment:10 cypherpunks]:
 > it's not possible determine whether the original size is 1000x700 or
 1000x600 as they both result in 600x400.

 Sure. Let's call it **reverse buckets per zoom variable**

 I'm not entirely sure here without doing some algebra (and I hate
 algebra), I **think**, the number of buckets isn't actually reduced
 overall (across all zoom levels): i.e as you increase zoom, the number of
 buckets for that zoom decreases because the real estate is less (so you
 get less reverse buckets), but as you decrease zoom, the opposite happens.

 I'm also not sure without doing some more thinking, that a duplicate
 reverse bucket on a zoom level (such as in your example) is not guaranteed
 to happen: it depends of the real available inner window space which may
 already include some letterboxing. We could make assumptions that the vast
 bulk of end users always start and stay at 1000px inner height (not the
 viewport height), but you know what they say about assumptions.

 So I'm not convinced that the number of buckets is reduced, but the
 distribution (or entropy if you will) of each would be altered. Ultimately
 it comes down to end user behavior, and we probably can't measure this
 (but I'm working on it! I'm pushing Mozilla hard as I can. Been badgering
 various Mozilla people for a few months)

 ---

 The more I think about it, the more I see tying zoom to letterboxing as
 creating far more problems and information paradoxes than it solves.

 ***... but ...**

 I have a plan so cunning, you could pin a tail on it and call it a weasel.
 Here's my reasoning:

 - Like this discussion, we're talking theoreticals, edge cases, trying to
 cover all possible angles, PoCs
 - In the real world, AFAICT, no-one does this: they just go for the lowest
 hanging fruit
 - In the real world, they go for plug and play scripts like fingerprintjs2
 (see OpenWMP's fingerprinter lists, and inspect them all)
 - FPing likes stability, and inner window etc is not stable
 - Scripts in the wild only target screen, available screen (because
 stability)
 - We tie everything to the inner window (or letterbox) for compat reasons:
 i.e is we don't lie about this metric because otherwise things break or
 have weird side affects
 - By tying screen, available screen to inner, we now have problem of our
 own making and added complexity

 What I think we could do is
 - treat screen, available screen (and associated @media) differently to
 inner/outer/chrome etc
 - e.g. for Desktop return three or four screen really common resolutions
 only
    - i.e not tie it to the inner window
    - use some logic as to which to use based on the actual monitor res
    - note: without letterboxing we're already returning **way** more than
 that due to rounding errors, bookmark toolbars, desktop environments, DPI
 settings, available screen res
    - note: with letterboxing, we're already returning many as well from
 max 1000x1000 and lower as screen resolution is not available (sure: maybe
 the majority are in two buckets 1000px high and 900px high)
 - This means regardless of zoom, our non-chrome metrics are not affected
 - This means 99.999999% of scripts in the wild will never get more than
 three of four buckets

 This does leave edge cases which already exist: such as when you go full
 screen

 Another one (new in this approach) would be if you create an information
 paradox that leaks, e.g lets say we spoof as `1920x1080` but your monitor
 is a higher res than that, and you manually resize it larger. I think the
 answer to that is a little bit of smart coding logic. e.g. up to our max
 spoof value (lets say its 1920x1080) we always make sure we spoof equal to
 or higher than what is available, and if the inner window kicks over that,
 we either ignore it, or flip to the next bucket. Or we could do that for
 all of them. i.e **just like we step letterboxing based on the inner
 window, let's step non-chrome metrics** - and limit those steps to a
 handful of common screen resolutions

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32253#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs