sereneblue / chameleon

WebExtension port of Random Agent Spoofer
https://sereneblue.github.io/chameleon
GNU General Public License v3.0
507 stars 53 forks source link

Chameleon Not Displaying TimeZone & Language Relative To My Proxy IP #540

Closed Kraxys closed 2 years ago

Kraxys commented 2 years ago

Prerequisites

Please use issues for bugs only! Answer the following questions for yourself before submitting an issue: YOU MAY DELETE THE PREREQUISITES SECTION.

Expected Behavior

I use SSH proxies on my browser, and select wich one I want to use with FoxyProxY. Chameleon should indicate the Language and Time zone relative to my SSH Proxy IP.

Current Behavior

When I use a middle/low en laptop with SSH proxies, or when my internet connection is not fast enough, Chameleon indicates TimeZone and Language associated with my ISP IP. I then have a few second later to click on Chameleon icon, click on the gear -> Ip rules -> reload IP Info. Then the correct faked data are displayed on Chameleon icon. But having to do that every time I launch my browser is very annoying (and sometime, I forget).

It seems that initially, Chameleon connects to ipapi.co bypassing my ssh proxy settings, and so the time zone/Language it retrieves is the one associated to my ISP IP, and not the one associated with my proxy IP as it should..

I think it's not really a bug, but a serous inconvenience due to the fact that probably Chameleon is asking ipapi.co before my proxy (I use FoxyProxy for that) is completely set.

So why not implement in Chameleon an adjustable delay (in seconds) before asking ipapi.co?

Optionally and for added security, you could give the user the possibility to block any (browser related) network activity until the information from ipapi.co have been retrieved?

Relevant settings

"config": { "enabled": true, "notificationsEnabled": true, "theme": "light", "hasPrivacyPermission": true }, "excluded": [ "win1-edg", "win1-ie", "win4-edg", "win3-ie", "win3-gcr", "win4-ie", "win2-edg", "win3-edg", "win2-ie", "win2-gcr", "win1-gcr" ], "headers": { "blockEtag": true, "enableDNT": false, "referer": { "disabled": false, "xorigin": 0, "trimming": 2 }, "spoofAcceptLang": { "enabled": true, "value": "ip" }, "spoofIP": { "enabled": false, "option": 0, "rangeFrom": "", "rangeTo": "" } }, "ipRules": [], "options": { "cookieNotPersistent": false, "cookiePolicy": "reject_trackers_and_partition_foreign", "blockMediaDevices": true, "blockCSSExfil": true, "disableWebRTC": true, "firstPartyIsolate": false, "limitHistory": false, "protectKBFingerprint": { "enabled": true, "delay": 67 }, "protectWinName": false, "resistFingerprinting": true, "screenSize": "profile", "spoofAudioContext": false, "spoofClientRects": false, "spoofFontFingerprint": true, "spoofMediaDevices": false, "timeZone": "ip", "trackingProtectionMode": "always", "webRTCPolicy": "disable_non_proxied_udp", "webSockets": "allow_all" }, "profile": { "selected": "windows", "interval": { "option": 0, "min": 1, "max": 1 }, "showProfileOnIcon": true }, "version": "0.22.33.1", "whitelist": { "enabledContextMenu": true, "defaultProfile": "none", "rules": [ { "id": "112dfc90-82c7-49a0-b098-684553e5b869", "name": "Ygg", "sites": [ { "domain": "www3.yggtorrent.nz" }, { "domain": "www3.yggtorrent.re" } ], "lang": "en-US", "profile": "default", "spoofIP": "", "options": { "audioContext": false, "clientRects": false, "cssExfil": false, "mediaDevices": true, "name": true, "ref": false, "tz": true, "ws": false } }, { "id": "5b2881c0-ad95-43d3-b6c0-45612c640851", "name": "Subscene", "sites": [ { "domain": "subscene.com" } ], "lang": "en-US", "profile": "none", "spoofIP": "", "options": { "audioContext": false, "clientRects": false, "cssExfil": true, "mediaDevices": true, "name": false, "ref": false, "tz": true, "ws": false } } ] } }

