AstroSkipper

The @AstroSkipper types! Nice description! I sincerely hope it was meant in a friendly way.

Same in New Moon 28. After setting security.ssl3.rsa_aes_128_gcm_sha256 to true, MEGA downloads are working again.

You are absolutely right. This entry was pre-configured, and I forgot to remove it. I thought my config file was clean. I do have a lot of these config files. Anyway! Good find! After removing it works indeed. So, the problem is really cipher related.

The cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256 was already implemented in ProxHTTPSProxy 1.5.220717. I tried to connect to Mega using Serpent 55 via ProxHTTPSProxy 1.5.220717, and the download of files didn't work, either. Same issue as without using the proxy. Therefore, I think the problem is presumably not only a cipher incompatibility.

Interesting news! ProxHTTPSProxy can only be used by programs which offer an option to use the IE proxy settings as for example browsers or use system components if the proxy has been set system-wide. From now on, we have the possibility to connect any program with a server or the internet via the local proxy ProxHTTPSProxy if necessary, of course including the latest protocol TLS 1.3. The solution is SocksCap64. I have already tested this tool, and it works perfectly with ProxHTTPSProxy. Link: https://www.sockscap64.com/homepage/ Cheers, AstroSkipper

I have tested FreeCap and SocksCap64 for suitability. I set up ProxHTTPSProxy as the proxy server and Iceape-UXP as the program that should exclusively use this proxy server via FreeCap or SocksCap64. The results were very different. FreeCap works with a local proxy like ProxHTTPSProxy more badly than well, SocksCap64 on the other hand has no problems with a local proxy like ProxHTTPSProxy and and works perfectly together with such a proxy. Therefore, my recommendation is definitely SocksCap64.

Just an idea! What about establishing a VPN connection to circumvent ForcePoint's censoring? If a VPN connection is established, all @roytam1's browser with their own TLS 1.3 clients (set to No Proxy, of course) use this connection. Maybe, OE Classic, too. ForcePoint actually shouldn't notice a connection to www.oeclassic.com via VPN.

And on raymond.cc, there is a further recommendation called WideCap: http://web.archive.org/web/20130228172919/http://widecap.ru/files/widecap_setup.en.1.4.exe This tool is abandoned, too, but although it was originally payware, it was changed to freeware in the past. In my system, I have installed Proxifier for a long time. It's not free of charge but IMHO it's one of the best.

These commands can't be executed in Windows XP where you have to use proxycfg.exe instead. Your commands work only on Vista, 7 and up.

As far as I can see, you can try to set ProxHTTPSProxy systemwide by the command proxycfg -u. If it doesn't help, you can revert this by the command proxycfg -d. And did you try in the IE Proxy Settings only the setting of HTTP in combination with the option "Use the same proxy server for all protocols"? Anyway! Software which can't be activated easily is actually not worth its money. Maybe, you should try to get a refund. BTW, @roytam1's suggestion to use ProxyCap sounds promising in any case, though.

@Mathwiz! In which way did you set ProxHTTPSProxy as a systemwide proxy in Windows XP?

@NotHereToPlayGames! Nice to see that you followed my suggestion to offer a special version for Windows XP users after all. Although I no longer need this version and have already rebased the chrome.dll file in my installation of 360Chrome 13.5 build 1030, I'm sure other users here will be happy about a RAM-friendly version for Windows XP. Or did you do other changes except rebasing the chrome.dll file?

I use different profiles for all my browsers. No sharing of profiles anymore for years. In the past, I made bad experiences with shared profiles which became suddenly corrupted. And I always keep backups of important profiles to be on the safe side. Happy New Year, too

The information I researched was actually intended for @UCyborg relating to the browser and our conversation here. So on-topic, unlike so many other posts here. You are welcome to post the problem on the WiseVector StopX forum, but it is not official and therefore not really helpful. But, as I explained in my last post, for me personally, the problem is already solved after rebasing the chrome.dll file. And BTW, the culprit of my BSOD was not my computer. Maybe, you should read my posts again. I think you missed something.

My mainly used browsers in Windows XP are the @roytam1's browsers New Moon 28, Serpent 52, Serpent 55 and @feodor2's browser Mypal 68. Additionally, I use @NotHereToPlayGames's modified browser 360ChromePortable 13.5.1030 rebuild 6 with a chrome.dll rebased by me, only if the others fail on a specific website.

