Letterboxing can be bypassed in a pre-render state
Categories
(Core :: Window Management, defect, P2)
Tracking
()
People
(Reporter: tjr, Unassigned)
References
Details
There's at least one way to do this; maybe more. I'm hopeful that fixing this instance would fix all other issues.
The new window test on https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#screen will be able to grab the viewport sizes before letterboxing is applied.
Note that with RFP enabled, the popup is fixed to a (max) size of 1000x1000 and the test will grab that value. But it's coincidental that 1000x1000 is also the letterboxed value. You can observe this test succeeding in stealing the real viewport size by either disabling RFP, or setting privacy.resistFingerprinting.letterboxing.dimensions to something like 500x500.
So with RFP enabled, and all other settings default, we are protected from this by luck.
But if the user has set browser.link.open_newwindow.restriction to, for example, open windows in a new tab - then we are not protected because we'll be grabbing the viewport size.
|
||
Comment 1•5 years ago
|
||
Tom, does LB happen when the new window has no content
|
Reporter | |
Comment 2•5 years ago
|
||
(In reply to Simon Mainey from comment #1)
Tom, does LB happen when the new window has no content
Yes; it seems like it does. At least it does for about:blank and about:newtab if that's what you mean. I'm not sure whether or not it needs to; but it does.
|
|
||
Comment 3•5 years ago
|
||
I'm not sure whether or not it needs to
Yes, it needs to: see https://people.torproject.org/~gk/misc/entire_desktop.html . Can any other non-web-content window be used this way, or loaded and be used to send back inner window measurements to web content? (I think I know of some)
|
|
Reporter | |
Comment 4•5 years ago
|
||
Hm, nothing comes to mind. (I'm considering ftp:// and related to be web content and trying to think of some sort of Firefox modal popup we have that would behave similarly...)
|
|
||
Comment 5•5 years ago
|
||
This sounds a bit hacky ... (and duplicated code I guess until you rework it?), but rather than wait for the LBing to kick in, always round down as per the stepping, knowing that the LB will happen a few ms later (has anyone timed how long it takes?)
|
|
||
Comment 6•5 years ago
|
||
https://thorin-oakenpants.github.io/testing/newwinLB.html - the letterboxing seems to kick in around the 2 to 6 ms mark, depending on whether it's a new tab or a new window
|
|
||
Comment 7•4 years ago
|
||
(In reply to Simon Mainey from comment #6)
https://thorin-oakenpants.github.io/testing/newwinLB.html - the letterboxing seems to kick in around the 2 to 6 ms mark
Updated to reflect more accurate timing: as counting setInterval at 1ms is never quick enough (even stripped down to the core functionality). Following the instructions (disabling RFP), I consistently take approx 20ms for LB to kick in at it's final size on desktop Firefox
It's even worse on desktop Tor Browser (due to latency? no networking cache?): I bumped up the setInterval checks to 60 and on first load (after New Identity: and RFP is off so I can get accurate info), LB still hasn't kicked in after 200ms - a subsequent test shows it kicks in around 100ms
Those are the results on my PC. I guess the more powerful the machine, the quicker the code executes: still, it's a significant delay, and while clamping new tabs (as Tor Browser enforces) might work in some cases, it does nothing for new windows (which Firefox allows)
|
|
||
Comment 8•4 years ago
|
||
Interestingly, on Tor Browser (alpha), I can detect the borders (at least I think that's what it is), I don't get this in Firefox (with RFP + LB on): i.e 2px diff in width, 1px in height: it's very early on
0 | 0ms | 1136 x 1042 // very first measurement taken as soon as possible
1 | 0ms | 1138 x 1043 // stays at this until LB kicks in, it's about the 1ms mark
12 | 100ms | 1100 x 1000 // LB kicks in
|
||
Comment 9•4 years ago
|
||
(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #0)
The new window test on https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#screen will be able to grab the viewport sizes before letterboxing is applied.
Wouldn't be the obvious answer to simply start the website's code execution after the letterboxing aligned? As currently the issue sounds to me that we have simply a race which one is faster: The (very first) website's code execution to check for the viewport or the letterbox aligning.
Feel free to correct me if I'm misunderstanding something here. Do we otherwise have some new informations about this issue or is any progress in sight? Fixing this issue will also help evaluating further steps in bug #1538130 which is being blocked now.
In case it is relevant for the source cause of this issue in past releases of Firefox (and I guess still in the current one) there is a bug that causes the stepping of the letterboxing to incorrectly step too much. This randomly happens (might be a bit difficult to reproduce) if the search bar on a website (CTRL + F) is being opened. Instead of stepping back 1 time as expected (as in my setup (Windows 10; 1680x1050 screen resolution; menu bar in Firefox enabled; Firefox being maximized with experimental letterboxing enabled) there would now not enough space) there are 2 steps being done and thus making the content window now smaller as it should be. I think switching tabs might encourage this behavior. Also switching to another tab (where no search bar is active) causes it then to randomly stepping back 1 time too.
|
||
Updated•2 years ago
|
Description
•