Open Bug 1491343 Opened Last year Updated 7 months ago
Time is incorrect when the instance is opened via about:profiles in another profile with privacy
.resist Fingerprinting enabled
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.
Apparently the environment variable set in  is inherited in this case.  https://searchfox.org/mozilla-central/rev/dd965445ec47fbf3cee566eff93b301666bda0e1/toolkit/components/resistfingerprinting/nsRFPService.cpp#833
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?
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?
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.
I had forgotten that mobile does not use e10s.
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 , however the problem here is how to update when switching privacy.resistFingerprinting on and off since it cannot access preference directly within the file.  https://searchfox.org/mozilla-central/rev/72b1e834f384a2ffec6eb4ce405fbd4b5e881109/js/src/builtin/intl/DateTimeFormat.js#253
Whiteboard: [fingerprinting-breakage] → [fingerprinting]
Assignee: xeonchen → nobody
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]
You need to log in before you can comment on or make changes to this bug.