Open Bug 1364261 Opened 5 years ago Updated 1 month ago
Make UTC Timezone Spoofing optional when privacy
.resistfingerprinting = true
Priority: -- → P2
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.
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: 4 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 comment 16 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
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
You need to log in before you can comment on or make changes to this bug.