1684230 - Resist Fingerprinting breaks WebGL Peaks of Austria site because RFP's max texture size is too small

Status: ASSIGNED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Kevin Locke]

Attachment: Screenshot of garbled rendering.

Visiting the "Peaks of Austria" page at https://felixpalmer.github.io/peaks-of-austria with privacy.resistFingerprinting=true results in a confused/broken rendering, as shown in the attached screenshot produced using:

mozregression --pref privacy.resistFingerprinting:true -a https://felixpalmer.github.io/peaks-of-austria

The issue appears on Firefox 84.0 and current nightlies. Both tested on Debian testing with Intel 3rd Gen Core processor graphics.

The website source is available at https://github.com/felixpalmer/peaks-of-austria I have not reached out to the author yet, but would be willing to do so if that would be helpful.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

Still reproduces on Linux / NVIDIA proprietary / current Nightly 95.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

I'm guessing this is because of

Blocked https://felixpalmer.github.io/peaks-of-austria/ from extracting canvas data because no user input was detected. procedural-gl.js:41474:27

So I think this is expected.

Comment 3

[Thorin [:thorin]]

When you load https://felixpalmer.github.io/peaks-of-austria/ you will see a canvas icon in the urlbar, you can click this and allow (or allow for session by unchecking Remember this decision

Can probably be duped to Bug 1631673 which is a bit of a think tank on this problem

• we reduced prompt fatigue with privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts
• now as more site use canvas, the lack of education on RFP (it is not front facing) and the silent breakage is becoming more problematic
• possibly auto-allowing per eTLD+1 per session after a user-gesture (which is problematic as eliciting a gesture is not hard)

tom? dupe to Bug 1631673

Comment 4

[Kevin Locke]

Attachment: Screenshot showing rendering issue and allow canvas extraction dialog

Thanks all for weighing in on this issue!

(In reply to Simon Mainey from comment #3)

When you load https://felixpalmer.github.io/peaks-of-austria/ you will see a canvas icon in the urlbar, you can click this and allow (or allow for session by unchecking Remember this decision

I gave this a shot with 95.0a1 (2021-10-07) (64-bit) launched via mozregression:

mozregression --pref privacy.resistFingerprinting:true -a https://felixpalmer.github.io/peaks-of-austria --launch 2021-10-07

After clicking Allow (and force-reloading) the rendering is still broken for me. (Screenshot attached.) Without --pref privacy.resistFingerprinting:true it renders correctly with 95.0a1 (2021-10-07) (64-bit).

Comment 5

[Thorin [:thorin]]

I have to admit I didn't actually test it, sorry ... however, I don't think that's RFP ... I see console errors galore (also on Nightly 95)

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://maps1.wien.gv.........

Comment 6

[Kevin Locke]

(In reply to Simon Mainey from comment #5)

I have to admit I didn't actually test it, sorry ... however, I don't think that's RFP ... I see console errors galore (also on Nightly 95)

No worries, still a good suggestion. I don't mind doing the testing. I am also seeing the "Cross-Origin Request Blocked" console errors, but the site works for me with mozregression -a https://felixpalmer.github.io/peaks-of-austria --launch 2021-10-07 in spite of the errors and not with --pref privacy.resistFingerprinting:true. Are you seeing different behavior? What makes you think it's not RFP?

Comment 7

[Thorin [:thorin]]

Attachment: console.png

Are you seeing different behavior? What makes you think it's not RFP?

I was being lazy and making you do the testing :) Sorry, not sorry :) I see the same as you. Here are the console errors

• left: RFP is on with a canvas exception, force reload
• right: RFP is off

IDK why the code thinks the image is now too big to be supported? I see the waypoints, and can move around, there's just no imagery

Comment 8

[Kevin Locke]

