Timezone spoof issues

[h6a8ke1k]

Prerequisites

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed

Expected Behavior

The timezone spoof works as intended to apply intended timezone to every function to get time / timezone, and does not consume too much resource.

Current Behavior

The following items may be related to each other, so please read them all before any testing.

1. Uses too much resource (CPU and memory) on web pages that call new Date very frequently when the timezone spoofing is on (the timezone option is other than default).
   It seems that the reason is because the modifyDate function. See the profiling report below:
   
   The modifyDate function alone uses 65.80% computing time. And the web page becomes not responding after a while.
   An example of such web pages is: link
   It is in Chinese, but you can enable timezone spoofing and use task manager or the profiling tool in devtools in Firefox, and then click on the play button to play the video and see the effect.

2. When using default timezone, the timezone will be GMT+0 UTC instead of the real timezone. I think default timezone should be the real timezone instead of UTC. Moreover, if disable Chameleon from the popup (not disabling the entire extension from about:addons), the timezone is still GMT+0 UTC, which is clearly not intended.

3. When using default timezone, the resource usage is not very high even when new Date is called very frequently. However, the constructor of the replaced Date object still consumes a little large amount of computing time. If disable Chameleon from the popup, there is no such resource consumption.

4. When changing timezone option to some specific timezone, only calling Date() will return the intended timezone, and calling new Date() returns time in GMT+0 UTC timezone. I believe it is critical to make the latter one also return time in correct timezone because many websites use the latter method to determine your timezone. (I am not sure if this is related to the high CPU and memory usage on the website I mentioned in item 1 before.)

Context (Environment)

Firefox 68 ESR

[h6a8ke1k]

I guess I know the reason of Date() and new Date() returning time in UTC timezone:
It is also because I enabled "resist fingerprinting" option.

Here are more detailed behaviors:

1. Clean browser without "resist fingerprint" and Chameleon:
   Date() and new Date() are both real timezone.

2. Browser with "resist fingerprint" on and without Chameleon:
   Date() and new Date() are both UTC timezone.

3. Browser with "resist fingerprint" on and with Chameleon:
   Date() returns the intended timezone in Chameleon; if the timezone is default in Chameleon, the timezone will be real timezone.
   new Date() returns UTC timezone time.

4. Browser with "resist fingerprint" off and with Chameleon:
   Date() returns the intended timezone in Chameleon; if the timezone is default in Chameleon, the timezone will be real timezone.
   new Date() returns real timezone time. (not the one set in Chameleon)

So I think it should be the problem with not able to spoof the timezone when calling new Date() with the replaced Date object.

[sereneblue]

Hi @h6a8ke1k, thanks again for the detailed issue!

In your first post,

1. I know what's causing this issue; it's how Chameleon attaches extra info to a Date object to properly spoof it. I'll have to change the implementation but I can't guarantee that this will be in the next update because it may take some time.
2. This is because of RFP.
3. This happens because the Date object is replaced by a Proxy to detect when it's accessed. There is a performance hit for that but I'm sure I can replace it with something else.
4. This is actually not a bug. Are you checking the values in the dev console? What's actually being used on the page and what's shown in the dev console can be two different things! This also occurs when viewing some headers in the developer console. To verify this, check https://browserleaks.com/javascript. You can also try new Date().toString() to verify the timezone being used.

In your second post,
3. This is related to 4 above.
4. This is also probably related to 4 above.

[h6a8ke1k]

@sereneblue Thank you! I realized that it is not appropriate to use dev console to test these things now. Sorry for any confusion.

I know that the implementation change may be harder. So it is fine for me now. I am using the default timezone, although many pages will show wrong timezone with resist fingerprint on.

But since the web page is using more and more memory when new Date is frequently called, is it probably a problem with the Garbage Collection? If it is, are there some possible ways to dispose the objects more properly? (It eventually consumes so much memory that I believe it is similar to a memory leak.)

Thank you again for such a great extension!

