Open h6a8ke1k opened 4 years ago
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:
Clean browser without "resist fingerprint" and Chameleon:
Date()
and new Date()
are both real timezone.
Browser with "resist fingerprint" on and without Chameleon:
Date()
and new Date()
are both UTC timezone.
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.
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.
Hi @h6a8ke1k, thanks again for the detailed issue!
In your first post,
new Date().toString()
to verify the timezone being used.In your second post,
@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!
@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. :)
@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.
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.
@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.
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!
@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.
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.
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.
@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.
Interesting, but is there a reason why it doesn't use the OS's native notification system, such as notify-send
on Linux/BSD?
@travankor It uses the WebExtension notifications API which does use the OS's native notification system. What type of notifications are you getting?
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.
If I am right then this issue is resolved. And current version is doing spoofing correctly and related to detected IP Location.
@DGjone44 There's still an issue with web.archive.org as mentioned here.
Prerequisites
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.
Uses too much resource (CPU and memory) on web pages that call
The
new Date
very frequently when the timezone spoofing is on (the timezone option is other thandefault
). It seems that the reason is because themodifyDate
function. See the profiling report below: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.When using
default
timezone, the timezone will beGMT+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 stillGMT+0 UTC
, which is clearly not intended.When using
default
timezone, the resource usage is not very high even whennew 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.When changing timezone option to some specific timezone, only calling
Date()
will return the intended timezone, and callingnew Date()
returns time inGMT+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