VistaLover

Already posted:

@32bitforever : I don't have a Google account myself, nor will I create one now just for the sake of experimenting with Google Meet in latest Serpent 52 ... There may be several reasons why it doesn't work for you, e.g. 1. User-agent-sniffing; GM servers might not like the UA sent by your copy of Serpent 52 2. GM webpage / APIs might need browser technologies (e.g. Web Components, ShadowDOM, etc.) that are not yet complete/implemented in St52 and are particular to Chromium forks ... 3. GM APIs might not like the (older) implementation of WebRTC present in latest Serpent 52 ; while "upstream" claim it is still specs-compliant, Google have a habit of rejecting everything else that isn't tailored to their own "vision" () of Web 2021... Tools -> Web Developer -> Web Console/Browser Console/Error Console may give some clues as to your predicament... If you have access (through a sibling/relative/friend) to official Basilisk builds (require Win7 SP1 64-bit at minimum), you can try there, too; if still no go, little, if any, chance of fixing GM in our fork... And even if the issue persists in official Basilisk, again, very little chance "upstream" would even bother trying to fix it, as they harbour a known aversion towards Google-owned technologies, including WebRTC itself (which they haven't included in Pale Moon, BTW...).

You may also consider substituting the XP-incompatible openssl 1.1.1.x files with XP-compatible ones, like I advised for SUMo previously in this thread: Not tested here (XP is unavailable) ... BTW, the latest openssl 1.1.1 official release now is at version 1.1.1k (file versions 1.1.1.11)

Thanks for the heads-up! If you (or anyone else) can't wait until the (patched) version 3.0.13 is officially released, VideoLan provide VLC 3 automated nightly builds, where, hopefully, the exploit has been patched already ; latest (as of this writing) 3.0.13-dev-win32 build can be downloaded from: https://artifacts.videolan.org/vlc-3.0/nightly-win32/20210417-0625/ binaries repo: https://artifacts.videolan.org/vlc-3.0/nightly-win32/ Best wishes

The really interesting bits are to be found inside: https://github.com/notepad-plus-plus/notepad-plus-plus/pull/9378 especially in comments by XP user @KOLANICH ... TL;DR : They didn't really have to drop XP, it was just that one of their devs (@mere-human) "forcefully" introduced code for a "modern" style File Open dialog, that relies on APIs found only on Vista+; the idea to have a fallback for XP was also dropped, as "too complicated"...

... FTR, I did warn about WebIDE having been kept "here" but removed by "upstream" : I'm sure Dutch speaking members here will appreciate your efforts! However, stay vigilant, more string changes on the way... https://github.com/roytam1/UXP/commit/700f7804bdfe9f8d6dbb9b5dae825a297dd16a34#diff-a4c8afcf877e09836666f13acf9d862c30c2b029439418d1afd4fd63f61c1a9d

Yes, but no common userscripts are shared between them... FWIW, I also have installed in that same St52 profile Stylem (a "legacy" userstyle manager, for styles that alter parts of the browser) and Stylus 1.14.23 (a WE userstyle manager) for styles that alter web pages - the latter also has support for the newer format of userstyle called UserCSS (offers configuration choices post-install); sadly, v1.14.23, the last compatible with St52, has become now quite old, several of the newer UserCSS styles won't install or previously installed versions won't update to the most current... One such example is Old Reddit Favicon : // ==UserScript== // @name Old Reddit Favicon // @include https://old.reddit.com/* // @grant none // ==/UserScript== (function () { var link = document.querySelector('link[rel*=\'icon\']') || document.createElement('link'); link.type = 'image/x-icon'; link.rel = 'shortcut icon'; link.href = 'https://i.imgur.com/veJX9o5.png'; document.getElementsByTagName('head') [0].appendChild(link); }) (); A WE (like VM) could never alter a tab's favicon for a given site... Regards

