https://www.hyatt.com and other websites fail to load when `brave://flags#brave-block-screen-fingerprinting` is enabled

Description

Looks like we have a webcompat bug where certain websites fail to load when brave://flags#brave-block-screen-fingerprinting is enabled. Originally reported by @ryanbr and confirmed by @pes10k & @arthuredelstein. It was decided to rollback the BraveBlockScreenFingerprinting study on all the channels as per https://github.com/brave/brave-variations/pull/473 until we know what’s causing the issue.

The strange part that we need to figure out is why the issue occurs even when disabling Brave Shields or disabling FP.

Steps to Reproduce

1. launch brave (used 1.48.10 Chromium: 108.0.5359.48 in this case)
2. enable brave://flags#brave-block-screen-fingerprinting (need to use brave://flags as we rolled back the changes via Griffin)
3. restart the browser once brave://flags#brave-block-screen-fingerprinting has been enabled
4. attempt to load https://www.hyatt.com and you’ll notice that the page is completely blank

There’s also more QA verification notes via https://github.com/brave/brave-variations/pull/472#issuecomment-1329710539.

Actual result:

Expected result:

Reproduces how often:

100% reproducible when using the STR/Cases outlined above

Brave version (brave://version info)

Brave | 1.48.10 Chromium: 108.0.5359.48 (Official Build) nightly (64-bit)
-- | --
Revision | 18ceeca0d99318e70c00d2e04d88aa55488b5c63-refs/branch-heads/5359@{#854}
OS | Windows 11 Version 22H2 (Build 22621.819)

Brave | 1.47.104 Chromium: 108.0.5359.48 (Official Build) beta (64-bit)
-- | --
Revision | 18ceeca0d99318e70c00d2e04d88aa55488b5c63-refs/branch-heads/5359@{#854}
OS | Windows 11 Version 22H2 (Build 22621.819)

Brave | 1.45.133 Chromium: 107.0.5304.141 (Official Build) (64-bit)
-- | --
Revision | cddb1ab381a982f400a57e15e14080e1aaaca4b8-refs/branch-heads/5304_105@{#3}
OS | Windows 11 Version 22H2 (Build 22621.819)

Version/Channel Information:

• Can you reproduce this issue with the current release? Yes
• Can you reproduce this issue with the beta channel? Yes
• Can you reproduce this issue with the nightly channel? Yes

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? N/A
• Does the issue resolve itself when disabling Brave Rewards? N/A
• Is the issue reproducible on the latest version of Chrome? N/A

Miscellaneous Information:

[arthuredelstein]

I have tracked down the problem to the value of outer[Width|Height in iframes. In the farbling screen protection, we spoof outer[Width|Height] to inner[Width|Height] for iframes. For example, in a document with innerWidth = 100 containing an iframe with innerWidth = 20, we return an outerWidth value for the document near 100 and an outerWidth value for the iframe near 20. It appears that a bot-detection script on these websites notices that outer[Width|Height] for the iframe does not match outer[Width|Height] for the top-level document and therefore decides to reject the visitor.

I found I can fix this problem on both websites (hyatt.com and realestate.com.au) by changing the farbling code to return a value for outer[Width|Height] in the iframe that matches inner[Width|Height] of the top-level document rather than the iframe. So, in our example, in a document with innerWidth = 100 containing an iframe with innerWidth = 20, we will return an outerWidth for both the top-level document and iframe near 100.

(I’m working on a PR that incorporates this fix.)

[GeetaSarvadnya]

Verification PASSED on

Brave | 1.46.141 Chromium: 108.0.5359.99 (Official Build) (64-bit)
-- | --
Revision | 410951fc34bb4b2cbf182231f9f779efaafaf682-refs/branch-heads/5359_71@{#9}
OS | Windows 10 Version 21H2 (Build 19044.2251)

• ensured that https://www.hyatt.com loads without issues when brave://flags#brave-block-screen-fingerprinting enabled
• ensured that https://www.realestate.com.au/buy/in-melbourne,+vic+3000/list-1 loads without issues when brave://flags#brave-block-screen-fingerprinting enabled

Example	Example

Example	Example