Revert 1372069 and allow geolocation prompts if Resist Fingerprinting is set to true

RESOLVED FIXED in Firefox 63

Status

()

enhancement
P3
normal
RESOLVED FIXED
Last year
Last year

People

(Reporter: tjr, Assigned: lyuyuan92)

Tracking

Trunk
mozilla63
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox60 wontfix, firefox61 wontfix, firefox62 wontfix, firefox63 fixed)

Details

(Whiteboard: [fingerprinting])

Attachments

(1 attachment)

Reporter

Description

Last year
Blocking Geolocation was done in Bug 1372069 early on in the Resist Fingerprinting process and done under the rational that your physical location is a fingerprinting vector _and_ that we were building this feature for Tor to use and they _definitely_ don't want geolocation.

But turning off features that have permission prompts is inconsistent. We don't disable Webcam or Microphone access, or Screensharing. (And all of those are even more fingerprintable than a location!)

All of these features (and geolocation) are behind permission prompts. If a user wants to grant a website access to this data, the permission prompt is the best way to do it; so it doesn't make sense to disable the feature when RFP is enabled.

Comment 1

Last year
(In reply to Tom Ritter [:tjr] from comment #0)
> we were building this feature
> for Tor to use and they _definitely_ don't want geolocation.

So TBB would still want this, right (since it overrides the site permissions)? How about replacing the relevant geolocation RFP checks with a new one eg `privacy.resistFingerprinting.block_geolocation` as a hidden pref (default false)
Reporter

Comment 2

Last year
(In reply to Simon Mainey from comment #1)
> (In reply to Tom Ritter [:tjr] from comment #0)
> > we were building this feature
> > for Tor to use and they _definitely_ don't want geolocation.
> 
> So TBB would still want this, right (since it overrides the site
> permissions)? How about replacing the relevant geolocation RFP checks with a
> new one eg `privacy.resistFingerprinting.block_geolocation` as a hidden pref
> (default false)

Don't need it, geolocation can be disabled (independently of RFP) with geo.enabled
Setting geo.enabled = false will cause navigator.geolocation to be undefined, which will leak that the user is resisting fingerprinting. If that is a concern, you could make the geolocation APIs silently return POSITION_DENIED or POSITION_UNAVAILABLE instead of prompting the user.
Priority: -- → P3

Comment 4

Last year
(In reply to Chris Peterson [:cpeterson] from comment #3)
> Setting geo.enabled = false will cause navigator.geolocation to be
> undefined, which will leak that the user is resisting fingerprinting. If
> that is a concern, you could make the geolocation APIs silently return
> POSITION_DENIED or POSITION_UNAVAILABLE instead of prompting the user.

Bug 1379560 (FF58) introduced `permissions.default.geo` (0=always ask (default), 1=allow, 2=block) to allow setting a geo default. Rather than remove the geo block, RFP should silently block (bypassing `permissions.default.geo`), but allow site permission exceptions.

---
IMO it should also bypass `geo.enabled` - but that's a whole other story where end users can tinker with about:config settings and alter the FP as defined by RFP - there are quite a few of these: eg
- `dom.netinfo.enabled`=false returns `undefined` but RFP returns `unknown` (i.e with dom.netinfo.enabled at default true)
- `media.video_stats.enabled`=false disables the stats entirely, but RFP spoofs the values
- there are others eg performance timing, but no need to list these all here

TBB can enforce/lock prefs if need be, but in Firefox, we could hardened these up (to protect users from inadvertently altering their fingerprint). Should we open a new ticket for this discussion?
Comment hidden (mozreview-request)
Reporter

Updated

Last year
Attachment #8986621 - Flags: review?(tom) → review?(amarchesini)
Reporter

Comment 6

Last year
Comment on attachment 8986621 [details]
Bug 1441295 - Reverted the changes in bug 1372069 and modified test;

Passing to baku for review, but LGTM. 

Could you do a try run for the build+test just to be safe though? You can use https://mozilla-releng.net/trychooser/ and choose linux64, debug (or opt) and (all) mochitests.
Attachment #8986621 - Flags: feedback+

Comment 7

Last year
mozreview-review
Comment on attachment 8986621 [details]
Bug 1441295 - Reverted the changes in bug 1372069 and modified test;

https://reviewboard.mozilla.org/r/251920/#review259118
Attachment #8986621 - Flags: review?(amarchesini) → review+
Reporter

Updated

Last year
Assignee: nobody → lyuyuan92
Keywords: checkin-needed

Comment 8

Last year
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/efe2c890d372
Reverted the changes in bug 1372069 and modified test; r=baku
Keywords: checkin-needed

Comment 9

Last year
bugherder
https://hg.mozilla.org/mozilla-central/rev/efe2c890d372
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.