I am reopening this bug and setting it to block bug 1401440 given the lack of responses to comment 6, in which I wrote:

Shouldn't this bug block bug 1401440 rather than be a duplicate? […] Bug 1401440 never mentions time zones. Bug 1401440 comment 16 is the only mention of times in the entire conversation so far, and its not even directly related to time zones.

This is one of the "multiple options" that bug 1401440 should refer to. My aspiration is that in creating this dependency, I'm ensuring this request doesn't get forgotten.

I think it's worth reiterating comment 2 above. 90% of the world's population lives in one of a dozen timezones. The privacy gained by hiding this information is negligible, and IMO does not outweigh the inconvenience. I've been running RFP for months, and the only ill effects I've seen are related to the timezone spoofing. I'd be happy with seeing TZ obfuscation removed altogether, but a separate option is the next best thing.

For those particurally invested in this issue; I am curious the range of websites you find yourself inconvenienced by. GCal, and a few other sites I use, lets you set your timezone manually; the main one I've found annoying is thetimzoneconverter.com

If we implemented Bug 1426232 do you think the site(s) that annoy you would take advantage of it?

:tjr the main blocker for me is Asana, which new tasks will have wrong due time when we enable RFP.

90% of the world's population lives in one of a dozen timezones. The privacy gained by hiding this information is negligible, and IMO does not outweigh the inconvenience

A solution that ignores some users is not a full solution, IMO. It should also probably be based on online users, not population. We only really need to look at the set of protected users (e.g RFP users on Firefox, or Tor Browser): entropy should drop as more users are in a set. If TB has 6 million users (assuming the same sort of distribution over time zones as all users), then outliers will stand out more, because it is already in a very small set: a user in say UTC+8 or UTC+1 would be in a much larger bracket than say someone who declares they are in UTC-2. If 60 million more TB users suddenly appear, then the consequences of not spoofing become less severe. But it is still a metric that raises entropy, and by eliminating any differences, that metric is rendered useless. This is mathematical fact.

The proper solution (when lowering entropy), is to make all users the same, or to limit the buckets. Limiting the buckets for TZ would only be a partial solution to usability

This issue is not about whether it should be spoofed for all as the same value, but about usability.

I am curious the range of websites you find yourself inconvenienced by

From comments elsewhere from other users of RFP:

• others: web-mail based issues (I don't use any, so IDK: e.g. replying to an email from the past depending on your devices, clients)
• myself & others: information about when an event is on (sports, concerts, etc) often usually uses TZ: I see this a lot.. and have actually missed things because I didn't pay attention
• myself: I see information on websites only offered to those in the right time-zone (usually sports related): probably the websites wanting to cut down costs by only pandering to their own markets

solution

Separating TZ spoofing from the parent RFP wouldn't allow any granularity: and inconvenienced (and unknowledgeable) users would be tempted / put at "risk".

I still think the (only) solution is to offer a per-site exception: same as canvas. i.e default: spoof and no Options>UI presence, but when RFP=true, then the site permissions dialog has a Reveal real Time Zone entry with options for "block (default)" and "allow". No need for prompts. I'm not sure Bug 1426232 actually fits this proposal (which for some reason I thought it did).

Examples:

• sites a user logs into (although they may be trying to anonymous as well: not their real ID) would probably have less impact but real benefits
• gmail, google calendar, etc
• I for one would use it on about two sites (not sharing those with you!)

When RFP becomes front facing, or added to PB mode (or another window mode), two things are important

• user expectations and teaching them those (and that they can use a normal window if too much "breaks" on a given site)
• uptake: the less breakage or usability issues, the more likely they continue to use it: and this is one of the biggest keys IMO. RFP/TB sets really benefit the more users they have.

I'm as curious as Tom as to the range of websites that will hopefully get reported here

I agree with Simon in comment 13 and disagree with comment 2 and comment 10.

It gets worse if the time zone revealed is more than an offset; in terms of revealing nature:
→ Africa/Bangui > West Africa Time > Europe/London > British Summer Time > +0100 > +0000

I'm not sure exactly what is visible (I assume it's just the offset), but even the offset is extremely telling in certain areas such as Nepal, Bangladesh, various islands in the Atlantic and Pacific, etc. It's even more telling combined with language preferences (which we'll never be able to control). Also consider all the summer time / daylight savings differences in adoption and timing.