Context (Environment)

FF 103 on W10 64

sereneblue commented 2 years ago

Hi @Kraxys,

I did some research and it seems to be an issue with how Firefox loads addons. Network connections can be made before the proxy is established. More info can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=1501159

So why not implement in Chameleon an adjustable delay (in seconds) before asking ipapi.co?

Good idea. I'll improve the workflow to make it more convenient to reload IP info as well.

Optionally and for added security, you could give the user the possibility to block any (browser related) network activity until the information from ipapi.co have been retrieved?

You need a kill switch for proxies when using an extension to load them. I did some testing and it looks like you can set a fallback proxy (localhost, random port) in your Firefox settings to prevent an IP leak. Testing with FoxyProxy, the startup request made by Firefox to http://detectportal.firefox.com/canonical.html was routed to a local proxy before FoxyProxy kicked in.

sereneblue commented 2 years ago

@Kraxys This has been added in v0.22.34. The startup delay can be found under the IP rules tab on the options page.

Kraxys commented 2 years ago

Thank you very much for your reactivity! 👍

Sent with Proton Mail secure email.

------- Original Message ------- On Monday, August 29th, 2022 at 12:47 AM, sereneblue @.***> wrote:

@.***(https://github.com/Kraxys) This has been added in v0.22.34. The startup delay can be found under the IP rules tab on the options page.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

Kraxys commented 1 year ago

Hello @Sereneblue,

The trick with the "proxy killswitch" plus the new adjustable delay feature in Chameleon should completely solve the problem I told about on the issue tracker.

But there could be other similar problems: even with the proxy killswitch, some network connections might be made before Chameleon kicks in (for example if the adjustable delay is set to a too high value.. but what is a " too high value" exactly?).

To solve all these kind of problems, Chameleon should block all network activities (except to ipapi.co of course) until all its job is done. But is such a thing possible? I have absolutely no idea. Nevertheless, I just realised that in ublockO, there is a list named "Suspend network activity until all filter lists are loaded", so, at least to some extent, it might be possible for an extension to "block all network activity until ". What is your opinion about that?

Regards

Sent with Proton Mail secure email.

------- Original Message ------- On Thursday, August 25th, 2022 at 1:33 AM, sereneblue @.***> wrote:

Hi @.***(https://github.com/Kraxys),

I did some research and it seems to be an issue with how Firefox loads addons. Network connections can be made before the proxy is established. More info can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=1501159

So why not implement in Chameleon an adjustable delay (in seconds) before asking ipapi.co?

Good idea. I'll improve the workflow to make it more convenient to reload IP info as well.

Optionally and for added security, you could give the user the possibility to block any (browser related) network activity until the information from ipapi.co have been retrieved?

You need a kill switch for proxies when using an extension to load them. I did some testing and it looks like you can set a fallback proxy (localhost, random port) in your Firefox settings to prevent an IP leak. Testing with FoxyProxy, the startup request made by Firefox to http://detectportal.firefox.com/canonical.html was routed to a local proxy before FoxyProxy kicked in.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

sereneblue commented 1 year ago

But there could be other similar problems: even with the proxy killswitch, some network connections might be made before Chameleon kicks in (for example if the adjustable delay is set to a too high value.. but what is a " too high value" exactly?).

As long as the requests are going through FoxyProxy once you have the killswitch in place, I think it's safe to assume that Chameleon is also running. The delay is only used to configure the language header and timezone values if you're using those options. The most that could leak from a network request is the language but I'd think the delta between these events make this very unlikely.

This is my understanding of what's going on:

T1 ***** T2 ** T3

T1 = Open Firefox T2 = FoxyProxy sets up proxy T3 = Chameleon loaded (this could be first, so use the delay to resolve)

The delay that you use should probably be under a second. It doesn't really do much if Chameleon loads after FoxyProxy but should be helpful if you switched T2 and T3 above.

I don't see the need to suspend all requests.