I use the open source Violentmonkey extension (WE, currently at version 2.12.14) in latest Serpent 52.9.0, as well as in 360EE... VM being a WE, it can only affect web content, not browser looks (this is not possible in 360EE, of course, but I use Greasemonkey for Pale Moon in St52 to change several browser-GUI aspects...). https://greasyfork.org/en/scripts/410687-google-shut-up https://greasyfork.org/el/scripts/412178-youtube-dismiss-sign-in (has some overlapping functionality with the previous one) https://greasyfork.org/el/scripts/375525-youtube-age-verification-bypass (works only for embeddable age-gated videos) https://github.com/Mottie/GitHub-userscripts/wiki/GitHub-download-zip https://greasyfork.org/el/scripts/407745-bypass-github-ajax (in St52 and NM28, together with JustOff's GitHub Web Components Polyfill extension) https://greasyfork.org/el/scripts/395497-login-reminder-popup-remover https://github.com/Procyon-b/make-gis-great-again https://github.com/Procyon-b/GitHub-sort-by-recently https://cable.ayra.ch/tampermonkey/view.php?script=youtube_autoplay_disable.user.js (a must have!) https://cable.ayra.ch/tampermonkey/view.php?script=youtube_volume_normalizer.user.js https://greasyfork.org/en/scripts/5566-youtube-links (doesn't work in NM27) https://greasyfork.org/en/scripts/377047-old-reddit-redirect

... But it's coming from a Chinese vendor (so XP support isn't that much of a "surprise" there ... ); however, several members here have expressed their mistrust (some even aversion) for everything with a Chinese origin ; at the end of the day, would you yourself use such a solution? FTR, I don't have any personal issues myself using a Chinese (and/or Russian) product, that is, no additional issues compared to using just US/EU ones... Best regards

... I think they have been candid about the type of "continued support" in the May 17th 2018 article below: https://forums.malwarebytes.com/topic/191650-malwarebytes-3-frequently-asked-questions/?tab=comments#comment-1243649 i.e. their "support" is limited, in practice, to just offering def updates, via a separate development track (they also make mention of "other maintenance upgrades", but only an actual (paid) user of the app can testify whether such "upgrades" ever took place... ) . Still, if you compare them to other vendors cited in this thread (who decided to cut-off updates on their XP/Vista compatible products), they do hold a higher place in my heart, because they acknowledged: See there, if it's still "possible" for them, why did the rest bail out ? One sane person would think that when an OS becomes unsupported by its vendor, third party Security Products should become even more effective in protecting the integrity of that OS (and their vendors could generate additional income in the process ); what did we see instead? Most AV vendors leaving "high and dry" the users of said OS (which may well have been paying customers until then) ...

If that is on Serpent 52.9.0, on latest build at least, javascript.options.jit_trustedprincipals is not an included pref by default ; I found a mention about it here : but that Bugzilla bug refers to a relatively recent Firefox version; further searches landed me on: https://github.com/arkenfox/user.js/issues/928 which states: new in 75beta but commented out by default //user_pref("javascript.options.jit_trustedprincipals", true); // [FF75+] [HIDDEN PREF] so, in all probability, it is not applicable to St52... If you're just picking up user.js files from the web, please make sure first they are valid for the version of the browser used; and remember, St52 != Fx52 (and, certainly, not later Firefox versions... ) ... Best wishes

Another tip already mentioned previously in this thread is to launch 360EE with the cmdline argument: --process-per-site so that tabs under the same domain (e.g. all facebook.com tabs) are loaded by the same unique browser process; I tested this briefly in the past, but since I never get to having more than 25 open tabs and very few, if any, among them share the same domain, I did not witness a noticeable reduction in RAM consumption (tried on 360EEv12/v13) ... YMMV, of course...

