Open Bug 1556016 Opened 4 months ago Updated 3 months ago

Letterboxing can be bypassed in a pre-render state

Categories

(Core :: Window Management, defect, P2)

defect

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.

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

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

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)

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

You need to log in before you can comment on or make changes to this bug.