1677733 - Bookmarks toolbar for new tabs changes screen resolution for new window when privacy.resistFingerprinting is turned on

Status: NEW

(Firefox :: Bookmarks & History, defect, P3)

Description

[Georg Vogt]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

With the Bookmark menu enabled only for New Tabs (for me enabled per default in Nightly) the screen resolution changes when opening new windows.
I have privacy.resistFingerprinting on, so the nice 1000x1000 gets replaced by 1000x1020.

Actual results:

Screen resolution increases for new empty windows (new tab) and remains increased when opening a non empty site.
Screen resolution remains correct for new window with content (open link in new window.

Expected results:

At least with privacy.resistFingerprinting activated the screen resolution should not change.
I fixed this by disabling the bookmark menu for new tabs, so before enabling the new menu one could check for the privacy.resistFingerprinting property.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[:Gijs (he/him)]

Arthur, can you remind me how the fingerprinting resistance resolution adjustment works now? IIRC we changed approaches a few times and I lost track. Do you know if anyone works on this at the moment and can help?

Comment 3

[Arthur Edelstein [:arthur]]

I don't believe we have anyone working on it right now, but we are planning more fingerprinting efforts in the coming months. Tom and Tim, does this look like a bug to you?

Comment 4

[Tom Ritter [:tjr]]

Sounds like a bug. From the description, this isn't about letterboxing, but rather about the original resolution behavior, about opening new windows with a fixed size. I thought that calculation was somewhere around here but the bug isn't immediately jumping out to me from that code.

Comment 5

[Tim Huang[:timhuang]]

Yeah, this sounds like a bug to me.

It seems that Firefox doesn't get the height of the Bookmark menu when rounding the window. The rounding size was decided when the chrome window was created. This issue could happen if the Bookmark menu is only enabled for New Tabs because the Bookmark menu didn't appear when the window got rounded in the first place. So, it will get an incorrect rounding size.

Comment 6

[:Gijs (he/him)]

I was hoping that the changes from bug 1667237 would help here, but I cannot reproduce either before or after that fix (tested on Windows).

Does this still happen? If so, does it happen only to the initial window, or only new windows? Every time, or is it a race condition of sorts / intermittent? Are you in a position to check if it's Linux-specific? Can you reproduce in a clean profile with just the fingerprint resistance pref set?

Comment 7

[Thorin [:thorin]]

IMO, this is the same issue as if you manually show/hid any chrome elements: sidebar, menubar, toolbar, findbar, docked console. The outer window dimensions are set once and to control the reported inner window, the solution is letterboxing.

I fixed this by disabling the bookmark menu for new tabs

Indeed. IMO, RFP should override the pref

Comment 8

[:Gijs (he/him)]

(In reply to Simon Mainey from comment #7)

IMO, this is the same issue as if you manually show/hid any chrome elements: sidebar, menubar, toolbar, findbar, docked console. The outer window dimensions are set once and to control the reported inner window, the solution is letterboxing.

Is there a meta bug for all these ways in which the current solution is broken? Because there are some more (I noticed, for instance, that the rounding is wrong on my non-integer-scaling Windows machine (ie it's at 1.5dppx), so I get a 1000x1001px viewport), and it seems maybe this needs some rethinking, if you think "the solution is letterboxing" but the implementation doesn't do that...

Comment 9

[Thorin [:thorin]]

so I get a 1000x1001px viewport

So LB is on, your browser window is somewhere just over 1000x1000, you load some web content (you don't need RFP on). How is it being measured - what APIs ? I know emilio landed a patch to allow viewport subpixels, which I asked him about, but I'm not sure if this is the cause - was this test on Nightly? You can use https://arkenfox.github.io/TZP/tzp.html#screen if you want (it also updates in real time if you resize, or toggle LB on/off)

I'm not sure what's being tested here exactly (there's too many unknown variables), or if it's already mentioned in other tickets (tor). The recent tor tickets to do with scaling have manifested since Richard's patch for adding borders to the letterbox (bug 1594455 only done downstream for now). But there are older tickets at tor, but it's confusing due to reporters STR or outdated. I'm not sure if new window sizing (exclude toolbar bug 1418537) has been out by 1 pixel - but maybe (I'll see if I can find one, see [1] ), but there may be an really old one to do with scaling.

but the implementation doesn't do that...

The LB (letterbox) implementation is meant to do that (stepped ranges: https://hg.mozilla.org/mozilla-central/rev/6d2d7856e468#l2.32 ) ... and it does helps mitigate when resizing/fullscreen/maximizing and toggling those chrome things on/off - and in fact protects against your incorrect new window size) - excluding bugs of course

For the most part it works - but there are bugs even without letterboxing, with new window sizes, including with the toolbar: bug 1418537 has been going on since Photon landed (it's not getting the right information because it's getting measured too early: I believe it was in startup perf when something got cut) and my knowledge says that bug 1418537 creates more entropy buckets than rounding being out by a pixel. And then there's tiling managers (linux) and macOS to boot.

The issues with scaling, dpi, layout.css.devPixelsPerPx leak in lots of areas, so there is equivalency - not that we shouldn't try and fix things. And then there are letterboxing bugs as well (such as leaking pre-render on new windows - did do do that in your test above, IDK). So nothing's perfect, unfortunately.

Is there a meta bug

Bug 1329996 is the main RFP meta, but not every RFP bug is reported here, and even those that are, aren't always added to it - in fact some RFP patches aren't even added to it - so it's not a tree I would 100% depend on. Some of the RFP bugs are at tor's issue tracker, but don't get upstreamed here - including your issue re dpi

Your issue is tied to these

• https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40081 - layout.css.devPixelsPerPx /
• https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40225 - system scaling

Some are old as heck and it probably needs a good clean up and old issues replicated/verified
[1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues?scope=all&utf8=✓&state=opened&label_name[]=Fingerprinting

Or did you mean we should create a RFP new-window/LBing meta bug to handle all the issues? I can probably think of a dozen or more issues right now

Comment 10

[Georg Vogt]

(In reply to :Gijs (he/him) from comment #6)

Does this still happen?

Yes, if I enable the bookmark menu "on new tabs"

If so, does it happen only to the initial window, or only new windows?

For new windows and the initial but only if it is empty (no tabs restored)

Every time, or is it a race condition of sorts / intermittent?

Yes

Are you in a position to check if it's Linux-specific?

I have this problem with 3 synced profiles: Windows, Ubuntu, Arch

Can you reproduce in a clean profile with just the fingerprint resistance pref set?

I tried but with just privacy.resistFingerprinting there is no letterboxing, I just assumed it was enabled by this
With a clean profile and privacy.resistFingerprinting together with privacy.trackingprotection.enabled there letterboxing and I can reproduce the problem

Comment 11

[:Gijs (he/him)]

(In reply to Simon Mainey from comment #9)

so I get a 1000x1001px viewport

So LB is on,

Apparently not, per comment #10? I don't know what is supposed to control letterboxing, beyond the resist fingerprinting pref... It seems weird that tracking protection influences things?

your browser window is somewhere just over 1000x1000, you load some web content (you don't need RFP on).

No, just the new tab page.

How is it being measured - what APIs ?

innerHeight/innerWidth on the window from the devtools console (which is set up to open as a separate window).

I know emilio landed a patch to allow viewport subpixels, which I asked him about, but I'm not sure if this is the cause - was this test on Nightly?

Yes.

Or did you mean we should create a RFP new-window/LBing meta bug to handle all the issues? I can probably think of a dozen or more issues right now

I think it'd be useful to collect issues via a metabug or some other mechanism, so that the knowledge of where/how it's imperfect is easily gained - it's clear you have a good overview, but it's a shame if that's mostly stored in your head - it makes it harder for other people to understand what the state of the feature is and what the plans are around it (and/or what fixes are in the "right direction" and which ones are not). :-)

Documentation of what the current implementation does would also be useful...

(In reply to georg.em.1909+firefox from comment #10)

Can you reproduce in a clean profile with just the fingerprint resistance pref set?

I tried but with just privacy.resistFingerprinting there is no letterboxing, I just assumed it was enabled by this
With a clean profile and privacy.resistFingerprinting together with privacy.trackingprotection.enabled there letterboxing and I can reproduce the problem

I'm still confused, sorry. If I try a clean profile with these two prefs, then the innerHeight and innerWidth of the about:newtab content area is 800x1000 on my mac (where I happen to test atm). Then if I load a page into the tab from the URL bar, the innerHeight is 828 (which I guess is bad?). But when opening windows, the height/width are reliably 800x1000. If I resize the window I do not see any visual letterboxing - is there supposed to be some / is there some for you?

Comment 12

[Thorin [:thorin]]

(In reply to :Gijs (he/him) from comment #11)

I'll see what I can rustle up: but in a nutshell

• RFP protects screen, available screen, and outer by reporting them as inner. We do not want to lie about the inner window for compat reasons
• RFP + LB are currently independent and do not require or affect the other's purpose
• RFP (privacy.resistFingerprinting) controls new window sizes to manipulate the inner window
  • there are bugs with toolbar present, bugs with scaling (system, css.devicePixels: dpi and zoom on window create seem fine), bugs with tiling managers
  • because it only takes action on new window creation, it does nothing for chrome changes
• LB (privacy.resistFingerprinting.letterboxing) directly controls the inner window size (not viewport) with web content (a bit handwavey here about principals)
  • it handles everything RFP doesn't as it detects chrome changes and directly protects the inner window (full screen is not protected)
  • there are edge cases that can "leak" (pre-render on new-windows/new-tabs) - there's a bug for this
  • there are edge cases with findbar (because findbar is not per tab, it's per window and affects other tabs) - there's bugs for this
  • there are maybe bugs with scaling, but so far no-one has shown me that Firefox does this, only in Tor Browser (see next point) - but I wouldn't be surprised if Firefox did
  • there's something bugwise going on with Richard's Tor Browser patch with scaling/css.devicePixels/etc
  • it doesn't protect in full-screen - there's a bug for that
  • it doesn't handle zoom changes - but we have other zoom mitigations - it's a very hard nut to crack because we can't take away accessibility features

However, inner window is not a stable metric (excluding if maximized or full-screen), but screen is, as far as fingerprinters care. So part of the problem is we have tied screen to inner, so now we have to protect the inner as if our lives depended on it. If we decoupled screen metrics, the risk is much lower. We would still want to protect inner+outer, and spoof screen+screen-available (we could use a sliding scale of 3 or 4 common resolutions depending on inner: which makes the metric unstable: i.e we still protect new windows, but if a user maximizes, it mutates). There's a ticket for that too!

What do you suggest. A google (ughh) doc, a mailing list (ughh), or should I just compile something and email you, or tom/arthur?

Comment 13

[Georg Vogt]

(In reply to :Gijs (he/him) from comment #11)

I'm still confused, sorry. If I try a clean profile with these two prefs, then the innerHeight and innerWidth of the about:newtab content area is 800x1000 on my mac (where I happen to test atm). Then if I load a page into the tab from the URL bar, the innerHeight is 828 (which I guess is bad?). But when opening windows, the height/width are reliably 800x1000.

My problem is that a new window with bookmark menu on (empty tab) is visually larger than a new window without the bookmark menu (tab with content). Because of this his visual change I checked the screen resolution with https://browserleaks.com/javascript.
And this is what I can reproduce.

If I resize the window I do not see any visual letterboxing - is there supposed to be some / is there some for you?

It I resize it manually the window is changed in the desired resolution but new windows will still get the letterboxing resolution.

Comment 14

[:Gijs (he/him)]

(In reply to Georg Vogt from comment #13)

(In reply to :Gijs (he/him) from comment #11)

I'm still confused, sorry. If I try a clean profile with these two prefs, then the innerHeight and innerWidth of the about:newtab content area is 800x1000 on my mac (where I happen to test atm). Then if I load a page into the tab from the URL bar, the innerHeight is 828 (which I guess is bad?). But when opening windows, the height/width are reliably 800x1000.

My problem is that a new window with bookmark menu on (empty tab) is visually larger

Sorry, do you mean the content area (ie just the website), or the total size of the window (including toolbars etc. ) ?

than a new window without the bookmark menu (tab with content). Because of this his visual change I checked the screen resolution with https://browserleaks.com/javascript.
And this is what I can reproduce.

If I resize the window I do not see any visual letterboxing - is there supposed to be some / is there some for you?

It I resize it manually the window is changed in the desired resolution but new windows will still get the letterboxing resolution.

Let me rephrase my question: Is there "dead space" around the content area for you, between the edge of the browser window and/or toolbar on the one hand, and the edge of the content area (website) on the other?

On the whole, I'm still confused what the problem is. Is it:

(a) that the bookmarks toolbar appearance means that the content area size calculation is off and so we end up with the "wrong" content area size immediately (which is what I originally thought the issue was)
(b) that if you switch between tabs in a window where the toolbar is/isn't visible, the content area changes?
(c) that if you open a new window with a URL directly (e.g. from a URL) vs "just" opening a new browser window (using the browser keyboard shortcut / UI), the content area size is the same but the outer window size is different
(d) something else?

Because of this confusion, I'm not sure how to debug and/or fix the issue. :-(

(In reply to Simon Mainey from comment #12)

(In reply to :Gijs (he/him) from comment #11)

I'll see what I can rustle up: but in a nutshell

Thank you for this!

• RFP protects screen, available screen, and outer by reporting them as inner. We do not want to lie about the inner window for compat reasons
• RFP + LB are currently independent and do not require or affect the other's purpose
• RFP (privacy.resistFingerprinting) controls new window sizes to manipulate the inner window
  • there are bugs with toolbar present, bugs with scaling (system, css.devicePixels: dpi and zoom on window create seem fine), bugs with tiling managers
  • because it only takes action on new window creation, it does nothing for chrome changes
• LB (privacy.resistFingerprinting.letterboxing) directly controls the inner window size (not viewport) with web content (a bit handwavey here about principals)

Georg: do you have this pref (privacy.resistFingerprinting.letterboxing) turned on?

(snip)

What do you suggest. A google (ughh) doc, a mailing list (ughh), or should I just compile something and email you, or tom/arthur?

We have in-tree docs using sphinx (sp?) and markdown! They automatically get put on https://firefox-source-docs.mozilla.org/ as HTML. It's pretty nice. If you (Simon) could file a bug and put up a patch to add to that, that would be awesome (and yay, avoids mailing list / google doc!). :-)

Comment 15

[Georg Vogt]

(In reply to :Gijs (he/him) from comment #14)

Sorry, do you mean the content area (ie just the website), or the total size of the window (including toolbars etc. ) ?

• In the empty new window with the bookmark toolbar I guess/estimate the content area is (correctly?) the same as for a window without the toolbar.
• To get this total size of the window size is increased when it is created.
• when opening a website in the empty window the bookmark toolbar disappears
• window size stays increased ⇒ content area is increased compared to other windows

To sum up I have to problems with this: Firstly it doesn't look nice if windows don't have the same size depending on how they got created (only aesthetic, not what I reported but how I came aware of this). Secondly the increased content area conflicts with the letterboxing (reported bug).

Let me rephrase my question: Is there "dead space" around the content area for you, between the edge of the browser window and/or toolbar on the one hand, and the edge of the content area (website) on the other?

No, there is no dead space. The content area is increased.

On the whole, I'm still confused what the problem is. Is it:

(a) that the bookmarks toolbar appearance means that the content area size calculation is off and so we end up with the "wrong" content area size immediately (which is what I originally thought the issue was)

I think it is not a wrong calculation but a wrong assumption: If the bookmark toolbar would not disappear, the content area would still be letterboxed, but the calculation is done for an empty tab, not for a tab with content where it would matter.

(b) that if you switch between tabs in a window where the toolbar is/isn't visible, the content area changes?

The bookmark is only visible on empty tabs so I compare a window that was created with the toolbar visible, but now has content loaded so the toolbar is no longer visible, and a window that was created without the toolbar visible.
They have different size/shape and a differently sized content area.

(c) that if you open a new window with a URL directly (e.g. from a URL) vs "just" opening a new browser window (using the browser keyboard shortcut / UI), the content area size is the same but the outer window size is different

No, both are different

Georg: do you have this pref (privacy.resistFingerprinting.letterboxing) turned on?

I don't have this key created/it is not visible in about:config, so I guess it is implicitly turned on by some other pref.

Comment 16

[Thorin [:thorin]]

^^ letterboxing is not turned on (Georg: it is not set by anything else: if the pref does not exist in about:config then it is not being used)

STR

• Turn on RFP, do not turn on LBing, set bookmark toolbar only on new tabs, close, reopen
• the new tab is activity stream, the toolbar shows
  • note: there is no session restore in my test (someone else can test that: not relevant for Tor Browser)
  • note: IDK what happens with moz-extension:// pages like speed dials that replace the home-page, new-windows or indeed custom new-tabs
• load a webpage like https://arkenfox.github.io/TZP/tzp.html .. the toolbar vanishes, the size is now the original size (e.g. 1000x1000) + the toolbar height: e.g. for me it went from 1000 height to 1028 - therefore my toolbar height is 28px. You can just check by toggling the toolbar on/off (TZP updates in real time)
• NOW turn on LBing .. the inner size is protected (in my case, I get a 14px top and bottom letterbox matte)

That's what OP is saying: that the size does not conform to protected new window rounding. But it's no different really to a user manually toggling the bookmarks toolbar, or the menubar, or flipping the sidebar open or manually resizing .... LB is designed for this. Except that it's worse because the user didn't manually do anything, but leaked a different size. LB is not tied to RFP (and in Tor Browser a lot of users just cannot adapt to margins, so they disable it) - which means with the visibility set to newtab, they would not have a rounded window (bugs aside), instead it would be rounded + toolbar height: and variation in that from density, OS, and themes is quite wide = more buckets = entropy = not a good outcome

Notes

browser.toolbars.bookmarks.visibility can be always, newtab or never. Lets say you detect never or newtab and open at a toolbar-less height i.e 28px less height (in my case) to accommodate the toolbar missing on new tabs with web content: that looks good: until someone toggles the toolbar on permanently (ctrl-shift-b): now all open tabs in that window are compromised: With LBing, instead of a 28px letterbox (in my case), it's now 72px (and 100px less real estate used in height for displaying content). Without LBing, toolbar heights can still be detected

Either way you slice it, you're leaking extra entropy

Solutions

• A) mostly solved (less some aesthetics) by enforcing LBing with RFP (but I think this might be a deterrence to uptake when/if RFP is exposed), and if/when inner is decoupled from screen (one day) then it's not strictly necessary (instead it LBing could be a slider item for safer or higher)
• B) treat newtab as always when RFP = true: i.e the user wants it to show at some stage, so they use it, therefore treat it as always on. I think this is the answer

If you took solution B, can you get the pref value earlier enough, and can it handle session restore and extension pages?

Comment 17

[:Gijs (he/him)]

This is now enabled in 85 and above, fixing flags.

I need to come back to Simon's comment and figure out what we want to do - I suspect just not offering the "only on the new tab page" functionality as suggested there might be best, but I haven't had time to think about it much - been too busy with other stuff.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

For more information, please visit auto_nag documentation.