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.

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?

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.

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

Thanks, I'll do that and point them to this report.