(In reply to Simon Mainey from comment #7)

IDK why the code thinks the image is now too big to be supported?

Good catch! I should have looked more closely at the error messages. It looks like this is the result of the RFP analog (Bug 1217290) of "WebGL Minimal-Capabilities Mode" (Bug 686732) which defines the maximum texture size as 2048. See: https://hg.mozilla.org/mozilla-central/rev/61d074cfdeaf#l3.36

So this appears to be working as intended. Feel free to close or track as appropriate.

Comment 9

[Thorin [:thorin]]

for the record, this can be reproduced as far back as FF60 (I didn't go back any further: just spot checked 78, 68, 60). Bug 967895 was added in FF58 and Bug 1217290 & Bug 1409677 were in FF57, I suspect it's one of the latter two

Comment 10

[Thorin [:thorin]]

what timing, I was hunting thru the bugs trying to find the RFP webgl ones, you bet me to it

Comment 11

[Kevin Locke]

Great timing! Thanks again Simon.

For reference, now that we know what's going on, I opened an issue to let the site developer know: https://github.com/felixpalmer/peaks-of-austria/issues/1

Comment 12

[Thorin [:thorin]]

Six years is a long time - https://bugzilla.mozilla.org/show_bug.cgi?id=1217290#c2 .. perhaps 2048 is too low these days for a minimum

[1] https://www.khronos.org/registry/webgl/specs/latest/1.0/
[2] https://www.khronos.org/registry/webgl/specs/latest/2.0/

Comment 13

[Tom Ritter [:tjr] (OOTO until 7/21)]

We could probably update the constants here.

Comment 15

[sworddragon2]

(In reply to Thorin [:thorin] from comment #12)

Six years is a long time - https://bugzilla.mozilla.org/show_bug.cgi?id=1217290#c2 .. perhaps 2048 is too low these days for a minimum

I guess there is a reason why we stick to 2048 with RFP enabled and didn't increase it yet.

Roughly estimated from my own observation 75% of the games on itch.io show now a black window (it was significantly less a few months ago). This always happens when the game launches in an own popup (I think this is a workaround from itch.io if the game requires SharedArrayBuffer) but also some embedded games stay black as well.

That is quite some breakage and I wonder how long it will need now until this moves over to more general multimedia sites.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1949930: S3

:jgilbert, could you consider increasing the severity of this bug to S3?

For more information, please visit BugBot documentation.

Comment 17

[Tom Ritter [:tjr] (OOTO until 7/21)]

S4 is appropriate given that RFP is not supported. However; yes, I think that we should increase the values. I think we have the data to choose new values appropriately, we just need to fit it in.

Comment 18

[Thorin [:thorin]]

another example: https://old.reddit.com/r/LibreWolf/comments/1kyhf2f/how_to_increase_webgl2_max_texture_size/

Comment 19

[Tom Ritter [:tjr] (OOTO until 7/21)]

Attachment: Bug 1684230: Update the RFP constants for WebGL capabilities with empircal data r?#gfx-reviewers

This numbers represent the 1% percentile for each OS.
(Meaning 99% of all users have a value equal to orgreater than this value.)

Comment 20

[Tom Ritter [:tjr] (OOTO until 7/21)]

I've attached a patch that uses the data from Nightly that we've collected. I might want to redo the analysis once we have release data, but this can at least start a discussion.

Comment 21

[Thorin [:thorin]]

IANAE - some values stand out to me, e.g. 7, 9, 63, 511 vs 1, 16, 32, 1024. These seem adversarial/odd to me, but again, IANAE nor do I have any data. What happens if we report a higher value than the card's real value - e.g. we return 8 instead of 7 and the card is a 7 - would this cause webgl glitches/crashes, is it dependent on the webgl code?

Comment 22

[sworddragon2]

(In reply to Thorin [:thorin] from comment #21)

IANAE - some values stand out to me, e.g. 7, 9, 63, 511 vs 1, 16, 32, 1024. These seem adversarial/odd to me, but again, IANAE nor do I have any data.

I noticed this as well when I saw the patch 2 days ago, but in terms of tracking it shouldn't matter as anybody with RFP(/FPP?) enabled has the same values. It might just help websites determine that the user runs on the WebGL minimum capability mode (independent of the current or proposed values) and respectively that the user might have RFP or similar enabled - but this is something we probably can't reliable hide anyways with all the normalization/spoofing.

Or do you have something specific in mind where this might cause issues?

Comment 23

[Thorin [:thorin]]

something specific in mind

FPers generally have large databases of known real-world data - so anything that is "unusual" can be construed as adversarial (think anti-fraud, bot detection) - this is not about hiding that RFP is enabled. This is of course hypothetical (but we've seen this behavior before with RFP values). I wold guess that the current patch is unique/new

Maybe we should emulate the specs of a low-end real world card - maybe even the renderer/vendor (and update accordingly every two years)