Closed Bug 1954194 Opened 5 months ago Closed 3 months ago

Make screen.availWidth/height report screen resolution

Categories

(Core :: Privacy: Anti-Tracking, enhancement)

Product:
Core
Component:
Privacy: Anti-Tracking
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
140 Branch
Tracking Flags:
Tracking Status
firefox140 --- fixed

People

(Reporter: tjr, Assigned: fkilic)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Bug 1954194 - Introduce RFPTarget::ScreenAvailToResolution to spoof avail screen size to screen size. r?tjr
48 bytes, text/x-phabricator-request
Details | Review

screen.availWidth and availHeight report the difference between your screen resolution and the available space for the browser window (including its chrome) to take up. i.e. it reports your taskbar or dock height. We know that having availWidth = screen resolution isn't uncommon or considered a hack - auto-hiding taskbars on Windows (which I swear at once point in time were all the rage) already do this.

Currently we have an RFPTarget that affects ScreenAvail (as well as Window Inner, Outer, and Screen Resolution, plus posX and posY and maybe a couple others) - but that target pins ScreenAvail to the WindowInner size. We're going to introduce a pref that pins ScreenAvail to the ScreenResolution.

Because in RFP all targets are enabled, we have to choose which target will take precedence, and we will replicate whatever Tor Browser chooses to do. (They are currently landing and uplifting their own changes here, but we can manage them both being in-flight at the same time. The second patchset to land will just be rebased on top of the first and ensure Tor's behavior is respected.)

Blocks: fpp2

I don't think you should do it like this. You should report available as screen minus a constant per OS (as the OS's default) - by default desktops do not hide taskbar/docker, and on mac (IIUIC) you can't hide it. I honestly think you could just follow TB's patch minus setting a screen size. This also takes care of the outer measurement (including handling fullscreenElement and DisplayMode fullscreen).

Hmm so the thing is, we want to enable this for everyone, not just fingerprinting protection users. If a user doesn't specifically toggle ETP for a page, this protection should be always on.

I could be wrong, but I think we strictly want to hide dimensions of OS related stuff, not browser. So we don't need to lie about css size, outer size etc.

We haven't considered using a constant. It makes sense for possible bot detection issues actually. I'll ni Tom.

Flags: needinfo?(tom)

Hmm so the thing is, we want to enable this for everyone, not just fingerprinting protection users

screen - available = entropy | outer - inner = entropy (menu bar, theme density, toolbar, sidebar, etc). In the past using valid but "unusual" (less common) values always comes back to bite us (I can see scripts using this as counting towards penalizing the user). Hence why we should IMO use realistic/common values.

TB's patch fixes both and neither have anything to do with website rendering etc, and in fact both are very hard (if not impossible) to detect as "lies". In reality they (both) do change with zoom but it's not linear - TB's patch ignores this. So we went with the default chrome constants per OS, same logic as going with default taskbar/docker constants per OS. Android for us we left as everything = inner, so you might want to think what you're doing there.

FWIW: Brave also does this but most likely because they wanted to randomize it

This is totally fine for everyone. There's also an issue somewhere about returning 0 for co-ordinates for all users and even nudging it upstream for a spec change, but I can't find it

  • found it ... Bug 1579584 which is about outer but mentions co-ordinates

edit: typo: add a 1 to 579584

screen - available = entropy | outer - inner = entropy

Yeah I agree with this too. It is just we haven't proposed/considered spoofing outer sizes for every user.

In the past using valid but "unusual" (less common) values always comes back to bite us (I can see scripts using this as counting towards penalizing the user). Hence why we should IMO use realistic/common values.

Also agree with this one. I'm not sure which site it was, it was a hotel booking site or something and lying about one of the screen properties actually caused ff to be detected as a bot. I'm not sure if it was avail size though.

nvm found it, it was bug 1885101 and it was caused by WindowOuterSize, not avail, which kind of makes sense. Our hope is that, there are many (obviously not the majority but still lots of) people that use hidden taskbar on windows for example, and in that case avail == screen resolution. So from a bot detection perspective it isn't very reliable. Outer size makes sense though, because if outer size is equal to inner size, then there's a change you are running a headless browser.

Anyway, these are just my thoughts, I'll let others (tom and you) decide.

(In reply to Fatih Kilic [:fkilic] from comment #7)

Yeah I agree with this too. It is just we haven't proposed/considered spoofing outer sizes for every user.

Well, let me re-present to you Bug 1579584 specifically for all users to spoof outer :) TB's patch will do that for you, just saying :)

So after thinking about it for a bit, I think you're right Thorin, that it would be better to report a constant offset. I am a little concerned about potentially reporting an Outer Window Size that is larger than Available Window Size; but that is a thing that happens, your window can be underneath your taskbar.

I went looking at the data to figure out what the best offset was, and figured out that our screen reporting metrics might be off in a few ways, so we're going to fix those and then figure it out.

Flags: needinfo?(tom)

reporting an Outer Window Size that is larger than Available Window Size

Without re-rechecking-yet-again what we've done in the TB patch, this should be impossible (for us), as in the TB patch we spoof the screen size (so it always fits unless it can't at 8k) but you're not doing that here. So for you it should be fairly rare IMO (unless the user actually has resized their outer to be bigger by dragging it below and then resizing upwards for example)

  • first: we cater for fullscreen: fullScreenElement and F11 (displayMode:fullScreen): where outer == inner
  • second, our constants are default OS: normal density, toolbar hidden, menu bar off e.g. on windows, etc: so fairly slim
    • i.e is someone is different they "added" chrome which shrinks their possible inner which makes it less likely for outer to exceed available (if you can follow that logic)