I'd probably object less to some kind of popularity-driven TZ approximation, where your time zone is reported as the closest "sufficiently popular" time zone (which would need to be determined somehow), but that'd likely lead to a good amount of end-user confusion. (It'd also still be revealing when your TZ changes due to summer time / daylight savings unless the browser also rounds that to a less revealing time, which would contribute to even more confusion.)

I must confess I don't understand the objections raised: there's two things here that probably need separate consideration.

1. allowing users to disable timezone spoofing
2. adding UI that lets users toggle that setting

For 1, adding timezone clearance for power users via about:config is a great idea, and won't change how fingerprint resisting works for standard users. The default settings stay the default settings, turning on anti-fingerprinting locks everything down, the vast majority of users won't know (or care) that this is even a thing they might be able to control.

The kind of people who use Firefox because it offers them the freedom to configure it as needed, and who actively look for settings in about:config that lets them improve their browser experience, should be able to go "I disagree with where you decided to draw the line between privacy and usability, and prefer to have accurate dates from both my own code and websites at large even if that means I am easier to track".

For 2, exposing that setting as part of the general preferences is maybe worth it? Most regular users never dig into all the privacy and security features, and adding a bit on what fingerprinting tricks Firefox should try to block in the "custom" section for Tracking Protection sounds pretty useful. That said, whether 2 is a good idea or not, 1 most certainly is.

(edited because I thought I was replying to a different bug, so the original comment didn't actually make sense)

Regarding entropy exposed by exposing the time zone, it might make sense to normalise timezones that share a same offset.

Eg: Europe/Amsterdam and Europe/Berlin are both UTC+0200. Just blend them both into the same thing. This maximises convenience/security.

GMail also relies on the browser reported timezone so you get a lot of wrong time stamps, even when Google Calendar time zone is set correctly.

(In reply to Tom Ritter [:tjr] (ni? for response to CVE/sec-approval/advisories/etc) from comment #11)

For those particurally invested in this issue; I am curious the range of websites you find yourself inconvenienced by.

In addition to comment #13:

• Checking business hours. Not only is converting inconvenient, there's no indication when times have been localized and when they haven't, unless they're preposterous.
• Ordering anything for pickup or delivery. They shouldn't use the user's clock to determine if the business is open or closed, but some do.
• Approving documents, including signing contracts. Some read the date from the browser and don't allow changing it; some require the user to enter the wrong date to proceed.
• Firefox's own history window.

Chiming in because this has been impacting me a lot over the last few months.

• A lot of scheduling tools have been broken. This includes job interview scheduling tools, or tools that a volunteering organization I've worked with uses for checking availability. Having to convert my calendar to UTC is a very painful experience, so I've started using a different browser for those websites.
• Facebook is now showing me a notification for people's birthday the day before (my current time zone is UTC-7 so I've started seeing birthday alerts at 5pm)
• Food delivery websites have been showing me wrong times, confusing me multiple times.

While I understand that a user's time zone can be used as another data point for fingerprinting, it's arguably not as significant as other factors that are still leaked by Firefox. On the other hand, the downsides for the users can be significant. We can't expect websites to get fixed, we need to fix the issue in the browser.

it's arguably not as significant as other factors

It's very significant - there are 374 unique sets of timezone offsets, 450+ unique timezone names. Protection is for everyone, including those marginalized in a very long tail of decreasingly-sized buckets of users, like the dozen people in Artic\Longyearbyen or that one guy at Antarctica\McMurdo

there are 374 unique sets of timezone offsets, 450+ unique timezone names

Could be generalized to Etc/GMT* offsets to reduce the number of options significantly. When DST starts or end, the offset reported by the browser would change.

(In reply to Alessandro Segala from comment #24)

Could be generalized to Etc/GMT* offsets to reduce the number of options significantly. When DST starts or end, the offset reported by the browser would change.

That doesn't work. Instead of 374 unique sets of timezone offsets, where everyone is happy all year round with correct times and DST, you would reduce that to 25 timezones with no DST, and put all those in a timezone with DST, with the wrong time for half a year.

About the best you can do is only look at dates from say 2020 on (so a little backwards compat), and reduce it to 62, which is still high, and has a long tail and the guy at McMurdo is not happy

(In reply to Alessandro Segala from comment #22)

We can't expect websites to get fixed, we need to fix the issue in the browser.

I agree. I think this is something we can improve in (at least) two ways.

1. Our long-standing effort to make RFP exemptable on a per-site basis. This is happening in the parent Bug 1450398 and should get some more movement in the next year with some volunteers. Timezone is trickier than most aspects, it's in Bug 1709867, but there is a patch we can build off of in Bug 1716541. If anyone is impatient enough they want to tackle this themselves, I can mentor.
2. Some additional option; like making it optional (this bug), or making it a permission Bug 1426232. Again, if someone is impatient enough they want to tackle it, let me know.

(In reply to Simon Mainey from comment #25)

That doesn't work. Instead of 374 unique sets of timezone offsets, where everyone is happy all year round with correct times and DST, you would reduce that to 25 timezones with no DST, and put all those in a timezone with DST, with the wrong time for half a year.(

I don't understand.

My current time zone is America/Los_Angeles. As of today, that is equivalent to Etc/GMT-7. In November, that will change to Etc/GMT-8. The browser could be reporting Etc/GMT-7 today (DST on) and Etc/GMT-8 when DST is off. Where's the issue?

(In reply to Tom Ritter [:tjr] (ni? for response to CVE/sec-approval/advisories/etc) from comment #26)

Thanks, I look forward seeing progress here!

Alessandro, this is better discussed in Bug 1719738

(In reply to Tom Ritter [:tjr] (ni? for response to CVE/sec-approval/advisories/etc) from comment #11)

For those particurally invested in this issue; I am curious the range of websites you find yourself inconvenienced by. GCal, and a few other sites I use, lets you set your timezone manually; the main one I've found annoying is thetimzoneconverter.com

If we implemented Bug 1426232 do you think the site(s) that annoy you would take advantage of it?
Adding my late two cents. Several years ago just after I first enabled privacy.resistFingerprinting, I made an appointment online with the Red Cross to donate blood. I selected the appropriate time and date, only to have Red Cross log it as the following day (I am at UTC-8). I showed up at the time I thought my appointment was, only to be told they had me down for the next day and they couldn't take me.

That was a huge bummer for me, and because I cannot predict what other negative side effects it will generate, I have not used privacy.resistFingerprinting since - even though I would sorely like to.

(In reply to Tom Ritter [:tjr] (ni? for response to CVE/sec-approval/advisories/etc) from comment #11)

For those particurally invested in this issue; I am curious the range of websites you find yourself inconvenienced by. GCal, and a few other sites I use, lets you set your timezone manually; the main one I've found annoying is thetimzoneconverter.com

If we implemented Bug 1426232 do you think the site(s) that annoy you would take advantage of it?

Add these to the list of websites/apps that produce incorrect local times when privacy.resistFingerprinting = True:

https://whatismytimezone.com/
and...
https://www.duplicati.com/

Unbelievable to me that this problem has been identified and unresolved after over 5 years with such a simple solution! How is that possible?

Meantime, my only "fix" is to set privacy.resistFingerprinting = False

I would also very much like for resistFingerprinting to have a specific option that'd let me toggle timezones specifically. It's not viable for me to be set to UTC, and it makes this feature significantly harder for me to use. I'll probably disable it again until this is hopefully resolved.

Maybe this should not be implemented as an additional built-in setting, as it may not make sense to give the option to avoid complete spoofing (even though still not perfect) and may confuse users (but they would already be kinda-advance users to know that).
That said, I wish there were a workaround for who would still want to take that "risk". The 2 add-ons that promised to do that do not work (anymore? or they never did). I could not find extensions or policy settings or hacks around, could be posted it here so people finding this bug would too.

I can't believe the arguments that have been provided against giving users control of choosing whether or not they want their timezone known.
There doesn't have to be more than 24 different time zones. UTC (?). Get it from computer clock or do a simple background calculation from a zone entered.
I am always amazed at the arrogance of someone thinking they know what is best for me. If others want UTC, let them keep it
If privacy.resistFingerprinting = True it does cause me problems, period.
So I have made it false and lost all the other advantages it offers. Gee, thanks for looking out for me.

RFP is NOT front facing in Firefox, it is for Tor Browser. No one is forcing you to use it.

There doesn't have to be more than 24 different time zones

This isn't true. If we were to cover all user's real timeZones + DST for all dates, there are 372 unique timeZones (from 468 supported timeZones in gecko - and any of those timeZones could change in future due to local laws, which is why they all exist). Anything less than that will cause potential wrong date/times (depending on the user's real timeZone). Even if we only took 2022+, there's still 71 unique timeZones, which is too many - having "24 timeZones" will cause "breakage" (and how does RFP decide which one to use) - so no matter what we do, we are going to "break" times for some people. 24 timeZones vs 1 timeZone is simply going to splinters users into 24 more buckets = adding entropy. The simplest and best solution is to only use one timeZone (zero entropy: all Tor Browser users are the same), educate users, and add site exceptions for RFP.

RFP is not officially "supported" in Firefox, and any changes are done in devs spare time - hopefully site exceptions will land in the future. But misunderstanding how the API and entropy and compat work, and posting complaints is not the answer

RFP is NOT front facing in Firefox, it is for Tor Browser.
There of many of us who don't use Tor, but would like to keep our fingerprint as small as possible.
No one is forcing you to use it.
I find that insulting. Your basically saying easy programing out weighs user preference.

I stand by the 24 time zones. Just add a feature in about:config to list a time zone and have Firefox figure out what UTC(?) that is. All 372 timezones have specific dates on when they change. If the date changes, there is advance warning. privacy.resistFingerprinting could then get that UTC(?) and present it.

No one would be forced to use the feature

This bug has been open for years, and has bitten me more often than anything else, especially with regards to planning things in various online calendars. No matter what I do, such as having a secondary profile without privacy.resistFingerprinting set, since my timezone is so close to UTC I consistently manage to forget about it and mess things up.
So, since I ritually build firefox from source, I figured I'd just fix this for myself. Turns out, it's fairly trivial to patch out: https://pastebin.com/raw/Z8Ma095i
With a hex editor, one may also look for the string "TZ=UTC" in libxul, and replace it with zeroes.
Of course this isn't anywhere near a real patch suggestion, and it'd be useful to make a real prefs toggle.

figured I'd also attach the file properly, sorry for the double-message.

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 18 votes.
:timhuang, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Nope

The spirit of this request will be possible with FPP, although we don't recommend fiddling the defaults (the default FPP behavior won't spoof Timezone, that I can say for sure) as it will make your fingerprint more unique.