For the duration JustOff was the head of the official Pale Moon localisation project, he would maintain his own langpack (LP) GitHub repository, https://github.com/JustOff/pale-moon-localization/releases and his Pre-release LPs would target PM's unstable channel, with which NM28 has/had the closest affinity... Modifying the minVersion value inside the install.rdf file, to account for NM28's different versioning, would produce an installable and functioning langpack... This practice used to work up to a point in time (e.g. I know it worked till the end of May 2019, when NM28 was at v.28.6.0a1); but,"upstream" started making coding decisions that were deemed "unwanted" by the majority of members here; old code was kept by us, but removed by upstream (e.g. WebIDE inside devtools) and vice-versa, i.e. they introduced new code that was not adopted here... Whenever these code differences introduce string modifications (addition or removal), then the PM-targeting LP becomes incompatible with NM28 to a varying degree; slight modifications in parts of the browser you don't use often may stay unnoticed, but when major core strings have been altered, considerable breakage takes place, even to the point that the non en-US pack renders NM28 unable to launch with it; a "safety" mechanism then silently disables that LP and re-launches the browser in the default (en-US) locale... I wrote the above "summary" for the sake of those unfamiliar with NM's localisation scenarios; FWIW, roytam1, from the very start, said he would not provide himself LPs for his browsers, we, as fork users, were just lucky we could, up to a point, "freeload" the ones prepared for PM by MCP (and get all the hatred from them for doing so... ). Our (roytam1's ) source tree had already diverged significantly from upstream even before JustOff was ousted from the MCP localisation team, but lack of his "unstable" LPs currently means that a DIY person like you can't peek into them to find newly introduced strings there (that could be migrated to a NM28-specific LP); the sole source of PM localisation now are the LPs intended for its release channel, to be found: https://addons.palemoon.org/language-packs/ with NL on https://addons.palemoon.org/releases/pm-langpack-nl/ Save as .xpi file and extract with 7-zip, then look inside for new strings not yet incorporated into your own NM28 NL-pack; you have to be well versed in the folder/file structure of the LP, if you have a NM28 NL pack that used to work in previous NM versions, you can "build" on top of that and go forward towards more recent releases... You must use a file diff application (or a text editor) to inspect the string differences between the exact same files of the two LPs, so you can modify your DIY one accordingly (taking care to incorporate only the new strings needed by our fork, the PM file may contain other strings not compatible with NM). Indication of strings modification in code can be found also on roytam1's GitHub repo; whenever UXP and/or Pale Moon source files that have a path containing "*/locales/en-US/*" are being modified, this signals modification to the natively bundled en-US langpack; these modifications should be reflected (and translated into Dutch, where applicable) in your DIY NM28 langpack. For instance, for the "Media Formats" strings that you cited, the relevant commit is [Pale-Moon] Issue #1862 - Add media format controls in Preferences -> Content from which you can see the newly introduced (English) strings in file application/palemoon/locales/en-US/chrome/browser/preferences/content.dtd by loading: https://github.com/roytam1/UXP/commit/650abe2cb9eb02c14369a807a6225ebb053d0b17#diff-d3c90e964941daf05f84a5b5192bc0c94f6f629dcc424dd23e8f87cc766cd4f7 Many times, it is difficult to tell on which LP file to apply the string changes committed to source files, this ain't one of them : <LP root>\browser\chrome\nl\locale\browser\preferences\content.dtd In conclusion, the natively bundled en-US langpack is found split between NM28's two omni.ja files: ".\palemoon\browser\omni.ja\chrome\en-US\*" ".\palemoon\omni.ja\chrome\en-US\*" (use 7-zip to access); ultimately, these are all the files you have to translate into Dutch and then package appropriately (consult an existing LP) to make a functional NM28 nl-langpack.xpi; it ain't easy, is it? But I am open for any automation process you happen to be aware of (this extends to the rest of this community here ) ... Kind regards

Well, AFAIK, @JustOff only supports official Pale Moon, official Basilisk and SeaMonkey 2.53.x; he doesn't support pre-Quantum Mozilla Firefox (v52-56), nor any other Fx52ESR-based fork... (snipped) Imagine the case your wish has been granted by @JustOff and his extension installs out-of-the-box in Serpent 52.9.0; (snipped) The extension would have no issue installing in a 2018 build of Serpent 52 (on Firefox ESR 52.x.x, too), but obviously the GitHub experience there would be substandard... Do you think @JustOff is willing to deal with such scenarios? (snipped) ... so, things aren't as clear-cut as initially imagined; the ball is now in @JustOff's court, so let's wait for his reaction... ... And the man has spoken: https://github.com/JustOff/github-wc-polyfill/issues/21#issuecomment-813060443 ... Didn't I tell you so?

