1826998 - DevTools console presents `new Date` in localized format, when it probably should use UTC, with privacy.resistfingerprinting = true

Status: NEW

(DevTools :: Object Inspector, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Set about:config pref privacy.resistFingerprinting to true
2. Restart Firefox.
3. Open web console (ctrl shift k) and type new Date()
4. Try that again but now explicitly stringify: (new Date()).toString()

ACTUAL RESULTS:
new Date() gets shown in devtools with your local timezone, implying that that's what its stringified/etc. version will be, and implying that the date has your timezone encoded in it.

(In contrast, (new Date()).toString() reports the date in UTC as-expected.)

EXPECTED RESULTS:
The response to new Date() should probably be shown in UTC, since I think that's how we have it encoded to reduce fingerprinting.

Comment 1

[Daniel Holbert [:dholbert]]

This affects the devtools autocomplete preview-text that gets shown below the prompt, too. If I type new Date() (or d where d is a Date) and don't hit enter yet, then that autocomplete text shows me the date stringified in my local timezone.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (load with `privacy.resistFingerprinting:true` and open web console)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase, showing UTC (expected) vs. my local PDT timezone (unexpected)

Comment 4

[Daniel Holbert [:dholbert]]

As far as I can tell, this isn't web-exposed -- all of the actual web-exposed APIs (at least toString() and getTimezoneOffset()) behave as if the local timezone is UTC.

But the true-local-timzeone is reported in DevTools console's "object-preview" text, as shown in my screenshot, and that's confusing for developers. And it's probably worth chasing to be sure we're not missing some case that we need to handle.

Comment 5

[Daniel Holbert [:dholbert]]

regression range: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b54d15de5072cd0e289d9a5331dd20d65773a8fb&tochange=6f4c845bf6aa3685427473dffe7e90503f80c03d

Before that range, the devtools UI from my comment 3 screenshot consistently uses UTC (there's no Pacific Daylight Time shown).

--> Regression from bug 1709867.

Comment 6

[Daniel Holbert [:dholbert]]

(I tried additionally setting privacy.resistFingerprinting.testing.setTZtoUTC to true in current Nightly, but that doesn't seem to make a difference here; I still get the same actual-results.)

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

:tschuster, since you are the author of the regressor, bug 1709867, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1709867

Comment 9

[Tom Schuster (MoCo)]

This is purely a devtools issue. For the eager evaluation it formats the numerical timestamp in the context of the devtools, which as privileged code will not have fingerprinting resistance enabled.

(I tried additionally setting privacy.resistFingerprinting.testing.setTZtoUTC to true in current Nightly, but that doesn't seem to make a difference here; I still get the same actual-results.)

Did you restart Firefox after setting the pref? I do want to remove this pref and code as soon as possible however.

Comment 10

[Tom Schuster (MoCo)]

Unrelated to the resist finger printing mode, I think we would also have the same issue when remote debugging a device in a different timezone. We should probably send along the timestamp and the timezone.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Tom Schuster (MoCo) from comment #9)

Did you restart Firefox after setting the pref?

I did. I just retested, and that pref actually does avoid this issue under one specific set of conditions. Starting with a fresh profile in about:config filtered for "resist"...
(1) Set privacy.resistFingerprinting.testing.setTZtoUTC to true
(2) Set privacy.resistFingerprinting to true
(3) Load the attached testcase (https://bugzilla.mozilla.org/attachment.cgi?id=9327566), or just directly execute new Date() in web console for about:config

If I do those^ steps in precisely the right order, then I do see a GMT+0000 (Coordinated Universal Time) presentation of the datestamp.

However: if I swap the order of steps 1 and 2, OR if I restart Firefox after setting the prefs, then I see my local timezone.

So there seems to be some statefulness based on whether privacy.resistFingerprinting.testing.setTZtoUTC was enabled, at the moment that privacy.resistFingerprinting goes from false to true.

I do want to remove this pref [the setTZtoUTC one] and code as soon as possible however.

Yeah, I only mentioned it because it seemed like it might've been a "belt-and-suspenders" way to work around this.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: screencast showing statefulness of `privacy.resistFingerprinting.testing.setTZtoUTC` in its impact on this bug

Here's a screencast with an extended version of the steps in comment 11.

I enable the prefs for resistFingerprinting (t=5s), and then for setTZtoUTC (t=10s), and then I disable resistFingerprinting (t=15s), and then re-enable resistFingerprinting (t=20s). Between each change, I evaluate new Date() in the console. They all show PDT (my local timezone) except at the very end, when I've (re)-enabled resistFingerprinting with the setTZtoUTC pref being already-enabled at the moment that resistFingerprinting becomes enabled -- that one shows the datestamp in Coordinated Universal Time. So our behavior seems to depend on the order in which you enable the prefs (and particularly on whether setTZtoUTC is enabled or disabled at the moment resistFingerprinting becomes enabled).