Fingerprinting 3.0: Simplified timezones

[fmarier]

Websites can query the user's timezone using the window.Intl.DateTimeFormat() API:

> new window.Intl.DateTimeFormat().resolvedOptions().timeZone
America/Vancouver

We could try reduce the fingerprinting surface by normalizing timezones so that for example, both America/Vancouver and America/Los Angeles get simplified to Etc/GMT+7 (or Etc/GMT+8 depending on daylight saving) when using that API.

There is a related timeZoneName option, but returns undefined in my browser.

I don't think that this would be noticeable to users, but it would reduce the total number of timezone buckets that exist. Especially valuable for people who live in small regions which happen to have their own timezone.

(as suggested in #11866, we could also consider randomizing timezones )

[initsecret]

Do user agents typically report Etc/GMT* timezones? Picking the most popular timezone name in that timezone (like simplifying America/Vancouver and America/Toronto to America/Los Angeles and America/New York respectively) might reduce breakage while keeping the same anonymity sets.

[tiagovignatti]

Hi there! I did some hacking to farble the timeZone endpoint in particular. My code is breaking the larger Intl.DateTimeFormat API (which's probably not so wise) and also is requiring extensive testing on real-world websites to make sure such farbling makes sense. Anyhow, the three different farbling levels settings are implemented and the expected output is actually working in practice in the following branch:
brave/brave-core@master...tiagovignatti:timezones-farbling

I won't continue doing this work further, but I hope it serves a bit for someone to advance the idea. Thanks! 😃

[pes10k]

Thanks much @tiagovignatti neat stuff. Appreciate your work here, and I'm sure this will be helpful when we get to this issue!

@sgmenda if / when we implement this, i expect that, at least as a first step, we'll start by making changes to the most aggressive fingerprinting protections, and having the browser report a randomly selected timezone in the same time-zone-equiv-set, but thats all TBD.

[specter78]

Firefox, when RFP is enabled, sets timezone to UTC+0. Maybe that can be done.

When using timezone other than this (such as using proxy/vpn), browser's ip needs to be taken into consideration for setting timezone, else it can make browser more unique.

[fmarier]

Firefox is also considering changes to their timezone spoofing: https://bugzilla.mozilla.org/show_bug.cgi?id=1709867

[pes10k]

Closing because this is no longer plan of action (since farbling timezones in this manner would introduce difficult to diagnose webcompat issues with calendar apps and similar). The main problem is that geo-based timezones can change between different ETC+ representations during the year.

[fmarier]

since farbling timezones in this manner would introduce difficult to diagnose webcompat issues with calendar apps and similar

I agree that farbling/spoofing is the wrong thing to do here, mainly because of geo-political implications, I think whether or not the calendar webcompat problems are real is something we should test. We suspect they exist, but we don't know for sure.

The main problem is that geo-based timezones can change between different ETC+ representations during the year.

That would be the same thing as travelling. Your browser would always provide the correct UTC offset, it would just happen to change twice every year if you live in an area with daylight saving.

We can mark this issue as low-priority, but there is something left to explore/test.

[pes10k]

i dont have a preference between closing and marking P5, and im interested in finding a solution to this.

That would be the same thing as travelling. Your browser would always provide the correct UTC offset, it would just happen to change twice every year if you live in an area with daylight saving.

The difference here is that if i report my time as America/Chicago, google calendar (or whatever) knows to set the calendar event as America/Chicago, and so the time on the calendar will be correct across daylight savings times, etc. But if my browser reports it as ETC-06:00 (or whatever), then that calendar event (or whatever) will be wrong 50% of the year

[fmarier]

But if my browser reports it as ETC-06:00 (or whatever), then that calendar event (or whatever) will be wrong 50% of the year.

Except that the browser would set it to ETC-6 for half of the year and then ETC-5 (or whatever) for the other half of the year. Similar to how it's changing from America/Chicago to Europe/Paris if you take an overnight flight to Paris. The browser would be reporting the correct UTC offset in both cases.

[pes10k]

Follow up: @fmarier to manually test whether Google Calendar (or some other equiv popular calendar web app) uses the reported timezone (offset or geo) when creating records / events. If yes, then this approach wont work (bc it'll have the off-by-one errors mentioned in #8574 (comment)). If no (if it seems calendar apps don't use the now-browser-reported offset equiv (ETC+600 or whatever) then this idea still has legs and we should move forward with prototyping and further testing

[fmarier]

Pete and I talked about this and what we need to test to determine whether or not this is a viable idea is this:

1. creating calendar events with an Etc/... timezone
   -2.displaying existing calendar events with Etc/... timezone

and making sure that both work as expected.

[pes10k]

just to follow up here, whats needed is more than the above. Whats needed is to know if, when the browser is set to an Etc timezone, creating a calendar event uses the Etc/ timezone, or whether the calendar app otherwise uses the user's Geo timezone.

(if the calendar app uses the user's geo-timezone, thats good, it means this approach might work. If the calendar app uses the Etc/ timezone the browser reports, thats bad, since it means the etc/ approach will introduce errors if there are multiple geographic-timezones, following different daylight savings time rules, in the same Etc/ offset.)