Timezone is one of the canonical browser fingerprinting vectors, but as the Mozilla Wiki's Fingerprinting page put it, it is "Too useful to break." However, that doesn't say anything about the timezone name, which is a lot more unique: there are >300 timezone names while only ~40 timezone offsets. Indeed, timezone name is being used for fingerprinting (see this snippet from fingerprintjs).

Building on this insight, fmarier (Brave) proposed simplifying timezone names to one per timezone offset, like America/Toronto would become Etc/GMT+4. I think a further refinement to picking the most popular timezone name in that offset, like like America/Toronto becomes America/New York might reduce breakage even further.

I wrote a quick patch (with the above example) to show that this is possible: https://github.com/sgmenda/ideas/blob/main/simplify-timezones-to-resist-fingerprinting/simplify-timezones.patch

(In reply to sanketh from comment #0)

there are >300 timezone names while only ~40 timezone offsets

There are at least 374 distinct sets of timezone offsets when taking into consideration DST and covering all years - reducing to anything less than this will cause breakage

forgot to link the PoC: https://arkenfox.github.io/TZP/tests/timezones.html .. click [combine years]

from https://bugzilla.mozilla.org/show_bug.cgi?id=1364261#c27

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?

Alessandro, I misunderstood. I thought you meant applying a static mapped equivalent. Etc/GMT doesn't have DST. But if you assigned the right one based on the current DST, then sure, the "wrong time for half a year" wouldn't exactly apply.

But that still doesn't cater for non full-hours, e.g. Indian/Cocos today is UTC+06:30 (and literally thousands more examples of TZs and dates in past) and it lacks offsets - i.e your solution only applies to the current date