VistaLover

... Apologies are in order , it appears to be a "mea culpa" case; I have edited my original post accordingly :

... You're most welcome ! ... On the contrary, I became an avid fan of them since my beginnings in web navigation ; it was an era when full-blown VPNs were mostly unavailable to non-enterprises or too pricey for individuals, while open (read: misconfigured) HTTP(S) proxies could be easily found via a web search ; PACs offer a convenient way to selectively proxy only certain hosts/domains/etc. out of your total of web requests; was very handy on geo-fenced media portals/services in the ealry 2010s, where you had to (first identify and then) only proxy their geo-location checking scripts, with the media streams themselves (video and/or audio) being accessible "DIRECT"; now, 99.5% of these same media portals, free and paid for, geo-block fully their streams and also encrypt them with DRM ... PACs were also useful when you were employing a paid-for Proxy, but charged by proxy traffic or had quotas imposed on your use of it; by selectively proxying only those hosts that were inaccessible from your physical location, you could use less proxy bandwidth in a given time frame or squeeze more out of your proxy quota... This scenario involved use of proxies to unlock geo-fenced services (or ones regime-censored); if you were using a proxy for privacy reasons, then PACs were less applicable... Already known to me ; below, just for you, some PAC-related documentation, retrieved from my huge set of bookmarks: https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_(PAC)_file https://learn.microsoft.com/el-gr/archive/blogs/ieinternals/understanding-web-proxy-configuration https://superuser.com/questions/191037/local-pac-file-url-format-that-works-with-ie-and-safari-windows https://blog.mikejmcguire.com/2014/05/07/using-proxy-auto-configuration-scripts-with-internet-explorer-11/ https://support.microsoft.com/en-us/topic/how-to-disable-automatic-proxy-caching-in-internet-explorer-92735c9c-8a26-d0d8-7f8a-1b46595cbaba http://io.mysq.to/pac-file-and-proxy-auto-switch-for-firefox-ie11-and-chrome https://calomel.org/proxy_auto_config.html https://www.websense.com/content/support/library/web/v76/pac_file_best_practices/pac_file_best_practices.pdf The IEx articles relate to configuring a Windows "system proxy" (which can then be used by Chromium and its derivatives) ... End of off-topic ...

@Anbima : It is still unclear to me (and probably to the rest of the members trying to help you ) what exactly you're trying to accomplish here ... 1. Are there specific HTTPS URLs that fail to load on your 360EEv13.5 copy under your XP set up? 2. Are you concerned that the browser will load HTTPS sites under plain HTTP (and you're afraid sensitive/private info of yours will be sniffed?) - it's my understanding that a secure connection will either succeed or fail altogether... AstroSkipper has provided you with one-click sloution(s) for when you want to go through the HTTPSProxy and when NOT (however, the proxy should always be running, you do get that ) ... As already told, the proxy comes with a "[BYPASS URL]" section inside its "config.ini" file, but this serves just to exclude a small number of sites from being accessed via the Proxy (the purpose of this tool being to access the overwhelming majority of the internet through it ). Can you be so kind as to link to that documentation? This is a local PAC file you're talking about... 1. Internet Explorer, unlike Mozilla Firefox "legacy" browsers (I have no idea what the case is with recent Firefox), has poor support for local PAC files loaded from disk (and configured via the "unhealthy"/legacy "file://" protocol) - so, you can still try to configure IE8's proxy settings via pointing it to your local PAC file, then configure 360EE to "Use IE proxy", but YMMV ... Later EDIT (2024-05-21): This approach doesn't seem to work ; IE8 applies the above configuration (use the local PAC file over "file://" protocol), however 360EE, for reasons best known to its Chinese devs , doesn't observe this configuration when instructed to "Use IE proxy" ... 2. Since Chrome v68, native support for loading local PAC scripts over the file:// protocol has been disabled and/or revoked: https://bugs.chromium.org/p/chromium/issues/detail?id=839566 Some mitigations are offered inside comments on that bug, e.g. https://issues.chromium.org/issues/40574814#comment9 https://issues.chromium.org/issues/40574814#comment23 You can learn more about configuring Proxies in Chrome/Chromium by reading this excellent documentation: https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md#proxy-support-in-chrome Since HTTPSProxy is a secure proxy, used to access HTTPS URLs, the PAC syntax you quoted is wrong; change PROXY to HTTPS, e.g. function FindProxyForURL(url, host) { alert('url: \'' + url + '\', host: \'' + host + '\''); if (shExpMatch(host, "example.com")) { return "PROXY localhost:8079"; } } The "alert" line can be omitted, but it's there to generate a message in the (browser) console when a site is being successfully proxied... EDIT/CORRECTION: ProxyMII (and similar projects based on Proxomitron) actually uses two local proxies (Rear+Front); client apps (e.g. browser) connect directly to the FrontServer (localhost:8079), which is plain HTTP, while the RearServer (localhost:8081) is the one facing the web; thus, my initial advice was wrong ; "PROXY localhost:8079" must indeed be used inside a PAC implementation - apologies for any inconvenience, "errare humanum est"... In conclusion, I've offered lots of relative info you could have found yourself already by "fine-tuned" web searches ... TL;DR; Use a proxy extension inside 360EEv13.5 that has support for local PAC files, if you wish for some form of automation...

