1446472 - privacy.resistFingerprinting is true blocks QR code (canvas) on web.whatsapp.com without any notice

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect, P2)

Description

[Stebs]

With privacy.resistFingerprinting set to true, restart and go to  https://web.whatsapp.com/
You can briefly see the QR Code appear on the right side, where the telephone in a bubble symbol is, but it disappears immediately after. With privacy.resistFingerprinting off, QR Code stays visible.

Afaik this is because canvas generation on load is now blocked with the above privacy setting.
BUT the fact that there is no notification, blocked sign etc. whatsoever is less than optimal. Even without asking for HTML5 canvas permission, users should get notified that something was blocked, just like the shield sign for "tracking attempts blocked". (Maybe a "canvas generation blocked"?)

If you right click the page and go to View Page Info, Permissions and set Extract Canvas Info to "Always ask", you still get not asked nor notified that the QR Code was blocked. The page works as intended only if setting this to "Allow".

Without a better notification (that could be unobtrusive), on this whatsapp page alone, there will be lots of complaints of users who set privacy.resistFingerprinting=true upon some recommendation without understanding what it does, or even forgot about setting it.

Comment 1

[Aria Beingessner [:Gankra]]

Hey Tom, this isn't really quite a graphics issue, more of a high-level UI policy one; do you know who should be looking at this?

Comment 2

[Tom Ritter [:tjr]]

Yup, this is the fingerprinting team's.

Thanks for this report Stebs. You're correct that the UX for canvas being auto-blocked should be improved. I think this bug is going to be the bug for that issue.

I would like to understand a bit more about the 'QR Code' WhatsApp is hiding from you.  Resist Fingerprinting does not block someone from rendering to a canvas. But it will lie about what is rendered to a canvas if a website tries to read it out.

I can only conclude that WhatsApp is rendering a QR code, reading the QR code it just rendered from the canvas; and then... replacing the canvas data with the data it just read (which is an empty box)?  

Finally, if this behavior is blocking your workflow, you can restore the old behavior by flipping privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts - we eventually want to do away with that pref but I think we need to solve this issue before doing so.  If you can, can you try flipping that pref and see if you get the same behavior (except this time, with a prompt hanging there)?

Comment 3

[Stebs]

With privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts:false, I see the prompt.
When allowing it (use of HTLM5 canvas image), the QR code is rendered correctly. Upon disallowing it, the QR code is not rendered correctly (like in the bug description, it shows only briefly).
So disabling autodecline fixes the bug.
I have no idea how/why the WhatsApp page does the canvas rendering, sorry. 
Imho as a stop-gap measure, upon auto-declining, the "You have blocked canvas data extraction for this website" sign should show for the site, just like it does after manually declining canvas with privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts:false

Comment 4

[Tom Ritter [:tjr]]

Johann - I fiddled with this a bit, but hit a blocker.  I think what I want to do is:

>        nsresult rv = permissionManager->AddFromPrincipal(principal,
>                                        "canvas",
>                                        nsIPermissionManager::DENY_ACTION,
>                                        nsIPermissionManager::EXPIRE_SESSION,
>                                        /* aExpireTime */ 0);

When we deny access to indicate it was blocked. But CanvasUtils.cpp is in the content process - and you can't call AddFromPrincipal from the Content Process.  What's the right way to accomplish this?

Comment 5

[Johann Hofmann [:johannh]]

(In reply to Tom Ritter [:tjr] from comment #4)
> Johann - I fiddled with this a bit, but hit a blocker.  I think what I want
> to do is:
> 
> >        nsresult rv = permissionManager->AddFromPrincipal(principal,
> >                                        "canvas",
> >                                        nsIPermissionManager::DENY_ACTION,
> >                                        nsIPermissionManager::EXPIRE_SESSION,
> >                                        /* aExpireTime */ 0);
> 
> When we deny access to indicate it was blocked. But CanvasUtils.cpp is in
> the content process - and you can't call AddFromPrincipal from the Content
> Process.  What's the right way to accomplish this?

You need to send the isHandlingUserInput info along to the parent process.

It's a bit unfortunate that we're using the custom observer shenanigans for setting permissions here instead of nsContentPermissionUtils/nsIContentPermissionRequest, which is how permission requests are normally done. That would give us the ability to send along isHandlingUserInput data as part of the permission prompt: https://searchfox.org/mozilla-central/rev/f5fb323246bf22a3a3b4185882a1c5d8a2c02996/dom/interfaces/base/nsIContentPermissionPrompt.idl#90

Back in the day I figured it was too much of a rewrite to ask for a Tor uplift patch, but it could still be worth exploring for canvas (it's mostly boilerplate code, here's a recent patch from Tim that was ultimately discarded for different reasons: https://phabricator.services.mozilla.com/D568#change-xVwtJEWYzG45).


On a more general note, I don't think setting a DENY entry with session expiry will help the user experience. The main action associated with that state is the (x) button in the identity popup, which will have no effect at all (because we keep blocking even if you remove the "DENY" permission). The only helpful thing for the user to do would be to explicitly switch to "Allow", which can be only done in the Page Info window or in the permission dialog (which we're not showing anymore).

I would like to reiterate my suggestion from https://bugzilla.mozilla.org/show_bug.cgi?id=1376865#c6 instead:

> Show the doorhanger as hidden (with only the identity block icon visible), unless it was triggered through IsHandlingUserInput(). This would allow users to make their choice in a less intrusive way by clicking the identity block icon to optionally show the doorhanger (and it would be a nice test run for mainstream permissions).

I think it provides a much more coherent, non-intrusive user experience.

Let me know what you think :)

