Hi Mark,
Thanks for responding.
It appears that this behavior is controlled by the privacy.resistFingerprinting option.
Setting it to false solves the problem on IceCat for the desktop,
but the problem persists on IceCatMobile (Android), regardless of the option.
(Even after clearing the app's Android cache, browser cache, and restarting the app.)
However, if I understand correctly, the IceCat team no longer works on IceCatMobile.
The IceCatMobile bug tracker seems inactive, though.
Regards,
Jelle
Hi Jelle,
Jelle Geerts <address@hidden> writes:
> var s1 = new Date().toString();
> var s2 = new Date().toLocaleString();
> var s3 = new Date().toLocaleString('nl', {'timeZone': 'Europe/Amsterdam'});
>
> The resulting strings were:
> s1 === 'Fri Jun 07 2019 13:58:32 GMT+0000 (UTC)'
> s2 === '6/7/2019, 1:58:32 PM'
> s3 === '7-6-2019 15:58:32'
>
> s1 is not as expected (bug).
> s2 is not as expected (bug).
> s3 is as expected.
>
> Expected output (taken from Firefox; Chrome has the exact same output):
> s1 === 'Fri Jun 07 2019 15:58:32 GMT+0200 (Central European Summer Time)'
> s2 === '6/7/2019, 3:58:32 PM'
> s3 === '7-6-2019 15:58:32'
Yes, I've known about this issue for some time.
I strongly suspect that this difference in behavior is caused by one of
the privacy-protecting changes that IceCat makes to Firefox 60 ESR's
default settings, which are listed here:
https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/settings.js?h=v60.7.0
For example, IceCat changes the default value of "geo.enabled" to false,
to disable geolocation. If you think about it, revealing the user's
local timezone to web sites via _javascript_ effectively allows a coarse
form of geolocation.
If it's important to you to reveal your local timezone to web sites, I
would suggest going into "about:config" and experimenting with reverting
some of these IceCat configuration changes, starting with "geo.enabled".
If you could report back with your findings, that would be helpful,
because you're not the first person to ask about this.
Thanks,
Mark