1826051 - privacy.resistFingerprinting breaks pinch zoom on DuckDuckGo maps (Apple Maps/MapKit)

Status: ASSIGNED

(Core :: DOM: Events, defect)

Description

[Kestrel]

STR:

1. Set privacy.resistFingerprinting = true on Android Nightly.
2. Visit duckduckgo.com, search for a city and click the Maps tab.
3. Try to zoom the map out by pinching with two fingers.

Behaves like second touch does not occur. Zoom buttons are unavailable so there is no way to zoom out. MapKit uses pointer events with pointerType: "touch" and no pointermove events are logged for the second touch (maxTouchPoints reports as 0 with RFP).

Other maps I tested like maps.google.com, openstreetmap.org and flightradar24.com work with pinch zooming but they use touch events instead of pointer events.

As a workaround, zoom controls can be made to appear by changing dom.w3c_touch_events.enabled = 0.

It also works with a RFP domain exception:

privacy.resistFingerprinting = true
privacy.resistFingerprinting.testGranularityMask = 4
privacy.resistFingerprinting.exemptedDomains = duckduckgo.com

Comment 1

[Tom Ritter [:tjr]]

Thank you for this report. I think the solution is for Android to not do RFP on pointer events, because virtually all Android devices have a touchscreen, and it's more rare for desktop.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This is not a bug in the default settings. I think S3 at most. If not, feel free to upgrade it.

Comment 3

[Kestrel]

Getting pinch zoom to work requires disabling RFPTargets PointerEvents and WidgetEvents.

privacy.fingerprintingProtection = true
privacy.fingerprintingProtection.overrides = +AllTargets,-PointerEvents,-WidgetEvents

Comment 4

[Fatih Kilic]

Attachment: Bug 1826051: Improve PointerEvents RFP target for Android. r?tjr

• This patch separates RFPTarget::PointerEvents into PointerEvents and PointerId.
  -PointerId protection is disabled for Android.
• WidgetEvents emit non-primary mouse events on Android because any touch other than 1nd touch is considered non-primary
• Sets maximum touch points to 5 on Android

Comment 5

[Thorin [:thorin]]

Whoa ... where was it decided that android RFP is 5 max touch points?

Edit: we have plans for all devices to report 10 - here's a meta - https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42069

Comment 6

[Fatih Kilic]

It wasn't decided really, I just submitted a patch for review. I think Tom and you can decide. My phone (S23U) reports 5, so I based it on that, but we can change it to 10 (which I think makes more sense assuming some tablets might support 10 fingers)

Comment 7

[Thorin [:thorin]]

okie dokie :) here's some backstory: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/28535

• We should go with 'Option B' as outlined in @thorin's post here: #28535 (comment 2848069)

We're not trying to hide the OS (win linux android mac) of course, but the spec says "While a maxTouchPoints value of greater than 0 indicates the user's device is capable of supporting touch input, it does not necessarily mean the user will use touch input" and (from me) "the w3c link suggests always returning the highest on multiple screens"

So making everyone 10 covers all bases (no user activation/gestures - i.e just getting max touch points) and my desktop (no touch) and my laptop (10 points) and phone (5 points) all "work" spec wise IIUIC

Comment 8

[Fatih Kilic]

I see. Yeah makes sense to me. I just updated it to 10

Comment 9

[Tom Ritter [:tjr]]

This looks good to me conceptually (I hate that we're adding another weird exception in nsRFPService::IsRFPEnabledFor like spoof english, but the long-term goal of only using FPP and not RFP would resolve that issue.)

Before I approve this though I think pierov and and thorin should thumbs-up it for Tor Browser.

Comment 10

[Pier Angelo Vendrame]

We've been discussing about spoofing the number of touch points also on desktop (e.g., many high end Windows laptops have touch screens). Our issue is #28535
Anyway, I'll try to look at this patch better tomorrow and I'll let you know.
Thanks for the ping!

Comment 11

[Pier Angelo Vendrame]

Yep, I confirm what I said yesterday.
I think we could spoof 10 at least also on Windows for everybody.
As Thorin said, we don't care that much of revealing the OS, so we could keep 0 on macOS if you prefer.

Comment 12

[Fatih Kilic]

Sure, just as a note during testing I realized you can check for touch support using "ontouchstart" in document.documentElement. matchMedia("pointer: coarse") seems to be spoofed (though incorrectly if this patch lands) but not the legacy touch events.

Comment 13

[Fatih Kilic]

Okay I just updated the patch to also fix the "ontouchstart" in document.documentElement leak. Fixed that matchMedia error that was going to happen as well.

EDIT: I realized dom.w3c_touch_events.legacy_apis.enabled is set to false on every platform except android, so the events would never register on desktop regardless of touch support, which is strange and I asked it on desktop community, I'll update if they'll answer.

EDIT 2: I found the reason. It is intentional. According to the spec https://www.w3.org/community/reports/touchevents/CG-FINAL-touch-events-20240704/#conditionally-exposing-legacy-touch-event-apis

Existing web content often use the existence of these APIs as a signal that the user agent is a touch-enabled "mobile" device, and therefore exposing these APIs on non-mobile devices, even if they are touch-enabled, could lead to a suboptimal user experience for such web content.

Given that we don't care about leaking platform, I think there's no point in trying to spoof this too.