1875939 - Graphics garbage (vertical bars) in Zoom in place of camera self-view with pref privacy.resistFingerprinting=true

Status: NEW

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: image.png

We suspect this this is a webpage bug, but tracking it here for now until we're able to escalate.

STR:

1. In about:config, set privacy.resistFingerprinting to true
2. Join a zoom call and allow camera and microphone.

Expected result: Camera self-view
Actual result: Vertical bars (see attached image)

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Not a regression (confirmed back to 2021-03-20).

Interesting symptom: I can flip between vertical bars and camera by modifying the pref live in about:config in a separate Firefox window.

It might be interesting to figure out which API this is failing over to see if we can improve the privacy.resistFingerprinting mode without revealing any more user info.

Comment 2

[Tom Ritter [:tjr]]

This is happening because the website is rendering something to a canvas, then reading it back out, and then trying to show it to the user. Without granting the page canvas permission, the "read it back out" results in the garbage, so when its shown to the user - you just see garbage.

We can leave this open as a breakage bug, but practically speaking we aren't trying to improve RFP to address this except to make canvas software renderable (eventually) so we can stop doing the garbage stuff.

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Thanks Tom, I should have noticed the canvas-usage icon in the URL bar as a clue!

But even if I click it and allow "Extract canvas data" permission Zoom still doesn't work. This differs from e.g. bug 1827279 comment 0:

There's a canvas-usage icon in the URLbar that I can click into, to grant Google Maps permission to read back data from the canvas. If I do that, then I get expected-results. So I think the issue here is that Google is drawing these icons using canvas, and reading them back, and we're blocking the readback, and so they end up drawing some form of garbage instead.

Is that inconsistency a bug? If so, which way?

Comment 4

[Tom Ritter [:tjr]]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #3)

Thanks Tom, I should have noticed the canvas-usage icon in the URL bar as a clue!

But even if I click it and allow "Extract canvas data" permission Zoom still doesn't work. This differs from e.g. bug 1827279 comment 0:

There's a canvas-usage icon in the URLbar that I can click into, to grant Google Maps permission to read back data from the canvas. If I do that, then I get expected-results. So I think the issue here is that Google is drawing these icons using canvas, and reading them back, and we're blocking the readback, and so they end up drawing some form of garbage instead.

Is that inconsistency a bug? If so, which way?

If you refresh the page after granting the permission persistently, that should resolve it. Canvas isn't meant to behave this way (async asking for a permission), so we hack it - we give garbage synchronously, then prompt. If the user grants the permission the next read will succeed. But pages often don't know they should do another read.