[sereneblue]

@h6a8ke1k,

Don't worry about it. The dev console is the first place I'd look at too!

Yes, I believe the issue is with garbage collection, it does seem to be similar to a memory leak. This is a high priority issue, so I'll try to get it resolved ASAP.

Thanks a lot for the detailed issues. I wouldn't have been able to Chameleon this far without input from the community from users like you. :)

[sereneblue]

@h6a8ke1k It seems it wasn't a garbage collection issue but the Proxy being used. v0.20.3 should have significantly improved performance for timezone spoofing on bilibili. Although there is still a performance hit because window.Date is being overwritten, it's reasonable now and you generally shouldn't notice much of a difference.

[h6a8ke1k]

Thanks for your efforts! Unfortunately, I am still experiencing issues when testing using v0.20.4.

For youtube: after enabling spoofing, the memory consumption gradually increase if video is playing. After increasing 0.5GB or so, it drops back to normal level.

For bilibili: after enabling spoofing and play the video (with floating moving text above video), the memory consumption can still increase very quickly if the floating moving text is very dense. (Does not decrease automatically and causes high CPU consumption as well.) Please play the video for at least 20 seconds from the beginning to see the effect. I am using latest Firefox 68 ESR on Windows 10 with x86_64. The previous link is here for your convenience: link.

When disabling the spoofing, the memory consumption is flat for both (even if the floating moving text is very dense on bilibili).

I suspect that it is because the use of Object.assign in modifyDate? (just guessing) I do not know the reason or solution either.

[sereneblue]

@h6a8ke1k

I've figured out the cause of the performance issue. The root of the problem seems to be the toLocaleString function used in modifyDate. Apparently, it has to do a lookup for the locale. Replacing this function call with a cached Intl.DateTimeFormat object significantly improves performance. I've also done some refactoring on how timezone spoofing works so timezone spoofing performance should no longer be an issue in the next update. The bilibili link was much more convenient to use to debug this issue compared to the ArcGIS site. Once again, thank you; I really appreciate your debugging efforts.

[h6a8ke1k]

It is great that you have found the problem! I am happy that I can help you debug and resolve this issue.
I will definitely test if there are any other issues after the next version is released.
Thank you for your continuous efforts in protecting people's privacy!

[h6a8ke1k]

@sereneblue Hi, thanks for your update! I experience no issues visiting bilibili with timezone spoof on now.

However, I found another website with issues: https://web.archive.org/
Type in any url that has a record, e.g. google.com. Then the calendar page cannot load and it is consuming all of the CPU available.

Using the profiling tool of Firefox, it seems that there are some issues in modifyDate called from setDate. I do not know if the function is the root cause.

[sereneblue]

Hi @h6a8ke1k,

At a glance, this seems to be an issue with how timezone spoofing is implemented. That url is a pretty good test for the implementation. This is probably going to take a bit of work to fix so I won't be able to address it in the next update.

[travankor]

Separately, I noticed that timezone spoofing creates a notification on startup even when notifications are explicitly disabled. Mentioning here so I don't have to create a new issue for a minor problem.

[sereneblue]

@travankor Timezone spoofing is exempt from notifications except when IP is selected. This is done to inform users about what timezone is being used. Sometimes the IP location can be wrong or missing. In the latter case, UTC is used.

[travankor]

Interesting, but is there a reason why it doesn't use the OS's native notification system, such as notify-send on Linux/BSD?

[sereneblue]

@travankor It uses the WebExtension notifications API which does use the OS's native notification system. What type of notifications are you getting?

[travankor]

I can't reproduce this now, but there was an issue with firefox and dbus related to detecting notifications. The fallback mechanism is broken on at least wayland since the notification covers the entire screen. In any case, this is a bug with firefox.

[DGjone44]

If I am right then this issue is resolved. And current version is doing spoofing correctly and related to detected IP Location.

[sereneblue]

@DGjone44 There's still an issue with web.archive.org as mentioned here.