Twitter related upstream change targeting Pale Moon, applicable to New Moon 28, too: https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/4f00b12

Actually based on Chromium 69 - 360EEv12 is the one based on Chromium 78... Basilisk 55/Moebius was actually born by MCP as a fork of a snapshot of Mozilla Firefox 53.0a1 (yes, the Nightly channel); there's very little, if anything, backported from Firefox stable 54.0 or 55.0; in fact, MCP, right after forking, started removing features, so that Basilisk 55 was even inferior to release channel Firefox 53.0, feature-wise (especially in what concerns e10s and WebExtension APIs) ... MCP just gave it an appVersion=55.0.x for purely "sensationalism" reasons ... Today's Serpent 55, as maintained by Roytam1 (updated roughly once a month), is a mixed-bag, an experimental app where patches from Mozilla, TenFourFox and, mostly, UXP are being applied... As for the matter at hand, Chromium-derived browsers are notorious for gobbling up RAM at the speed of light... By design, each tab is run in its own browser process, add to that several other processes needed by the browser core and extensions, add the amount of RAM devoured by your ad-blocker extension alone and you get the picture... Session restore in Chromium browsers is also an issue, because the application has to spawn, after initial launch, ALL these additional processes to "resurrect" the tabs present in the previous session... I was first introduced to PCs when Windows XP was the OS du jour, with its IE6 fine (!) browser which, if you care to remember, did not support tabs - opening 150-300 browser windows was unthinkable at the time... When "tabbed" browsers came into being, people started abusing the feature, many ending up doing, what was later called, tab-hoarding ; but websites of yesteryear were mainly static HTML pages, so the impact on consumed RAM (my initial XP box came with 512MB!) was small; this allowed tab-hoarders to continue the type of workflow they had been accustomed to... But lately, certainly within the last 5 years, web-sites have turned into web applications in their own right, laden with omnipresent rich media content and heavy scripts; embedded videos and high resolution images are now obligatory to attain high Google-analytics figures (which is what drives webpage creation now), plus wizards to social media are everywhere (even here on MSFN...). Browsers are being served huge blobs of (minified) Javascript, Web Assembly (wasm) code, huge CSS files, HTML5 video etc., that have to be decoded and rendered locally by the browser engine ! Especially the design of the (very popular) Social Media sites (Facebook, VK, instagram, twitter, tiktok, youtube e.a.), targeting mobile devices with touchscreens, with their "infinite-scroll" pages (where more content is loaded in memory as you scroll further), all that is a veritable menace to under-resourced and on "hardware-of-the-past" desktop machines... I am mentioning the above just to highlight the fact tab-hoarding has become a lot more difficult these days, especially on older (32-bit) OSes (which, by their nature, have worse RAM-handling/allocating capabilities than the recent 64-bit ones...). Don't get me wrong, I'm not passing judgement on @Cixert's workflow habits, just pointing out that his practice will simply get worse in the future, irrespective of browser/OS bugs... Pre-quantum Mozilla forks, like the ones issued by Roytam1, are basically single-process applications, which, by that fact alone, makes them more lenient on system resources; if you only have a few vital extensions, an intelligently configured content-blocker, you try to stay clear of desktop-hostile places like the main Social sites, then I suspect you can afford to open more tabs there... But remember, single process means that if one tab crashes, it takes the whole browser with it! On the subject of RAM consumption, let me also recommend the Lull-the-tabs legacy extension (by JustOff), which minimises significantly RAM consumption at browser start-up, especially when it tries to restore a large previous session... Looking for a similar add-on for Chromium browsers, The Great Suspender Original https://chrome.google.com/webstore/detail/the-great-suspender-origi/ahmkjjgdligadogjedmnogbpbcpofeeo sounds promising, but I've not tried it myself, since I never have more than 25 tabs open in 360EEv12/13 (several of which are system tabs that don't consume RAM). Some more extensions to try are mentioned in: https://www.makeuseof.com/tag/google-chrome-ram-memory-usage/ By the looks of it, Cixert has hit some session-restore bug on 360EEv11 that manifests itself under his specific usecase and/or OS configuration... In the following URL, https://www.webnots.com/8-ways-to-reduce-memory-and-cpu-usage-of-google-chrome/ I urge you to read chapters 2+3+4 ; if the session restore bug kicks-in at 151 opened tabs, then make sure you close the additional ones before exiting the browser; as others have said, you have to adapt to the browser's capabilities, should you wish to continue using 360EE... I'm not quite sure what is the exact OS/architecture this happens on, but later 360EE versions may fare better with regard to RAM management and session restore; have you tried 360EEv12 and/or 360EEv13? At the end of the day, if you find that none of the 360EE versions quench your work-related absolute need for 300 open tabs, you should consider staying with/switching to a browser that lets you do it... We can only help up to a point here, sadly... Best regards, stay safe

... A quick search found a few mentions (mostly in Chinese and Russian sites) of an interim release v1.7.21469.0 with the "version number", again, assumed to apply to the main potplayer.dll file ... That release, apparently, took place on Mar 25th 2021, and has already been superseded/replaced by (potplayer.dll) v1.7.21472.0 (that I downloaded directly from vendor: https://t1.daumcdn.net/potplayer/PotPlayer/Version/Latest/PotPlayerSetup.exe ); while searching, I did come across several PotPlayerSetup.exe releases with the same file version 1.7.21465, but with different versions of contained DLL and different digital sigs (DS): Setup v1.7.21465.0/DLL v1.7.21466]/DS 20210318 Setup v1.7.21465.0/DLL v1.7.21467]/DS 20210319 Setup v1.7.21465.0/DLL v1.7.21469]/DS 20210325 Setup v1.7.21465.0/DLL v1.7.21472]/DS 20210402 (latest as of this time) None of the above are expected to run under Windows XP... But, as I told already, standardisation of the released binaries has gone out the window... To be frank, I don't expect them to restore XP-compatibility, it might be a while before their main homepage reflects this, but it's the sad reality... FWIW, Vista will be also dropped like a hot potato at first opportunity, by introducing Win7+ function(s)... In light of the above sad developments, any further discussion of PP versions > 210209/1.7.21419.0 would be OT for this thread... Let me close by sharing another disturbing piece of news about current owners of PP: https://old.reddit.com/r/potplayer/comments/lxsozp/potplayer_official_english_forum_was_closed/ Thus, international PP users likely have to turn to third-party forums for support...

... Actually named PotPlayerXP.exe here: Too many inconsistencies with that latest release, if you ask me... 1. The installer has "File Version" 1.7.21465.0, but the main DLL (potplayer.dll) has "File Version" 1.7.21472.0 2. The "About" info shows application version (according to new naming convention) as being 210318 (i.e. Mar 18th 2021), this is the one VH also use, but the installer itself, PotPlayerSetup.exe, as well as the main DLL have been digitally signed on Apr 2nd 2021 : What a fine mess they've created, user confusion is inevitable...

I recollect this as having been already discussed in this thread... Upon searching, I did locate a post from June 2019, by one of your compatriots: I have never experienced this under Vista SP2 32-bit, so, as hinted, it might be an issue specific to XP... I am convinced, through local testing, that PotPlayer uses system resources (TLS implementation/cipher suites/crypto libs/cert store) to establish HTTPS connections, since (recently) many web services abandoned TLS v1.0/1.1 and moved on to TLS v1.2+, this might be a manifestation of such an implementation... A similar issue I'm facing with PP recently is its inability to play back several audio streams served securely, like the newly introduced BBC Radio Icecast ones, e.g. https://stream.live.vc.bbcmedia.co.uk/bbc_radio_one A test on SSL Labs shows it demands exclusively TLS v1.2 and cipher suites IE[9] can't cope with... The same stream plays back fine in VLC 3.0.x (which bundles its own crypto libs). This was indeed deduced from a changelog on subsequent (beta?) release 1.7.18193 two years ago, VH have since then a permanent link on https://www.videohelp.com/software/PotPlayer for what "they" claim to be the last XP-compatible version... OTOH, the very same site hosts, what I believe to be, a copy of the official stable releases changelog, https://www.videohelp.com/software/PotPlayer/version-history which jumps from v [1.7.17508] 2019/02/12 straight to v [1.7.18344] 2019/04/17 with no word about drop of XP support... That VideoHelp misconception/misunderstanding was also rooted among XP users based on the "H/W accelerated HEVC" debacle, read here ; FTR, stable release 1.7.18346 (second after 1.7.17508) was confirmed as being XP-compatible already in this thread by our very own PP guru! So, the moral of this short story is, don't always believe what you read at first, consult a second opinion, if you are a "Doubting Thomas" (like myself), try for yourself (except, of course, when "trying" goes against your principles - this is acknowledged and respected! ) ... Practically not "mine", merely hosted currently on VH - if you peruse this thread, you'll find I'm not the first one to suggest VH's archive as a source of previous PP releases... I genuinely thank you for your time and efforts conducting this conclusive test, which proves that the last, at the time of writing, XP-compatible release of PotPlayer is the one versioned [new scheme] 210209/[old scheme] 1.7.21419 . Lastly, it has been posted that the latest PortableApps offering of PotPlayer, package with filename "PotPlayerPortable_1.7.21419.paf.exe", has been erroneously declared as being XP-compatible, ie. in reality it isn't ... The above statement had me really perplexed, because @FranceBB has proven, beyond any doubt, that v1.7.21419 (packaged inside the PAF version) IS XP-worthy; the answer to my pondering is that XP-compatibility has been broken not on appVersion itself, but on the fact the packager omitted the inclusion of file PotPlayerMiniXP.exe inside ".\App\PotPlayer\" (in the PAF folder structure); this can be mitigated quite easily, if that missing file is 1. extracted (7-zip) from the installer of v1.7.21419 2. copied inside the PotPlayer directory (besides PotPlayerMini.exe, which you can delete, if on XP) 3. you modify the portable launcher's configuration, in ".\App\AppInfo\Launcher\PotPlayerPortable.ini" as below [Launch] -ProgramExecutable=PotPlayer\PotPlayerMini.exe +ProgramExecutable=PotPlayer\PotPlayerMiniXP.exe -: deletion of line +:addition of line Hope it works, it should... Best wishes

Apologies , it was somewhat inconsiderate of me to wish you Happy Easter, while you are in mourning over your recent loss ... But, life must go on, as we say here: "The Dead among the Dead and the Living among the Living"; peace with you and your loved ones... Covid19-wise, it's the same SNAFU over here, too...

Many thanks, indeed! palem's post there is, I think, highly representative/reflective of the major part of Moonchild browsers' userbase, and should also encompass users of Roytam1 forks here... The actual URI of the post (by M.A.T.) quoted is: https://forum.palemoon.org/viewtopic.php?p=211976&sid=0181647fb5c2204a1c681cd16e21004d#p211976 ... As far as I know, no-one here has already gone/will go nuts over it, all is needed is to keep a vigilant eye on UXP+PM issue trackers/UXP+PM master branches and selectively revert/omit what is deemed unneeded for our tree... Even if that, eventually, will just buy us more time (hopefully lots of it...), it would be highly worth it! E.g., I have already warned readers here of the new plan (envisioned by M.A.T.) to move to an install.json based extension ecosystem (deprecating the install.rdf one), I think these developments should be dealt with on a case-by-case basis/when they present themselves... OT: To Sampei and to all observing Easter tomorrow, may you have a very Happy Easter Sunday (... Unfortunately, divisions between communities of the same Faith mean that over here Easter Sunday won't "arrive" until May 2nd ) ...

... Modern Wakandan? Really Moonchild? https://freefontsdownload.net/free-modernwakandan-font-160865.htm Anyhow, blocking remote fonts in uBlock Origin "legacy" fixed it for me... Well. I was well on April 2nd (by 5 hours) in my timezone already, so that wasn't my first thought... In a devilish coincidence (or perhaps it was deliberate all along), the official PM forums were down for maintenance, because going there to look for answers was what I did first, before posting here... Now that their forums are back, all has been revealed: https://forum.palemoon.org/viewtopic.php?f=37&t=26503 https://forum.palemoon.org/viewtopic.php?f=17&t=26504 Thanks everyone for your input...

In his latest Pale Moon extension-blocklist update, Moonchild, among other changes, moved to "severity 3" (hard/permanent block) the following two extensions: Giorgio Maone's (legacy) NoScript (id="{73a6fe31-595d-460b-a920-fcc0f8843232}") JustOff's Moon Tester Tool (id="moonttool@Off.JustOff") and added directly at "severity 3" level () JustOff's Classic Add-ons Archive (CAA) (id="ca-archive@Off.JustOff") Code below: https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/1ca7c78 I don't know whether it's a typo (probably not...), but the commit's title says it "fixes" PM issue #1444 , which has nothing to do with the extension blocklist... The latest update is in fact just another coordinated offensive against JustOff's offerings (previous ally, now treated as worst foe...). @roytam1 : Are New Moon 28 users being served the same blocklist as Moonchild's PM? Browsing inside NM28's "about:config" section and filtering for "extensions.blocklist", I see: extensions.blocklist.url;https://blocklist.palemoon.org/?version=%VERSION% but what is the value of %VERSION% in our case (if it's 28.10.3a1, then the resultant URI redirects to https://blocklist.palemoon.org/v28-1/blocklist.xml which serves currently an older iteration of the blocklist... ) ? Might I kindly ask you to undo these changes (if indeed they'll affect us, too ), since many users here use one or more of the now permanently blocked PM extensions (I use MTT+CAA, NoScript also has some enthusiasts among NM28 users ...). Somewhat OT, but do you, too, see "hieroglyphs" on everything hosted on www.palemoon.org: I noticed this when trying a NM28 fresh profile and was greeted with http://www.palemoon.org/firstrun.shtml FTR, the Page Source is correctly in English, but when the page loads, only displays English for a mere fraction of a second, then falls back to indecipherable scripts; I have tried several character encodings, all to no avail...

@Montana Slim : [App] Vendor=Hyperbola Name=Icedove-UXP Version=52.9.20210325 BuildID=20100101 ID={3aa07e56-beb0-47a0-b0cb-c735edd25419} RemotingName=Icedove-UXP [Gecko] MinVersion=4.8.0 MaxVersion=4.8.0 ... and [App] Vendor=OpenSource Name=MailNews RemotingName=mailnews Version=52.9.7754a1 BuildID=20210325050411 ID={3550f703-e582-4d05-9a08-453d09bdfdc6} [Gecko] MinVersion=4.8.0 MaxVersion=4.8.0

In my previous post in this thread, I assumed you were trying to just connect to https://www.catalog.update.microsoft.com/Home.aspx (because that's the URL I have bookmarked for MUC), so that's why I posted the results of SSL Labs on hostname www.catalog.update.microsoft.com : It later became apparent (first via your IE8 screengrab ) that you wanted to access https://catalog.update.microsoft.com/v7/site/Home.aspx which is, as you stated, a different story, because it has a stricter (pun intended) HSTS (courtesy, again, of SSL Labs/Server on the "catalog.update.microsoft.com" hostname) : Because XP doesn't support EC Cryptography (ECC), there's sadly no way you could connect natively with IE8... Another factor that is/was not clear is the level of your Windows Update (XPSP3 EoS, POSReady2009 EoS, etc.); judging by what @Usher has posted above, I gather that a POSReady2009 EoS level updated IE8 is able to connect successfully to https://www.catalog.update.microsoft.com/Home.aspx (via one of the TLS_RSA_WITH_AES_* cipher suites, possibly over TLS v1.2, too - POSReady2009 has indeed brought TLS v1.2 to XP...), so that should be the way to go on XP (until M$ ruin it further in the future, which I'm sure they will ). As @Dave-H has correctly advised , if your default ProxHTTPSProxy configuration file (config.ini) has the following entry under its [SSL Pass-Thru] section: [SSL Pass-Thru] *microsoft.com* you just have to comment it out, so that both MUC variants are being "proxied": [SSL Pass-Thru] #*microsoft.com* Best wishes