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

RESOLVED FIXED in Firefox -esr60

Status

()

defect
P2
normal
RESOLVED FIXED
a year ago
4 months ago

People

(Reporter: stebs, Assigned: timhuang)

Tracking

(Blocks 2 bugs)

Trunk
mozilla66
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox-esr60 fixed, firefox66 fixed)

Details

(Whiteboard: [fingerprinting] [gfx-noted][fp-triaged])

Attachments

(4 attachments, 2 obsolete attachments)

47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
4.15 KB, patch
Details | Diff | Splinter Review
9.78 KB, patch
Details | Diff | Splinter Review
Reporter

Description

a year ago
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.
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?
Flags: needinfo?(tom)
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)?
Flags: needinfo?(tom)
Whiteboard: [fingerprinting-breakage]
Whiteboard: [fingerprinting-breakage] → [fingerprinting-breakage] [gfx-noted]
Reporter

Comment 3

a year ago
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

Updated

a year ago
Priority: -- → P3
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?
Flags: needinfo?(jhofmann)
(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 :)
Flags: needinfo?(jhofmann)

Comment 6

8 months ago
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

8 months ago
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

8 months ago
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.
Whiteboard: [fingerprinting-breakage] [gfx-noted] → [fingerprinting] [gfx-noted]

Updated

6 months ago
Assignee: nobody → tihuang
Whiteboard: [fingerprinting] [gfx-noted] → [fingerprinting] [gfx-noted][fp-triaged]
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee

Comment 9

5 months ago
(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.
Assignee

Comment 10

5 months ago
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.
Attachment #9030727 - Attachment description: 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=baku → 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

Comment 13

5 months ago
Pushed by tihuang@mozilla.com:
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

5 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/24da6da80df9
https://hg.mozilla.org/mozilla-central/rev/183b5d2173b5
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

Comment 16

4 months ago

[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:

Attachment #9034823 - Flags: approval-mozilla-esr60?

Comment 17

4 months ago

[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:

Attachment #9034824 - Flags: approval-mozilla-esr60?
Attachment #9034824 - Flags: approval-mozilla-esr60?

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.

Attachment #9034823 - Flags: approval-mozilla-esr60? → approval-mozilla-esr60+

Updated

4 months ago
Attachment #9034824 - Attachment description: 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 → 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)
Assignee

Updated

4 months ago
Duplicate of this bug: 1460145
Assignee

Updated

4 months ago
Duplicate of this bug: 1468957
You need to log in before you can comment on or make changes to this bug.