1803268 - regression: RFP navigator spoof fails in initial about:blank iframes

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Simon Mainey]

Attachment: iframediff.png

Regression from Bug 1799435

STR

• use an OS that does not match the spoof (e.g Win 7: spoof is Win10)
• go to about:config and change privacy.resistFingerprinting to true
• load https://arkenfox.github.io/TZP/tzp.html#useragent
• click the iframe diffs
• see pic: the OS version spoof is not applied

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Wrong ni? presumably?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Can you be more specific on where do I need to click to get those logs? Or even better attach a reduced test-case that shows the issue?

Comment 3

[Simon Mainey]

the output is in the console (from clicking [diff]), and all seven iframe methods fail - the diffs are compared to the values shown above. But nvm ... here's a simplified test with just a single nested iframe, returning four screen/window metrics - https://arkenfox.github.io/TZP/tests/screeniframe.html

RFP will make screen, available screen, and outer == inner (just don't be full screen to test it). It fails to do so in the iframe. All output on the test page. Is this enough to go on?

This is now live in stable (107.1) :-( and I suspect most if not all RFP protections are not being applied in iframes

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1803268 - Compute should resist fingerprinting on Document::Init. r=smaug

So that it returns the right answer on initial about:blank.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1803268 - Minor clean-up in nsScreen::ShouldResistFingerprinting(). r=smaug

This doesn't change behavior but it's cleaner, and while I was near that
code...

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6560bda24ee9
Compute should resist fingerprinting on Document::Init. r=smaug

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f0c113aee645
Minor clean-up in nsScreen::ShouldResistFingerprinting(). r=smaug

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/6560bda24ee9
https://hg.mozilla.org/mozilla-central/rev/f0c113aee645

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9306078 [details]
Bug 1803268 - Compute should resist fingerprinting on Document::Init. r=smaug

Beta/Release Uplift Approval Request

• User impact if declined: comment 0
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): one-liner + test
• String changes made/needed: none
• Is Android affected?: Yes

Comment 10

[Dianna Smith [:diannaS]]

Comment on attachment 9306078 [details]
Bug 1803268 - Compute should resist fingerprinting on Document::Init. r=smaug

Approved for 108.0b9

Comment 11

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/c8001afe2852

Comment 12

[Catalin Sasca, Desktop QA [:csasca]]

I was able to reproduce the issue with Firefox 109.0a1 (2022-11-29) on Windows 7 by following the STR provided in Comment 0.

The issue is fixed and the iframes matches on Firefox 108.0b9 and Firefox 109.0a1 (2022-12-04) under the same system.