Comment 6

[Tom Ritter [:tjr]]

Tor disabled the no-prompt-if-not-user-interaction part of canvas because of this issue, so we're going to bump it up to P2 to investigate.

Comment 7

[Jeff Ro]

Thanks for looking into this problem. For months this issue has been the *only* reason for keeping chrome on my computer. I use web.whatsapp.com daily  (as do most of the university students I know).

Comment 8

[Patrick]

Just wanted to add that sending images via WhatsApp Web is also broken when "privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts" is set to true.
While enabled, the UI will only show a white box instead of the picture, and the white box would also be sent when submitting.

Comment 9

[Tim Huang[:timhuang]]

(In reply to Johann Hofmann [:johannh] - Away until January 2nd from comment #5)
> I would like to reiterate my suggestion from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1376865#c6 instead:
> 
> > Show the doorhanger as hidden (with only the identity block icon visible), unless it was triggered through IsHandlingUserInput(). This would allow users to make their choice in a less intrusive way by clicking the identity block icon to optionally show the doorhanger (and it would be a nice test run for mainstream permissions).
> 

I vote this idea that this could provide a better user experience. People can at least know something happened from inspecting the identity block icon in the case of auto-blocking. I think the problem here is that the blocking happens without any notice, so it looks to people more like a breakage than a feature at the first glance. So, showing an identity block icon would tell that something is happening on the page.

Comment 10

[Tim Huang[:timhuang]]

Attachment: Bug 1446472 - Part 1: Showing the identity block icon for canvas permission without the doorhanger when canvas extraction is auto detected. r=baku

For a better user experience of auto-blocking canvas extraction, this
patch changes the behavior when detecting a canvas extraction without
user interaction. It will show a canvas identity block icon with a
hidden doorhanger when auto-blocking the canvas extraction. Users can
make their choice to either block or allow the canvas extraction by
clicking the identity block icon and then refresh the page to make
the canvas permission taking effect.

Comment 11

[Tim Huang[:timhuang]]

Attachment: Bug 1446472 - Part 2: Add a test for ensuring that the identity block icon will show without the doorhanger when canvas auto-blocking happens. r=gijs

Depends on D14259

Comment 12

[Tim Huang[:timhuang]]

Try looks good.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a4a2333c9d9f0dcbc775592d82874b3c660e454d

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/24da6da80df9
Part 1: Showing the identity block icon for canvas permission without the doorhanger when canvas extraction is auto detected. r=baku,Gijs
https://hg.mozilla.org/integration/autoland/rev/183b5d2173b5
Part 2: Add a test for ensuring that the identity block icon will show without the doorhanger when canvas auto-blocking happens. r=Gijs

Comment 14

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/24da6da80df9
https://hg.mozilla.org/mozilla-central/rev/183b5d2173b5

Comment 15

[Tom Ritter [:tjr]]

I backported this to esr60 here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e2d6b61253f962f79f5de4660643fd1add09b1cf

Comment 16

[Tom Ritter [:tjr]]

Attachment: Bug 1446472 - Part 1: Showing the identity block icon for canvas permission without the doorhanger when canvas extraction is auto detected. r=baku,Gijs (esr60)

[ESR Uplift Approval Request]

If this is not a sec:{high,crit} bug, please state case for ESR consideration: Backport a canvas blocking improvement for Tor

User impact if declined: Tor will have to carry the patch themselves

Fix Landed on Version: 66.0a1 / 20181217220100

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): Affects a non-default feature; and it has tests.

String or UUID changes made by this patch:

Comment 17

[Tom Ritter [:tjr]]

Attachment: Bug 1446472 - Part 2: Add a test for ensuring that the identity block icon will show without the doorhanger when canvas auto-blocking happens. r=Gijs (esr60)

[ESR Uplift Approval Request]

If this is not a sec:{high,crit} bug, please state case for ESR consideration:

User impact if declined:

Fix Landed on Version:

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky):

String or UUID changes made by this patch:

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9034823 [details] [diff] [review]
Bug 1446472 - Part 1: Showing the identity block icon for canvas permission without the doorhanger when canvas extraction is auto detected. r=baku,Gijs (esr60)

UX improvement for canvas blocking when the privacy.resistFingerprinting pref is set to true (off by default for official Firefox builds, enabled for Tor). Includes an automated test. Approved for 60.5.0esr.

Comment 19

[Tom Ritter [:tjr]]

Attachment: Bug 1446472 - Part 1: Showing the identity block icon for canvas permission without the doorhanger when canvas extraction is auto detected. r=baku,Gijs (esr60)

I needed to rebase the first patch, attached now.

Try run for sanity checking: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f17ec2ee77894c5356e5a8788cb3f5a262d7e806

Comment 20

[Tom Ritter [:tjr]]

Attachment: Bug 1446472 - Part 1: Showing the identity block icon for canvas permission without the doorhanger when canvas extraction is auto detected. r=baku,Gijs (esr60)

Rebased and Fixed patch.

Successful try link: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1c591bbc8c19f7e72a082017e34f0cb45d1bc2db

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr60/rev/91e3866c2649
https://hg.mozilla.org/releases/mozilla-esr60/rev/a578196b1fe0

Comment 24

[monperrus]

FYI still breaking whatsapp web (see bug 1600252).

What would be an appropriate notice for this case? A popup?