@UCyborg! I removed all exclusions made for 360Chrome v13.5 build 2022 in WiseVector StopX. Running again this browser with the rebased chrome.dll does not cause a BSOD anymore. Therefore, my assumption that rebasing chrome.dll might avoid such conflicts is presumably correct. q.e.d.

This is a quotation from https://www.mandiant.com/resources/blog/six-facts-about-address-space-layout-randomization-on-windows: Important parts are marked by me in bold type.

I thought Windows XP wouldn't be able to rebase dll files in its memory due to the lack of the ASLR feature and would always load these files to their predetermined addresses.

I had only BSODs in the past when starting one of the 360Chrome browsers which had a conflict with WiseVector StopX. Only a total exclusion of all 360Chrome installations in WiseVector StopX helped to avoid further BSODs. And I never had any other BSODs before. My system is flawless, so to speak, at least there are no discernible problems. I assume that rebasing chrome.dll might avoid such conflicts. In any case, I will test this again. BTW, I never said that rebasing is a culprit of whatever. Quite the opposite! I think you have misunderstood something.

@NotHereToPlayGames! As I reported weeks ago, I observed BSODs on my Windows XP system when starting one of the 360Chrome versions, caused by WiseVector StopX. Now, I checked the used memory addresses in my system and found out that WiseVector StopX loads the file WiseVectorHelperOne_X86.dll at the default address 0x10000000 of chrome.dll. I think that was the reason for the BSODs. Therefore, a rebasing of chrome.dll is mandatory for those Windows XP users who use WiseVector StopX.

My suggestion to offer a special rebased version for Windows XP users is due to the fact that this thread only targets the version 360Chrome 13.5 build 2022. This version is rather a poor choice for Windows XP users on old, low-powered hardware. Therefore, a rebased version of, say, 360Chrome 13.5 build 1030 would be more suitable for these users. So only one additional version would have to be provided. All Vista users do not need a rebased version, they have the ASLR feature. And all users of Windows 7 and higher do not need this browser anyway. Anyway! Ultimately, it is solely your decision. I personally switched to the version 360Chrome 13.5 build 1030 which I already rebased.

I have also already downloaded the ReBase tool from the Windows SDK. When I have time, I will try that out as well.

Hello @NotHereToPlayGames! Since I was the one who discovered and documented the abnormal RAM consumption of the 360Chrome browser in Windows XP, for which I received extremely friendly comments in this thread at the beginning, then called for further investigations and researched the causes, I will now take a look at the state of play. First, the good things. For all Windows XP users who really need this browser, i.e. who want or need to run old, low-powered hardware for which this Windows OS is the last compatible one, the method of rebasing the chrome.dll is an excellent stroke of luck to put an end to the memory hunger of this browser. Thanks again to @UCyborg and @mixit for their tips! I have now rebased the chrome.dll file in all my 360Chrome installations. I was able to reduce the RAM consumption of 360Chrome 13.5 build 2022 by almost 85%. That is truly enormous. It's almost beyond belief! Now, the bad things. For me, the time it takes to start a browser is totally unimportant and frankly irrelevant. What is much more important is the loading behaviour of websites in general when the browser has already been started. And that's where this browser doesn't look good at all. Many websites take eternities for being loaded if at all. It is not uncommon for the endless loading process to end in an error page. Not comparable to @roytam1's UXP or moebius browsers at all! That would be much more of a cause to be concerned. Anyway! If I were you, I would leave all 360Chrome editions for users of Windows Vista and higher as they were. For Windows XP users, however, I would offer a separate version in which the chrome.dll file has been rebased in any case. The reason for such a procedure is the ASLR feature, which all Windows versions from Vista onwards have, but unfortunately Windows XP lacks. On the subject of rebasing, you can certainly test which address is best suited for this procedure. Personally, I have done it automatically with libase. And that seems to be sufficient, at least for me. However, I hardly think that this will improve the loading behaviour of websites on old, low-powered hardware. In any case, I couldn't notice any improvements in the loading behaviour of websites on my system. This is probably more of a browser-specific problem which presumably can't be solved without further measures as for example recoding, code changes or code optimizations. And I doubt that 360Chrome 13.5 build 2022 is the best suited version for Windows XP. For example, 360Chrome 13.5 build 1030 seems to be better suited as far as I can observe in my case, according to the 360Chrome rule: the newer, the worse.

My Windows XP system runs like a charm without any errors. We have an interesting range of working browsers which are constantly being further developed, and a lot can be done on such a system. Windows XP is a perfect Windows OS for old, underperforming computers. I hope this OS will live forever.

Dito!