Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

override RFP new window sizes #1286

Closed
Thorin-Oakenpants opened this issue Dec 2, 2021 · 4 comments
Closed

override RFP new window sizes #1286

Thorin-Oakenpants opened this issue Dec 2, 2021 · 4 comments

Comments

@Thorin-Oakenpants
Copy link
Contributor

Thorin-Oakenpants commented Dec 2, 2021

here's an override recipe

🔻 RFP users: allow bigger default sizes for on startup and for new windows

/* override-recipe: desktop: alter new window max sizes **/
user_pref("privacy.window.maxInnerWidth", 1600); // 4502
user_pref("privacy.window.maxInnerHeight", 900);

I doubt many, if any, FF users stick to a 1000 x 1000 max inner window on desktop. It's not very usable: mobile pages often like to use 1024 width as a trigger point, and regardless of that you can end up with horizontal scrollbars, including in FF's own internal pages

for RFP users

  • we are not Tor Browser and AF has never claimed to defeat advanced FPing - despite what ignorant peacocks say
  • we don't want users abandoning RFP over something so trivial to fix, as RFP is our preferred robust built-browser solution that also covers timing mitigations
    • there is a study somewhere that this was the biggest usability issue that caused users to disable RFP: real estate
  • regardless of not claiming to defeat advanced FPing scripts, we are not removing the protection
    • sizes are still rounded in buckets (most change will only be width)
    • there is still a default max
    • letterboxing is still on by default
  • a larger newin (assuming not edge case bugs like tiling managers) can also discourage resizing and help eliminate LB margins showing - thanks @fxbrit below

AF is aimed at desktop

  • FYI: newwin RFP sizes aren't used on android
  • desktops/laptops are more than likely to be at least 16/9'ish
  • it is the aspect ratio that is most important: size is affected by a number of factors: such as zoom, system scaling, layout.css.devPixelsPerPx
  • but we can also pick a useful size: 1600 x900 is a good balance
    • > 1920 x 1080 = we'd all be the same
    • at 1920x1080, you might lose 100px height but you will gain 600 width
    • <= 1600 x 900 and under will simple open as large as possible - effective adding only width
    • users can still choose a bigger override

Class discuss!

edited: to simplify the reasons

@Thorin-Oakenpants
Copy link
Contributor Author

@ everyone - I'm going to need some feedback and stories on what you all do/use, thanks

@fxbrit, what does LW do? Would you set the prefs and add then to the LW tab settings?

@fxbrit
Copy link
Collaborator

fxbrit commented Dec 3, 2021

what does LW do?

currently, nothing, we stick to 1000x1000. it seems reasonable to consider this imo.

edit: LW is now in line with arkenfox.

this change should also make letterboxing more tolerable as there's no need to resize manually, which might result in ugly borders.

on anything 1600x900 or lower, it will just open as large as it can

this is the biggest selling point imo, and we still get to keep the rounded values. in the end the goal with inner window isn't to spoof everyone to the same exact resolution, as much as it is to protect the real value.

@specter78
Copy link

specter78 commented Dec 4, 2021

I don't think your above change will help improve privacy. 1000x1000 was chosen as standard by tor for both windows and mac to ensure uniformity.

Now, if you'll change the resolution to 1600x900, the user will be somewhere in between 1000x1000 and native screen resolution and this can be an easy way to fingerprint.

Generally windows laptops have 1920x1080 resolution, so going with 1600x900 is still close. However, on mac, standard resolutions are much larger, 2560 × 1600, and this will make the user really stand out.

So I would rather suggest keeping the same, or changing them to native screen resolution (if that's possible) -- in between the two, I'd prefer native resolution. I suppose many users use RFP pref but use browser at native resolution, so this can allow AF users to blend in with them.

@Thorin-Oakenpants
Copy link
Contributor Author

I don't think your above change will help improve privacy

Read OP - it is not meant to, it is about letting users have more real estate and usability

1000x1000 was chosen as standard by tor for both windows and mac to ensure uniformity.

No it wasn't. And what about linux? It was chosen due to screen resolutions, not platforms

this can be an easy way to fingerprint

we're not protecting the fingerprint, see my first point about reading OP. I also disagree with your assessment for example

  • However, on mac, standard resolutions are much larger, 2560 × 1600, and this will make the user really stand out
  • me: and how does 1000x1000 not already make you stand out on Firefox

once again, this is not about protecting the FP, it is about working around the limited small window sizes - users are going to increase it anyway

changing them to native screen resolution (if that's possible)

that can't work, it rounds to 200s width by 100s height and even then because it uses as much res as possible and things like chrome and taskbars AND system scaling etc all affect things, you will never get this to work. In terms of how you protect a metric like this, it is not what is common, it only matters that all users form as few buckets as possible

  • but that's not what we're doing here: it is as a side effect of RFP - we are not trying to protect the FP and we are not TB

I suppose many users use RFP pref but use browser at native resolution

don't guess, use math. system scaling affects this, so you're going to have 4k res at 150%, and 2156x1440 at 133% and so on. Math says, simply create as few buckets as possible. I'm saying lets use 16/9 as a very common aspect ratio to get some usage - not to protect anything

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants