Open Bug 1591337 Opened 3 months ago Updated 2 months ago

RFP screen spoofs: step common spoofs based on inner window

Categories

(Core :: Window Management, enhancement, P3)

68 Branch
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: simon.mainey, Unassigned)

Details

(Whiteboard: [fingerprinting])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

  • This is for desktop
  • Not sure how this would fit into Android: in which case we leave Android as status quo
  • We do not lie about the inner window for compat/usability/breakage
  • We currently spoof non-chrome (screen metrics) to the inner window: e.g screen, available screen, various @media screen info
  • Fingerprinting likes stability, and most scripts in the wild (check with OpenWMP) don't bother with chrome measurements AFAICT. Most scripts are copypasta drop-ins like fingerprintjs2
  • Just like we step letterboxing based on inner window, step screen spoofs based on the inner window
  • But instead of using the actual inner window value, use a very limited number of common screen resolutions (always reporting the next one higher than the inner window)
  • Just like we treat HTTP header UA differently to navigator JS properties re OS, let's treat screen metrics differently to chrome metrics

Actual results:

Currently for screen metrics

  • RFP users can return hundreds of different screen results due to the fact that the inner window can change (letterboxing helps: but it's still a lot of buckets)
    • resizing manually, toggling chrome changes (bookmark toolbar, sidebar, etc)
  • RFP users without letterboxing: on new windows can return dozens of buckets due to various quirks/bugs
    • desktop environments on linux
    • DPI settings
    • bookmark toolbar showing
    • bookmark toolbar density (and even themes) affects this
    • bookmark toolbar per OS also makes a difference
    • available screen res on lower res devices
  • RFP users with letterboxing: on new windows can still return some buckets: that is 100px height steps from 1000px down
  • Zoom affects screen metrics: this is a byproduct from our implementation

Expected results:

What I would expect to see is

  • 99% (even if it was 50% it's an improvement) of scripts in the wild would only ever get whatever we limit the buckets to (as long as we have the highest res covered): because all they check is screen metrics
  • ^^ zooming wouldn't affect those scripts <-- this is important
  • inner window metrics if anyone checks is still covered: we don't change anything there
  • results are more plausible and more blending in with the general population is never a bad thing
  • might solve some compat issues?
Component: Untriaged → Window Management
Product: Firefox → Core

If I understand correctly, you're saying: get the most common screen resolutions (let's say they're 800 x 600 and 1080 x 1920) and report whichever is the smallest that is still larger than the current letterboxed resolution?

I suppose the goal of this is to make the screen resolution report something more common for people using RFP so they look a little less unusual? ("Who's this person with a screen resolution of 620 x 960?")

However, what do we do for extremely high or low resolution situations? Especially when one of those is in one dimension? e.g. if your letterbox size is 5000px x 800px? Or 300px x 75px?

So my thinking is this is for desktop only, which should eliminate most really small screens

  • Everything is spoofed as landscape (which we already try to do)
  • We have say a set of four screen resolutions spoofs: e.g. 1366x768, 1920x1080, 2560x1440, and 4K.
  • RFP new window size kicks in e.g 1000x600 -> spoof as 1366x768
  • RFP new window size kicks in e.g 1000x1000 -> spoof as 1920x1080 <-- if all these users don't change the browser, they stay in the most common bucket
  • user resizes window - step appropriately e.g user wants HD res video, goes full screen, we report "at least" his res

What I just thought about was multiple windows, and I don't know if you can spoof per window. But if we can separate screen from inner window, we can really get the entropy down, and eliminate zoom as a factor. And I don't know the ramifications/quirks of spoofing too high a res on a smaller device

(In reply to Tom Ritter [:tjr] (needinfo for responses to sec-[approval/ratings/advisories/cve's]) from comment #1)

I suppose the goal of this is to make the screen resolution report something more common for people using RFP so they look a little less unusual? ("Who's this person with a screen resolution of 620 x 960?")

No. It is to decouple zoom and other inner window changes from screen metrics (most scripts only grab screen): which allows us to dictate the number of buckets. We don't have to use common spoofs, as long as all RFP users stick to the same spoofs: it just makes sense to use common ones.

Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.