... However, the 360EE variants have proxy settings of their own, different to the ones in Google Chrome/Chromium ... @Anbima : If you opt to use just ProxyMII, then configure your IE8 browser to use this HTTPSProxy just for "Secure:" connections and once this is done (you can exit IE8 now), you can configure 360EE to use that proxy via:

... But why is Thorium reported to be Google Chrome 109 there? For consistency, weren't you supposed to test the same Thorium variant but on different OS (XP vs 7) ?

In the repo copy maintained by roytam1, those two toolbar buttons were removed by Tobin himself as part of: https://github.com/roytam1/boc-uxp/commit/360e21244397998a6183d847c65eaeb3b48fbbe0 352 + <!-- XXXTobin: These need to be exterminated 353...381 382 + --> on Aug 8, 2020 ...

"Out-of-Band" new Supermium (122) release, to patch publicly disclosed Chromium vulnerabilities: https://github.com/win32ss/supermium/releases/tag/v122-r5 (in response to https://github.com/win32ss/supermium/issues/570 ) ; @nicolaasjan :

... And if you took the time to read the linked reddit thread in its entirety, you would have also found that: In any case, and since this is OT here , I won't be posting more on this issue; however, I and other MSFN members will, no doubt, continue using ImgUr as an external image hoster, if it suits my/their needs... Regards.

... Be that as it may, win32's close collaborator and co-maintainer/administrator of Supermium's GitHub issue tracker, docrR, has already posted this: https://github.com/win32ss/supermium/issues/567 (BTW, that X link won't open/display for those without an account/those browsing X anonymously); the issue has also been pinned in the tracker, so it's difficult to not notice it ... ... My thoughts exactly - this doesn't mean that official sources of any given software are 100% immune to being tampered with, but this doesn't seem to be the case here...

... It all makes sense now : https://www.reddit.com/r/imguralternatives/comments/1357t3l/imgur_just_started_blocking_vpns_from_loading/

... But you were given named (and versioned) options already: ... Let's start with the most trouble-free option, the XUL ("legacy") UserScript Manager Greasemonkey-for-Pale-Moon (works on St52, too): https://github.com/janekptacijarabaci/greasemonkey/releases/tag/3.31.4Fork https://github.com/janekptacijarabaci/greasemonkey/releases/download/3.31.4Fork/greasemonkey-3.31.4-pm_forkBranch.xpi ... And don't take this personally , but at my older age I refrain from "spoon-feeding" others ... Take good care and good night!

... Since you're low on RAM, why did you disable disk cache? I might be wrong , but doesn't this mean that the browser cache is now stored solely in RAM?

... Provided you already have installed a St52-compatible Userscript Editor (XUL/WE, see the recommendations by AstroSkipper ), you should've scrolled down to: and clicked on one of the three offered options; ALL 3 work fine here (St52+VM) ; first option is the GH direct link, already provided in clear text by @AstroSkipper ; the "mirrors" will get you to the respective UserScript Portals, where you have to click appropriate "Install" buttons; FWIW, direct links below : https://update.greasyfork.org/scripts/423851/Simple%20YouTube%20Age%20Restriction%20Bypass.user.js https://openuserjs.org/install/zerodytrash/Simple_YouTube_Age_Restriction_Bypass.user.js If none of the links work for you, then something particular to your St52 profile may interfere...

... Indeed , as per: https://github.com/roytam1/UXP/commit/407a79e79f75a1de2af5588d8d54e853683af43f#diff-f1692414557ddbb1da94a106acb550a38c4145360214b795e77437b02b2a69ea (as part of upstream #2503 ) ...

