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?
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)?
Whiteboard: [fingerprinting-breakage] → [fingerprinting-breakage] [gfx-noted]
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
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?
(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 :)
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.
Priority: P3 → P2
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).
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]
Assignee: nobody → tihuang
Whiteboard: [fingerprinting] [gfx-noted] → [fingerprinting] [gfx-noted][fp-triaged]
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(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.
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.
Depends on D14259
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
Pushed by email@example.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
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)
You need to log in before you can comment on or make changes to this bug.