privacy.resistFingerprinting breaks pinch zoom on DuckDuckGo maps (Apple Maps/MapKit)
Categories
(Core :: DOM: Events, defect)
Tracking
()
People
(Reporter: ke5trel, Assigned: fkilic)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(1 file)
STR:
- Set
privacy.resistFingerprinting = true
on Android Nightly. - Visit duckduckgo.com, search for a city and click the Maps tab.
- 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•1 year ago
|
||
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.
This is not a bug in the default settings. I think S3 at most. If not, feel free to upgrade it.
Updated•1 year ago
|
Getting pinch zoom to work requires disabling RFPTargets PointerEvents
and WidgetEvents
.
privacy.fingerprintingProtection = true
privacy.fingerprintingProtection.overrides = +AllTargets,-PointerEvents,-WidgetEvents
Assignee | ||
Comment 4•1 day ago
|
||
- 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
Updated•1 day ago
|
Comment 5•1 day ago
•
|
||
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
Assignee | ||
Comment 6•1 day ago
•
|
||
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•1 day ago
|
||
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 9•1 day ago
|
||
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•1 day ago
|
||
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•6 hours ago
|
||
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.
Assignee | ||
Comment 12•5 hours ago
•
|
||
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.
Assignee | ||
Comment 13•4 hours ago
•
|
||
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.
Description
•