... On mine, too ; this has been already reported before by him/them, but D.Draker, Saxon (and the rest of the gang ), for reasons probably only particular to him/them, have problems displaying ImgUr image embeds inside MSFN posts; so, by linking to yet another ImgUr screengrab, you're not proving anything to him/them ; FWIW, "error 429" is explained here - I have NO issue at all viewing "imgur.com" hosted pictures in any (recent-ish) browser/OS (Vista SP2, Win7 SP1, Win10) in my household ...

I think I was clear : Linked binaries are of the official Basilisk browser application (by Basilisk-Dev), built on the official UXP platform (by MCP); requires Win7 SP1 at minimum to launch, has ALL support for Web Extensions, multiprocess, Container tabs and EME removed (compared to Serpent 52); thus, usability-wise, it's like official Pale Moon+Australis interface+WebRTC; I keep a copy of it myself in my household's Win7 SP1 old laptop, just to check/verify if St52's bugs are also present there, too ...

... Try to watch inside your browser below YT test clip (it's safe, BTW ): https://www.youtube.com/watch?v=7t0SqerlBA0 without: a) being logged-in to your Google/YouTube account (where you have already verified your adult age ) && b) without using the userscript I linked to previously... Best regards ...

FWIW, someone else did post there about the same issue, so Bk's maintainer became aware : https://forum.palemoon.org/viewtopic.php?p=251585#p251585 Culprit: https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/24d2cf3cade432ac657e353a974f5edf306bab0d Cause: Fix in official Basilisk: https://repo.palemoon.org/Basilisk-Dev/Basilisk/commit/40afe7b5b25758f0b233a9e26a63a03d46b06c30 Latest binary releases with the fix: https://archive.basilisk-browser.org/2024.05.11/windows/ ... "We" did inherit that bug initially , but also fixed "here" (at the last moment?) : https://github.com/roytam1/UXP/commit/fffa564c0caf1b2f0c0d06797989722488265222

... Age-related YouTube blocks can be successfully circumvented, while being logged out of course, by using below userscript: https://github.com/zerodytrash/Simple-YouTube-Age-Restriction-Bypass?tab=readme-ov-file#userscript

@UCyborg : https://github.com/IDA-RE-things/Chrome-xp-api-adapter?tab=readme-ov-file#current-limitations ... so your WinXP x64 SP2 setup probably NOT supported ...

... Well yes, sadly, this has also happened to me, especially when using Serpent 52 to post (only very rarely happens when using KafanMiniBrowser ) ... Well, after reloading the page (and praying during the page reload that whatever you've already written won't be lost ), do NOT immediately re-click the "Submit" button; first open in a new tab the MSFN thread you're posting to and inquire whether your post has indeed been uploaded, despite the browser hang; once you verify this is not the case, only then do click the "Submit" button anew ; FWIW, I had similar issues when using St52 to post comments on GitHub, but now, since MS made GH almost unusable in UXP-based browsers, I use KMB for GH (where that issue almost never manifests itself) ... Kind regards.

... Archived in Oct 2023 - the GH repo that is ... Development has been migrated to GitLab : https://gitlab.com/eyeo/anti-cv/abp-filters-anti-cv https://gitlab.com/eyeo/anti-cv/abp-filters-anti-cv#installation https://easylist-downloads.adblockplus.org/abp-filters-anti-cv.txt Kindest regards ... EDIT: It would appear this ABP list is compatible with uBO-legacy : but incompatible with the WE version of uBO (latest DEV here, i.e. 1.57.3b8):

... Or, more probably, using the same compiler but with different compilation scripts/configuration, depending on the OS the final binaries are targeting ...

... 99.99% of times , when the OS generates that error upon trying to launch an ".exe" file, it means that the "Sub System Version" value inside the EXE's PE Header has been set (by the compiler) to a figure higher than the one corresponding to the current OS (e.g. XP=5.1, XPx64=5.2, Vista=6.0, Win7=6.1, Win8=6.2, Win8.1=6.3, Win10/11=10.0); using special software to modify that field of the PE header to an appropriate value for the current OS will allow for the executable to launch, unless some other kernel dependency isn't being fulfilled (in which case the OS will generate an appropriate ERROR message, different to the initial one ) ... Below screengrab is with the AVX2 Thorium variant: TL;DR; ALL the builds you tried have been configured to require Win10+ out-of-the-box ...

... Leave your router alone ; it's NOT the root cause of this issue; a simple test on Qualys SSL Labs will reveal that the host is currently inaccessible via IPv6: https://www.ssllabs.com/ssltest/analyze.html?d=www.void.gr