Closed Bug 1491343 Opened 6 years ago Closed 3 years ago

Time is incorrect when the instance is opened via about:profiles in another profile with privacy.resistFingerprinting enabled

Categories

(Core :: Security, defect, P3)

Product:
Core
Component:
Security
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1709867

People

(Reporter: xeonchen, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fingerprinting][fp-triaged])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20100101 Steps to reproduce: 0. make sure your computer's timezone is not in UTC+0 1. prepare 2 Firefox profiles: * Profile-A set privacy.resistFingerprinting to true, * Profile-B set privacy.resistFingerprinting to false. 2. open Firefox with Profile-A, browse to about:profiles 3. launch Profile-B from the tab opened in 2. 4. in Profile-B, open "web console" from web developer tools 5. execute |(new Date()).toLocaleString()| in the console opened in 4. Actual results: It shows UTC time. Expected results: Local time is expected.
Whiteboard: [fingerprinting]
Whiteboard: [fingerprinting] → [fingerprinting-breakage]
Tim, does this issue occur only in timezone spoofing? Do we use the same technique (setting environment variable) in any other fingerprinting protection mechanism?
Flags: needinfo?(tihuang)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
So far, the time zone spoofing is the only fingerprinting protection which is using the environment variable. In my opinion, we might be able to not rely on this way to spoof time zone. I think we can virtually change the timezone by directly spoofing js Date object. However, I don't know that whether the Date object is the only place reveals the time zone. If it is not, we need to find them all. Otherwise changing the environment variable is a safe approach that we can sure time zone will never be revealed. What do you think, Arthur?
Flags: needinfo?(tihuang) → needinfo?(arthuredelstein)
Hi Tim -- I think patching JS instead might be a good idea. Change the env variable has unfortunate side effects on chrome code in general. Other places we would need to patch include: * Intl.DateTimeFormat() [no locale argument] reveals the locale by the way it formats dates and also via Intl.DateTimeFormat().resolvedOptions().timeZone * Date/Time picker variants: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/week https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/month It's important that we don't miss any other APIs! I guess a drawback of the JS API-patching approach is that we need to keep looking out for new APIs that might expose the timezone. One other idea that occurs to me: could we apply the env variable to content processes only?
Flags: needinfo?(arthuredelstein)
I think we can only apply the env variable to content processes only and indeed it is a good idea. However, it will not work for the non-e10s mode. So, does Tor browser fully use e10s? If the answer is yes, then we can go this approach.
Flags: needinfo?(arthuredelstein)
I had forgotten that mobile does not use e10s.
Flags: needinfo?(arthuredelstein)
Assignee: nobody → xeonchen
There are two implementations of time API, one uses ICU and the other is not. To update the time zone implementation with ICU can be overridden in [1], however the problem here is how to update when switching privacy.resistFingerprinting on and off since it cannot access preference directly within the file. [1] https://searchfox.org/mozilla-central/rev/72b1e834f384a2ffec6eb4ce405fbd4b5e881109/js/src/builtin/intl/DateTimeFormat.js#253
Blocks: fingerprinting-breakage
Whiteboard: [fingerprinting-breakage] → [fingerprinting]
Assignee: xeonchen → nobody
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]
Blocks: 1462115

however the problem here is how to update when switching privacy.resistFingerprinting on and off

I don't think this needs a new ticket (I am not an expert) but in a SINGLE profile... I can pick up on two issues with RFP & TZ spoofing when toggling the pref.

Test Site: https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#language
Assumption: Your real timezone is not UTC 0

Issue One: (when FF is started with RFP=true)

  • set RFP = true
  • restart browser
  • load test: TZ spoof is effective
  • set RFP = false
  • click [re-run tests]: TZ spoof is still effective
  • expected results: TZ spoof should not be used

Issue Two: (when FF is started with RFP=false)

  • set RFP = false
  • restart browser
  • load test: you will show your local time etc
  • set RFP = true
  • click [re-run tests]: TZ spoof is only partially effective
    • Intl.DateTimeFormat still shows local time (as seen in formatToParts)
  • expected results: TZ spoof should cover Intl.DateTimeFormat

Is there any reason why Intl.DateTimeFormat is not picked up on when turning the pref on (i.e was something missed, or is this a symptom of the bigger underlying issue re environment variable?)

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.