The localized date string on Windows reveals local time

https://blog.torproject.org/blog/tor-browser-602-released#comment-191587 mentioned it first and https://blog.torproject.org/blog/tor-browser-65a6-released#comment-225152 pointed it out again:

On Windows the localized Date string reveals the local timezone (again). I reproduced that with an en-US 6.5a6 bundle on a Windows 7 machine. On my Linux box it is not an issue.

added TorBrowserTeam201701R component::applications/tor browser owner::arthuredelstein priority::high resolution::fixed severity::major status::closed tbb-6.0-issues tbb-fingerprinting tbb-regression type::defect labels

This regressed in Tor Browser 6.0. While the To Locale Format and To Locale String row showed the same string (e.g. "Thursday, December 15, 2016 10:00:00") in Tor Browser < 6.0 starting with 6.0 To Locale String differs AND shows the local time: "12/15/2016, Your-Local-Time".

Arthur can you take a look at it?

Trac:
Severity: Normal to Major
Keywords: N/A deleted, tbb-regression-6.0 added

Trac:
Keywords: tbb-regression-6.0 deleted, tbb-6.0-regression added

I wonder whether #15299 (moved) would have caught this...

Trac:
Keywords: tbb-6.0-regression deleted, tbb-6.0-issues, tbb-regression added

Trac:
Owner: tbb-team to arthuredelstein
Status: new to accepted

Trac:
Cc: arthuredelstein to arthuredelstein, brade, mcs

Moving our tickets to January 2017

Trac:
Keywords: TorBrowserTeam201612 deleted, TorBrowserTeam201701 added

http://browserspy.dk/date.php on Linux:

• the fields get filled only on low and medium-low security.

• "Time and Date" is UTC, unlike my system's time, but my hardware clock is also UTC.

• "Locale string" is always date +"%x, %r" in "en_US" format, unlike my system-wide setting.

• "Difference between server and PC time" is consistent across two Linux systems on the same machine, with +/-2 second variation. The difference was noticeably reduced after running ntpdate pool.ntp.org and refreshing the page.

Here's a patch for review, tested on Windows: https://github.com/arthuredelstein/tor-browser/commit/20981+1

Trac:
Status: accepted to needs_review
Keywords: TorBrowserTeam201701 deleted, TorBrowserTeam201701R added

r=mcs

I did not test the patch, but it looks plausible. And I guess it is okay to return malloc'd memory since that is done in other cases. Your patch might be a couple of lines shorter if you used uprv_strdup(), but that is not a big deal.

Replying to mcs:

r=mcs

I did not test the patch, but it looks plausible. And I guess it is okay to return malloc'd memory since that is done in other cases. Your patch might be a couple of lines shorter if you used uprv_strdup(), but that is not a big deal.

Thanks for reviewing it. That's a good suggestion. I've written a new patch using uprv_strdup and I will post it here later today once I am done testing.

I believe the malloc'd memory is necessary -- later code attempts to free it if I recall correctly.

Here's my new patch. I'm having trouble building Firefox on Windows at the moment (nothing to do with the patch), so I haven't had a chance to test it.

https://github.com/arthuredelstein/tor-browser/commit/20981+2

Replying to arthuredelstein:

I believe the malloc'd memory is necessary -- later code attempts to free it if I recall correctly.

Yes, in timezone.cpp:

#if U_PLATFORM_USES_ONLY_WIN32_API
    // hostID points to a heap-allocated location on Windows.
    uprv_free(const_cast<char *>(hostID));
#endif

Looks good to me. I tested the patch on a Windows machine and the issue is fixed with it.

Applied to tor-browser-45.6.0esr-6.5-1 (commit 025f08062d4e633432e0248bbd047ac5d61c4399). I guess this can make it into 6.5 as the patch is quite simple.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Trac:
Keywords: tbb-fingerinting deleted, tbb-fingerprinting added

closed

moved to tpo/applications/tor-browser#20981 (closed)