Website Security Challenges (A type of captcha) are always very small square boxes instead of their intended size

[AutonomousCat]

This is noticeable on Linkedin and Microsoft signin.

[ave9858]

Can reproduce with normal Firefox + privacy.resistFingerprinting enabled

[Thorin-Oakenpants]

what version of MB? 12.5 or 13?

[ave9858]

what version of MB? 12.5 or 13?

I reproduced with 13, and I remember it being an issue for the previous versions too.

[Thorin-Oakenpants]

Ok, that rules rules out the devicePixelRatio change in TB/MB. I don't have a LinkedIn or MS account to test: in FF we can use RFPTargets to determine the culprit.

What is your devicePixelRatio? In Firefox without RFP, open the console and type window.devicePixelRatio

[ave9858]

I don't have a LinkedIn or MS account to test

This captcha appears during the Microsoft account creation process, you can just try to create an account with random info. The captcha will appear before the account is actually created.

What is your devicePixelRatio? In Firefox without RFP, open the console and type window.devicePixelRatio

1.5

[Thorin-Oakenpants]

ok, if I get time, I'll have a play

in FF you disable RFP, enable FPP (fingerprint protection) and instead enable all targets but then remove one (or some)

• https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/RFPTargets.inc

something like this

• privacy.resistFingerprinting = false (otherwise FPP will be ignored)
• privacy.fingerprintingProtection = true (FPP in all windows: normal + pbmode)
• privacy.fingerprintingProtection.overrides = +AllTargets,-WindowDevicePixelRatio
  • or you could use -AllTargets,+WindowDevicePixelRatio

you can of course change the last item in overrides, or add more by just appending them, comma delimited (e.g. +AllTargets,-something,-anotherthing). Most RFPTargets are calculated on page load - i.e just reload the site, but for good measure, when testing anything I always close existing tabs and use a new one, or even better I close and restart FF

I haven't gotten around to testing RFPTargets yet, and it's a work-in-progress - but it should be workable in stable FF at least to diagnose - I have seen bugzillas from months ago using it to find the culprit(s)

Feel free to experiment on your weekend :)

[ave9858]

+AllTargets,-ScreenRect results in no issue, -AllTargets,+ScreenRect results in the issue. Tested with 118.0.2, normal Firefox on Windows.

[ave9858]

Workaround: Open dev tools -> Inspector, search for the enforcementFrame iframe, change the style from "height: 100px; width: 100px;" to high values like "height: 1000px; width: 1000px;". The captcha won't be cropped after the change.

[Thorin-Oakenpants]

hmm, that's confusing (for me) ... i assume ScreenRect is returning screen width+ height the same as the inner window (or viewport if letterboxing is on) - never heard of that causing an issue with actual web content

https://searchfox.org/mozilla-central/source/dom/base/nsScreen.cpp#85

cc @tomrittervg

[Thorin-Oakenpants]

FYI: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41747

been saying for 3 years we need to "decouple" screen from window (still base screen on window though, just not the same)

[tomrittervg]

Yes, ScreenRect is only used for screen.[top, left, widfth, height], window.moveTo, and window.moveBy.

It would be great if this could also get filed on Bugzilla for us to investigate when we are able to.