The problem (for you) comes when users "remove" used real estate: e.g. changing to vertical tabs or having a hidden taskbar

  • i.e the available space for their inner becomes higher
  • this sort of thing is very likely to be more problematic and exposed with tiling

The answer to solve it of course, is to spoof the screen size - Brave does it and it doesn't seem to break anything :) So add that to fpp3

PS: using constants also means we could one day randomize them should we think it worthy especially available and outer as they are almost impossible to check :)

Okay, data.

  • Unsurprisingly, we will make the available width = actual width. On Darwin/Linux that matches about 95% of users, on Windows it's like 99%
  • Windows, for height, 48px is the most common value with ~30% of users, and 70% of users are 48px or less. A value of 60px adds about 15% and a value of 72 adds another 7.5%. I think the value to go with here is 48px.
  • Mac it is a lot less uniform. Values of 25px, 50px, and 76px are all more common values, but only account for ~ 40% of users. Everyone else is very uniformly spread over 55-75, and 77-304px. I'll say let's go with 76px.
  • Linux is not quite as bad - 65% of people report 0, and then values 28-95ish make up for about 33% of users spread fairly evenly, with the remainder of users in the 1-27 or 96+ range. It seems like the answer is 0px.

It would be beneficial for TB and FF to use the same constants: we currently have

  • 48 height for windows
    • this is system scaling 100% (devicePixelRatio is 1) and default windows 11
  • 32 height for linux
    • based on anecdotal data - we should change to 0 to match your data
  • 110 height for mac
    • this is the menu bar (25px) + dock (85px) on my desktop mac at retina (dpr = 2)
    • the dock can be auto-hidden which I suspect is why there are lower values of e.g. 25 and 50 and 76
    • variation is also due to devicePixelRatio (dpi/system scaling/zoom)
      • I know mac ship at 2, 2.5 and 3 - add system scaling (esp laptops) (and I assume data is not tainted by zoom) - but I am still surprised by the wide range
    • open to suggestions @pierov
      • seems 40% are [25, 50, 76] and another 20-30?% (you said uniformly spread but that's a big range) are 55-75px
      • so my best guess is at least half of users are auto-hiding the dock
      • 76 is such a weird number: AFAICT the menu bar cannot be hidden and 76 seems low for the dock. I wish I knew more

What is the mac breakdown of 25, 50 and 76 - is it uniform? Our DPR is spoofed at 2, so for RFP I'm inclined to go with 25

What is the mac breakdown of 25, 50 and 76 - is it uniform? Our DPR is spoofed at 2, so for RFP I'm inclined to go with 25

  • 25 is ~ 11.5%
  • 50 is ~ 17%
  • 76 is ~ 15%

I'm not sure if it will make a difference, but this is based on only US users at the moment.

still can't work out how there is such a large range of values: I can replicate 25px for menubar .. but 76? weird. I even changed screen resolutions on my mac and it stays the same (110 overall, 12 being menubar). Edit: Must be zoom - since we follow css pixels not device pixels?

Pushed by tritter@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0548f8848318 Introduce RFPTarget::ScreenAvailToResolution to spoof avail screen size to screen size. r=tjr

https://hg.mozilla.org/mozilla-central/rev/0548f8848318

Status: NEW → RESOLVED
Closed: 3 months ago
status-firefox140: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 140 Branch

I have some questions about this patch!

  1. Why check also for RFPTarget::ScreenAvailRect? Or, why have two different targets? That's what I'd do for Bug 1591337 (apologies for not having sent a patch yet, it's ready, except for tests, which are kinda hard to get right)
    2.Shouldn't the function check for (element) fullscreen, and avoid adding the offsets in that case? I.e., return the inner window, which will already be the fullscreen size
Flags: needinfo?(fkilic)

I can answer one:

  1. Why check also for RFPTarget::ScreenAvailRect? Or, why have two different targets? That's what I'd do for Bug 1591337 (apologies for not having sent a patch yet, it's ready, except for tests, which are kinda hard to get right)

Tor decides what RFP does. If Mozilla wants to do something different from you, we need a different target we can enable; and we make sure that your behavior has precedence when all targets (RFP) are enabled.

  1. Tom is right. We didn't intend this patch for Tor, but for Firefox only.

2.Shouldn't the function check for (element) fullscreen, and avoid adding the offsets in that case?

We are only spoofing avail(Width/Height). Should avail(Width/Height) change with fullscreen?

Oh I guess it changes on windows because it hides the start menu
It looks like it also changes on macOS (by 6pixels on my machine, though it would proably be more if I didn't have auto-hidden menu bar enabled)

I.e., return the inner window, which will already be the fullscreen size

On my machine, innerHeight is 1126 when a video/element is in fullscreen, and 1086 when firefox is in fullscreen, and 1085 when it isn't fullscreen. I wonder how this changes between platforms. I do think returning inner window sizes is a good idea though, because what else can we return? (assuming we don't define a set of height offsets for fullscreen and use them when fullscreen is true)

I'll create a new bug for this. edit: created bug 1966184

QA Whiteboard: [qa-triage-done-c141/b140]

FYI: interestingly enough, which I did not expect, is that the value respects devicePixelRatio AFAICT (zoom affects it, so I assume the rest such as system scaling as well). This is nice IMO as it now reflects what a non-"spoofed" value would report and you can't hide the real devicePixelRatio anyway (and FPP is not trying to do that regardless). Not sure if this was as planned. I had the impression that the value was static, but this is better :)

Will have to think of how this manifests in Tor Browser, where we (will) have hard-coded static/stepped screen sizes and we spoof the devicePixelRatio (but do not hide zoom, but do reset zoom)

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

Attachment

General

Creator:
Created:
Updated:
Size: