Zooming and letterboxing
Zooming changes reported window size, so letterboxing should be applied. This does not work at the moment or is buggy:
- does not letterbox on zoom event, only after resizing the window
- resizing the window on a zoomed tab applies proper letterboxing (multiples of 100) only after resizing the window back to its standard/default size
- when resizing the window back to its default size, the letterboxing is still applied to all other non-zoomed tabs, making their size smaller than standard despite the available space for default size
Activity
OK, then it can be closed. However there is still an issue related to point 3 that I've mistakenly associated with zooming.
The issue not related to zooming at all, it's instead caused by resizing the window from default size and resizing the window back: the letterboxing does not disappear, i.e. it is not restored to the default state of the newly created (default-sized) window without letterboxing space around the "content" area.
How to reproduce:
- open a window
- resize the window (letterboxing appears)
- resize the window back exactly to the default size (use another fresh window as "reference")
- the letterboxing space is still applied (the "content" area is smaller than default by 100 in both width and height)
Expected behaviour:
- In the step 3 the letterboxing should disappear, as in a fresh default-sized window.
Zooming should be handled by letterboxing as well because sizes like 667x667 still stand out. It enlarges the set of possible window sizes by a lot, since it is based on both the amount of zoom and the window size which can both vary a lot from user to user.
So wouldn't it better for zoomed-in tab to be part of the multiples-of-100 set? Then someone zooming-in would be indistinguishable from someone with a smaller window.
I understand it's hard to implement and you've got a lot on your plate. But I don't think it should be dismissed as possible enhancement in the future.
EDIT: and letterboxing to multiples of 100 is already applied right now to zoomed-in tabs, you just have to resize the window for it to take effect. Which is why I thought that handling a zoom event is all it's needed.
Replying to cypherpunks:
The issue not related to zooming at all, it's instead caused by resizing the window from default size and resizing the window back: the letterboxing does not disappear
I cannot reproduce this: my steps (based on yours)
- open TB (hide the bookmark toolbar if showing and click new identity)
- you should now have width & height at 100's and no letterboxing (e.g
1000x1000) - load https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html and note the inner window measurements (mine is
1000x1000) - manually resize your browser, and watch the measurements and letterboxing kick in - be mesmerized :)
- manually resize back to your original size
- the letterboxing no longer exists
Edit:
the "content" area is smaller than default by 100 in both width and height
When you suddenly lost an extra 100px, that's because your manual resizing nudged it fractionally too short/narrow. I took screenshots before and after, layered them in photoshop, zoomed in big time, and toggled the layers to make sure there wasn't anything out by a pixel. It's working as designed in this respect
-
Replying to cypherpunks:
Zooming should be handled
There is no entropy here that zoom itself (and other elements) doesn't already give away.
Zoom increases entropy - that's why RFP disables site specific zoom settings from being retained, and zoom is limited to the current tab. New tabs always reset to 100%.
example A
- page is
1000x1000at 100% - you zoom to 150%
- the metrics now show
677x677 - lots of other measurements have also changed
example B
- page is
1000x1000at 100% - you zoom to 150%
- letterboxing magic resizes the display content to
600x600 - the metrics now show
600x600 - lots of other measurements have also changed and are not altered by letterboxing
What have you achieved by tying zoom to letterboxing? Have I missed something?
- page is
Replying to Thorin:
What have you achieved by tying zoom to letterboxing? Have I missed something? I had something like this in mind:
- user A: 1000x700 + 150% zoom -> 667x467 + letterboxing -> 600x400
- user B: 1000x600 + 150% zoom -> 667x400 + letterboxing -> 600x400
If I understand correctly your point is that the page will first see the original size, then see the decreased size, so you're not hiding anything. If we assume the site continuously tracks and snitches your window size across your whole visit then it really is quite pointless.
However, even if we're dealing with that kind of site, it's not necessarily the case that it learns about your original window size:
- open about:tor or visit whatever site
- zoom in
- go to some other site in the same tab
In this case the last site has never seen your original size. However without letterboxing it can make some assumptions, like in the example above. For one thing it can immediately tell you're using zoom and do not have a small screen (and vice-versa if you have a small screen).
-
Replying to cypherpunks:
In this case the last site has never seen your original size
It doesn't matter which measurements it sees (at 100% or 133%), because math can be used to calculate the other, as long as zoom is known
current
- site A at 100%: 1000x700
- zoom A to 133%:
752x526<-- weird, but hey you zoomed - site B (same tab at 150%)
- site B uses math and calculates 100% = 752 x 1.33 by 526 x 1.33 = 1000x700
proposed
- site A at 100%: 1000x700
- zoom A to 133%: 752x526 -> 700x500
- site B (same tab at 133%)
- site B uses math and calculates 100% = 700 x 1.33 by 500 x 1.33 =
933x665<-- weird because you tried to solve a problem that does not exist
You can't "standardize" both ends unless you can completely spoof zoom, which is problematic and probably undo-able. And there are so many other ways to get measurements, e.g elements, and monitor them, e.g. observer APIs. DPI complicates this as well.
PS: I used 133% as an example so we got back crazy non-uniform numbers: some zoom levels are multipliers that can or do still round things
Replying to Thorin:
It doesn't matter which measurements it sees (at 100% or 133%), because math can be used to calculate the other, as long as zoom is known Well that was my point when I wrote that it can make assumptions because the values are not rounded. In my example above, where letterboxing is applied, it's not possible determine whether the original size is 1000x700 or 1000x600 as they both result in 600x400.
unless you can completely spoof zoom, which is problematic and probably undo-able. And there are so many other ways to get measurements, e.g elements, and monitor them, e.g. observer APIs. DPI complicates this as well. I'm aware of that. However decreasing the ways to extract some piece of fingerprint is still worth something IMO, even if there are other (more elaborate) ways to get to the same or similar info about the user.
Anyway, my initial impression was that this was doable. For reference, here's a blog comment from gk:
So, for the zoom I meant in the upcoming major release, Tor Browser 9, with letterboxing enabled. However, I looked closer now and stand corrected in that letterboxing does not solve the zoom issue automatically. We'd need to look into it. https://blog.torproject.org/comment/284106#comment-284106
-
Replying to 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
1920x1080but 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 Replying to Thorin:
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
I like this idea a lot. If many scripts in the wild really do go for the screen size and not inner window then this would be a massive improvement.