1556016 - Letterboxing can be bypassed in a pre-render state

Status: ASSIGNED

(Core :: Window Management, defect, P2)

Description

[Tom Ritter [:tjr]]

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

[Thorin [:thorin]]

Tom, does LB happen when the new window has no content

Comment 2

[Tom Ritter [:tjr]]

(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

[Thorin [:thorin]]

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)

Comment 4

[Tom Ritter [:tjr]]

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

[Thorin [:thorin]]

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

[Thorin [:thorin]]

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

[Thorin [:thorin]]

(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

[Thorin [:thorin]]

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

[sworddragon2]

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

Comment 10

[Thorin [:thorin]]

new window test at https://arkenfox.github.io/TZP/tzp.html

• still leaks in FF
• doesn't leak in TB

We hope to uplift a plethora of changes from downstream for newwin, letterboxing and betterboxing. I believe what fixes this is using css grid

Comment 12

[Pier Angelo Vendrame]

Attachment: Bug 1556016 - Part 1: Letterboxing, improve logging. r?tjr

Comment 13

[Pier Angelo Vendrame]

Attachment: Bug 1556016 - Part 2: Mitigate letterboxing race conditions. r?tjr

Preemptively apply margins in a global CSS rule to mitigate race
conditions on newly created windows and tabs.

Depends on D234457

Comment 14

[Pier Angelo Vendrame]

Attachment: Bug 1556016 - Part 3: Use direct browser sizing for letterboxing. r?tjr

Compute and assign width and height to the browser, rather than setting
its margins.

Depends on D234458

Comment 15

[Pier Angelo Vendrame]

Attachment: Bug 1556016 - Part 4: Disable findbar animations with letterboxing. r?tjr

Depends on D234459