Open Bug 1426232 Opened 7 years ago Updated 6 months ago

Consider a Timezone Permission for Resist Fingerprinting

Categories

(Core :: Security, enhancement, P5)

enhancement

Tracking

()

Tracking Status
firefox59 --- affected

People

(Reporter: tjr, Unassigned)

References

Details

(Whiteboard: [fingerprinting][fp-triaged])

I'm throwing this idea into a bug to not lose track of it, and to generate some discussion. One of the things we spoof in Resist Fingerprinting mode is Timezone. I don't want 99% of websites to have my timezone, but I really do want 1% of websites to have my timezone: Calendar and Timezone Conversion websites. Many of these websites have functionality where you can set your timezone manually, but that setting is often buried or difficult to find. If we assume that very large websites (e.g. Google Calendar) are willing to do a some amount of work to accomodate a Resist Fingerprinting mode, we could make Timezone into a permission (similar to Canvas Pixel Data). It's a little tricky though. Normally a permission prompt is trigger by a website accessing an asyncronous API which waits for the permission to be granted or declined. The asyncronous API *is* the access of the data you want: for example the workflow is "Give me a video stream of the webcam" which either succeeds (and gives the stream) or fails (when the user declines.) We *definetly* don't want to pop a permission prompt anytime a website accesses a field that exposes timezone. Ideally, we'd work within the constraints of the Permissions API: https://w3c.github.io/permissions/ but we hit a problem, which I will illustrate. Consider A website that wants the user's timezone would query the permissions interface, like so. > console.log("Line A: " + getDate.Timezone) > > navigator.permissions.query({name: "timezone"}).then(({state}) => { > if(state == "granted") > // Case 1 > else if (case == "prompt") > // Case 2 > else if (case == "denied") > // Case 3 > }).catch(err => { > // Case 4 > }) > > // After all permission 'stuff' is done: > console.log("Line B: " + getDate.Timezone) Some of these cases are easy. A browser that *has* a resist fingerprinting mode, and therefore understands the 'timezone' permission - but doesn't actually have that mode on (so it's not resisting fingerprinting) will return the legitimate timezone in Line A, return 'granted' (Case 1), and the same legitimate timezone in Line B. A browser that doesn't do any fingerprinting resistance, and don't understand the timezone permission, will give the legitimate timezone in Lines A and B, and return an exception (Case 4). The tricky parts are the other two cases. Assume we are in a Resist Fingerprinting mode. Line A will return 'UTC' (the spoofed timemzone). It will not cause a permission prompt. The query() call will enter in Case 2: "prompt". The website now knows it needs to prompt the user to get the legitimate timezone - but _how_ does it trigger the prompt? This is an open question. The Permissions API just doesn't expose a way for the website to say "Okay now ask for permission", that's always implied by the individual method calls for the feature in question. We _could_ attach a new method to the PermissionStatus return value: https://w3c.github.io/permissions/#status-of-a-permission - that'd be the most straightforward thing to do, but it's... a very unusual one-off that probably wouldn't be used for anything but our thing. That's undesirable. It's also a completely open question as to whether any large website would bother supporting this permission.
See https://github.com/w3c/permissions/issues/158. There's a number of APIs that have this kind of issue. It seems the rough conclusion was to just have a dedicated request permission API per thing we want to gate with a permission. E.g., navigator.requestTimezone() or some such. See also https://github.com/whatwg/html/pull/3047 by the way about exposing timezone changes to script in a more deliberate manner (and ensure consistency within a single event loop task).
Changing component as the "Permission Manager" component is not meant for this per its description.
Component: Permission Manager → JavaScript: Standard Library
Anne, what next action do you recommend here? Should we just implement something called `navigator.requestTimezone()` right away, or get this into a standard first? If the latter, who can do take this bug and get that going?
Flags: needinfo?(annevk)
Priority: -- → P5
I'm willing to do spec work. But honestly, if we don't have a high-profile partner website that would be willing to work with us on this I'm not sure it's worth it; it'd just be a dangling API no one uses. I also don't think we should take any action (other than discussions!) until we've kicked the tires on the Resist Fingerprinting feature a bit more, so that would be late Q1 2018 at the earliest.
Flags: needinfo?(annevk)
See Also: → 1364261
We just stumbled upon this bug after our IT introduced a new group policy for Firefox containing "resistFingerprinting=true". The enabled setting causes a lot of problems with our internal reporting systems that shows the wrong time and also calculates reports based on an incorrect time zone. It would be highly appreciated if the proposed feature would be added to Firefox as right now the users (~100 internal users with more to come) are no longer able to use Firefox in conjunction with these systems.
(In reply to Sascha M. from comment #5) > We just stumbled upon this bug after our IT introduced a new group policy > for Firefox containing "resistFingerprinting=true". The enabled setting > causes a lot of problems with our internal reporting systems that shows the > wrong time and also calculates reports based on an incorrect time zone. > > It would be highly appreciated if the proposed feature would be added to > Firefox as right now the users (~100 internal users with more to come) are > no longer able to use Firefox in conjunction with these systems. The correct solution to this is to tell your IT to remove that policy again, a lot of stuff breaks with resist fingerprinting and running Firefox with it on should be considered experimental.
(In reply to Johann Hofmann [:johannh] from comment #6) > (In reply to Sascha M. from comment #5) > > We just stumbled upon this bug after our IT introduced a new group policy > > for Firefox containing "resistFingerprinting=true". The enabled setting > > causes a lot of problems with our internal reporting systems that shows the > > wrong time and also calculates reports based on an incorrect time zone. > > > > It would be highly appreciated if the proposed feature would be added to > > Firefox as right now the users (~100 internal users with more to come) are > > no longer able to use Firefox in conjunction with these systems. > > The correct solution to this is to tell your IT to remove that policy again, > a lot of stuff breaks with resist fingerprinting and running Firefox with it > on should be considered experimental. Please direct your IT department to this comment and ask them to email me if they have any questions. tom@mozilla.com
Flags: needinfo?(info)
Thanks, I'll do that and point them to this report.
Flags: needinfo?(info)
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]

While this will solve the issue with timezone mismatches on sites that don't let you use a user preference to override the browser's setting, an automatic pop-up triggered by a site requesting the time zone is an annoyance to the user. Let's not repeat the "example.com wants to: Know your location" usability issue (there are myriads of sites online that show users how to disable these alerts).

The best compromises I can come up with are, in no particular order, not exclusive:

  1. Suppress time zone queries (today's functionality). The locationbar's shield dialog can toggle the site's TZ visibility
  2. Same as #1 but the shield changes color when the TZ was queried by the site's JS (no auto-popup!)
  3. Pop up alongside other permissions requests (but not standalone)
  4. Expose a new custom (... nonstandard) option that sites can use to request permission
  5. Expose nothing, allow timezone transparency via bug 1364261 instead

It would be a burden for somebody to maintain a list of sites that need this information for usability, especially since different users would likely disagree about which sites should make the list (basically, more similar to NoScript than to ad blockers), so I think that's out. However, it would be useful to be able to suppress the popup or color change proposed by my bullets 4 and 2.

Severity: normal → S3
Component: JavaScript: Standard Library → Security
You need to log in before you can comment on or make changes to this bug.