Open Bug 1364261 Opened 4 years ago Updated 6 months ago

Make UTC Timezone Spoofing optional when privacy.resistfingerprinting = true

Categories

(Core :: General, defect, P3)

51 Branch
defect

Tracking

()

REOPENED

People

(Reporter: emceeaich, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [tor][fingerprinting-breakage][fp-backlog][fp-triaged])

Because many pages use JavaScript to format timestamps and epoch milliseconds (for example FastMail and the kexp.org realtime playlist) the timezone spoof can lead to misleading information a page when resistFingerprinting is enabled. 

In the tracking bug for resistFingerprinting, https://bugzilla.mozilla.org/show_bug.cgi?id=1333933#c3, it's suggested that that strict and loose forms of fingerprinting be enabled.

I recommend making UTC timezone spoofing part of the strict set of measures, and advising users of this in preference panes.
Priority: -- → P2
Whiteboard: [tor][fingerprinting]
I vote against it: anti-fingerprinting settings are fingerprintable themselves. Instead I think we need to extend the spec for empty time tags with datetime and lang attr for machine-synthesized local datetime on any locale (I don't think it is very hard to create a library formatting date and time for every locale) and encourage Web devs to use it for displaying correct local time to a user. Measures should be taken to prevent direct (like textContent, or screenshot) and side-channels (sizes) leaks of time, its format and timezone.
Whiteboard: [tor][fingerprinting] → [tor][fingerprinting][fp-backlog]
Note that changing the timezone alone does not have a terribly large effect on reducing the efficacy of fingerprinting: the combination of metadata with a UTC timezone vs. the combination of metadata with a non-UTC timezone (given the number of users in quite a number of high population timezones) doesn't really make a lot of difference: for tracking purposes the timezone is not a geolocator, it's simply a stable string to work into a digest and this change replaces one stable string with another stable string. Unfortunatly, it also "breaks" any website that relies on a reliable Date object for presenting the user with time-stamped information (notable example: gmail).

Adding a level of finer control would be super useful here: keep privacy.resistFingerprinting, but with a set of finer detail flags as well, such as privacy.resistFingerprinting.hideLocale so that it's not an all-or-nothing deal: if I would like sites to not tap into my canvas2d for finger printing (which makes a whole lot of sense), but would like to make sure that information that relies on an accurate clock is correct, having the level of control needed to affect that is probably worth the extra flags.
Duplicate of this bug: 1420234
See Also: → 1426232
Whiteboard: [tor][fingerprinting][fp-backlog] → [tor][fingerprinting-breakage][fp-backlog]
Priority: P2 → P3
Whiteboard: [tor][fingerprinting-breakage][fp-backlog] → [tor][fingerprinting-breakage][fp-backlog][fp-triaged]
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1431909
I guess this is duped to a wrong bug.
Duplicate of bug: 1401440
Shouldn't this bug *block* bug 1401440 rather than be a duplicate?  That bug is hard to read since fingerprinting wasn't mentioned until its fifth comment and it wasn't abstracted beyond window dimensions until its ninth comment.  

This is all the more pertinent since bug 1401440 never mentions time zones.  Bug 1401440#c16 is the only mention of times in the entire conversation so far, and its not even directly related to time zones.

I still see the current purpose of bug 1401440 as being both a tracking bug for the concept of separable anti-fingerprinting items *and* as a request for migrating the window size portions into such a separated anti-fingerprinting item.  In that case, this bug should depend on the tracker bug alongside the window size separation request.
slack will also be affect of this option that it will show timing of message according to browser timezone, which I feel this will be a major drawback when we promote Firefox in office with more privacy idea.
@Irvin - You want to look at Bug 1426232 - similar to privacy.resistFingerprinting's (RFP) canvas protection. When RFP=true then you can set a site permission to allow. And the default is hardcoded for best protection (i.e no UI or pref for it). This is the best solution in my opinion for overcoming some usability issues with RFP.

At the moment, canvas "breaks" things, but time zone spoofing should only be an "inconvenience" (e.g. being given the wrong time for an event). But I totally get that it messes up content flow, so "breakage" kind of fits as well - e.g. email replies dated prior to the original because different devices/browsers used). Time Zone spoofing would be about the only other RFP feature I can think of right now that could do with a site exception. But anyway, try Bug 1426232

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.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Depends on: 1401440

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.)

Duplicate of this bug: 1577947

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.

You need to log in before you can comment on or make changes to this bug.