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

Status: RESOLVED FIXED

(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] (OOTO until April)]

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

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

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

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

Comment 9

[Tom Ritter [:tjr] (OOTO until April)]

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

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

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.

Comment 14

[Thorin [:thorin]]

What exactly is the reasoning behind mac and linux being 0? The whole point was to report everyone as having some so if they decided not to use touch, no harm, but if they did then it matches spec (so to speak). Are you telling me that mac and linux are never touch capable ( or have never ever reported max touch as anything other than 0 in gecko code)?

Comment 15

[Thorin [:thorin]]

ontouchstart - there is more than this. I don't quite see/follow where this is addressed in the patch, but I also think we should ignore this (as a leak in this patch) and address it properly in a separate bug

Comment 16

[Fatih Kilic [:fkilic]]

(In reply to Thorin [:thorin] from comment #15)

ontouchstart - there is more than this. I don't quite see/follow where this is addressed in the patch, but I also think we should ignore this (as a leak in this patch) and address it properly in a separate bug

This revision enabled it but then I removed that because of W3C's comment which makes sense. Also I was wrong the first time, it doesn't get enabled automatically. If the user modifies that pref on any platform other than Android, that's when it automatically detects it. I searched for how to detect touch support and one of the thing that comes up is "ontouchstart" in document.documentElement, so it is likely that if we spoof this as well, many websites will recognize firefox with this rfp target enabled as a mobile device. In that revision, I was also modifying the (pointer: coarse/fine) media query but that's also not set as coarse on windows machines with touch screen support, I haven't looked at it but probably for the same reasons, websites recognizing a non-mobile device as a mobile device. All the browsers still emit touchstart etc. events, but just don't expose these to prevent being recognized as mobile device.

I think we have to answer this one though. Do we want to spoof pointer type to touch ALL the time if SPOOFED_MAX_TOUCH_POINTS > 0? My proposal in that comment is not spoofing if SPOOFED_MAX_TOUCH_POINTS > 0 && mInputSource != pen or SPOOFED_MAX_TOUCH_POINTS == 0 && mInputSource != mouse. The websites will still be able to add listeners for touch and mouse events to differentiate between touch and mouse.

Comment 17

[Thorin [:thorin]]

Do we want to spoof pointer type to touch ALL the time

noooo, see next snippet

The websites will still be able to add listeners for touch and mouse events to differentiate between touch and mouse.

We're not going to be able to hide user actions, but imagine my touch laptop - and I only use my mouse. It's to try to eliminate the differences between touch vs non-touch devices (ignore android). Just because my max touch points is 10 on my laptop doesn't mean I used touch - I also have a mouse and/or trackpad and I even have a pen

pref

are we talking about dom.w3c_touch_events.enabled? Thing may have changed since I last tested...

// Touch, TouchEvent, TouchList, ontouchcancel, ontouchend, ontouchmove, ontouchstart
	// ^ are not in my windows touch-capable laptop but may be present in a tablet
// dom.w3c_touch_events.enabled: 0=disabled (macOS) 1=enabled 2=autodetect (linux/win/android)
	// autodetection is currently only supported on Windows and GTK3 (and assumed on Android)
	// on touch devices: 0 (all false) 1 or 2 (all true)

The last line, by all false/true I mean the properties are present (I think, it's been a while). So I think the answer is to force the pref and API disabled on all platforms except android - given my laptop FF seems to and always has worked perfectly fine without them

Comment 18

[Pier Angelo Vendrame]

(In reply to Thorin [:thorin] from comment #14)

What exactly is the reasoning behind mac and linux being 0? The whole point was to report everyone as having some so if they decided not to use touch, no harm, but if they did then it matches spec (so to speak). Are you telling me that mac and linux are never touch capable ( or have never ever reported max touch as anything other than 0 in gecko code)?

No macOS device has a touch screen. (I consider iPadOS a different OS, but I know nothing about iPadOS/iOS Firefox).
I don't know about external touch screen devices support though. IIRC I even had problems with my Wacom tablet.

For Linux they're more or less supported, but you'll need special environment variables IIRC (MOZ_USE_XINPUT2=1), or maybe it was only for my device. So, I thought it as a disabled by default, hence my suggestion.
However, to be coherent with dom.w3c_touch_events.enabled, maybe we should spoof 10 also on Linux.

+1 for not spoofing as touch screen all the time.

We're not going to be able to hide user actions

Yep, we usually exclude behavioral fingerprinting AFAIK... it's just too hard to cover it.

Anyway, I have an old MS Surface, if you need for tests in a Windows tablet.
I also used to have Debian Mate in a microSD, if we need to see how Linux behaves there as well.

Comment 19

[Fatih Kilic [:fkilic]]

are we talking about dom.w3c_touch_events.enabled? Thing may have changed since I last tested...

I actually meant this one dom.w3c_touch_events.legacy_apis.enabled but I think the general consensus is not spoofing it, so I removed the code that override it.

We're not going to be able to hide user actions, but imagine my touch laptop - and I only use my mouse. It's to try to eliminate the differences between touch vs non-touch devices (ignore android). Just because my max touch points is 10 on my laptop doesn't mean I used touch - I also have a mouse and/or trackpad and I even have a pen

Yep, we usually exclude behavioral fingerprinting AFAIK... it's just too hard to cover it.

Alright then, I removed that part too.
I also set linux to 10 as well. So only OSX is 0, and all the other platforms get 10.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/75db5798bdd4
Improve PointerEvents RFP target for Android. r=tjr

Comment 21

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/75db5798bdd4