VistaLover

According to SSL Labs, Chrome 49 / XP SP3 supports the following protocols and cipher suites: https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP SP3&key=136 Protocols TLS 1.3 No TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes Cipher Suites (in order of preference) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Forward Secrecy 256 OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) Forward Secrecy 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) WEAK 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) WEAK 128 TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112 I presume the above reflects XP SP3 fully updated until EoS, without any POSReady additional updates; NB that while Chrome 49 comes with its own TLS protocol support, it relies on the OS both for certificates (WinCert store) and supported cipher suites... For completeness, what additional (if any) cipher suites are added via the POSReady updates? To check, launch Ch49 (under XP SP3+POSReady) and visit https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html OTOH, the server "o.rthost.win" resolves into two IPv6 + two IPv4 addresses; e.g., "104.21.48.191" supports the following protocols and cipher suites: https://www.ssllabs.com/ssltest/analyze.html?d=o.rthost.win&s=104.21.48.191 Protocols TLS 1.3 Yes TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes This server supports TLS 1.0 and TLS 1.1. Grade capped to B. This site works only in browsers with SNI support. # TLS 1.3 (server has no preference) TLS_AES_128_GCM_SHA256 (0x1301) ECDH x25519 (eq. 3072 bits RSA) FS 128 TLS_AES_256_GCM_SHA384 (0x1302) ECDH x25519 (eq. 3072 bits RSA) FS 256 TLS_CHACHA20_POLY1305_SHA256 (0x1303) ECDH x25519 (eq. 3072 bits RSA) FS 256 # TLS 1.2 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH x25519 (eq. 3072 bits RSA) FS 128 OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14) ECDH x25519 (eq. 3072 bits RSA) FS 256P TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) ECDH x25519 (eq. 3072 bits RSA) FS 256P TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH x25519 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 # TLS 1.1 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 # TLS 1.0 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 As you can verify on closer inspection, there exist no common cipher suites between what the browser and the server support, so the OP is absolutely right; the same is indicated by SSL Labs Server Test: Notice how the server is configured to only support cipher suites (TLS_ECDHE_ECDSA_*) with Perfect Forward Secrecy (PF), which, on the one hand, is a good thing, but it may limit the connection ability of older clients... @roytam1, do you have any control on this? If you could add (on the server) support for (even just one of) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) which aren't deemed WEAK, Ch49/XP SP3 could connect over TLSv1.2... PS: For anyone vaguely interested, Chrome 49 / Vista SP2 (fully updated to EoS+TLSv1.2 support from WS2008SP2) can connect natively over TLSv1.2 via "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)" :

For NM28, you need to install https://addons.palemoon.org/addon/pdf-js-for-seamonkey/ For NM27, you need to install JustOff's https://github.com/JustOff/moon-pdf-viewer/releases (there was a v1.0.3 hosted in "addons.palemoon.org", but after the rift between MCP & JustOff and the removal of all of his extensions, it is currently AWOL ... EDIT: The Web Archive has salvaged it! https://web.archive.org/web/20200103222159/https://addons.palemoon.org/addon/moon-pdf-viewer/ https://web.archive.org/web/20200103222246/https://addons.palemoon.org/?component=download&id=MoonPDFViewer@Off.JustOff&version=1.0.3 )

FWIW, I'm using myself another (more recent) variant, https://greasyfork.org/en/scripts/377047-old-reddit-redirect along with // ==UserScript== // @name Old Reddit Favicon // @include https://old.reddit.com/* // @icon https://i.imgur.com/veJX9o5.png // @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); }) (); that also resurrects the "old" Reddit favicon...

This isn't an accurate assessment by now even , because official Basilisk has become an abandonware by upstream... The last publicly released Windows binary was a 64-bit ONLY compile, with appVersion=52.9.2022.01.27 and BuildID=20220127135138 ; the platform submodule that was used to compile it was GRE (Goanna Runtime Environment, now dropped by Moonchild), not even UXP, and the GRE version back then (Jan 27th 2022) was 4.8.3. So, latest Serpent 52 is far more "rich" in Web Compatibility features compared to the last Basilisk build of more than 4 months ago (not to mention some other Serpent-specific features that make it more "valuable" in my eyes, e.g. WebEx & Container Tab support)... Thanks! If it was up to me, in https://github.com/RamonUnch/palefill/commit/a82544e I would've have also changed "Platform51Up" (two occurrences inside "main.js") to "Platform485Up", because (and call me pedantic ) : 1. UXP by Roytam is currently at v4.8.5, 2. 4.8.5 can't be >= 5.1.0 (i.e. 51Up ) I installed your fork in my St52 copy, then I explored its options (inside the Add-ons Manager); the "Dump platform information" button had me perplexed for a while ... By clicking that button, I was expecting a "Save File" prompt, to save on disk a "text-type" file (e.g. *.log, *.info, etc) with the dumped info, however none was showing up... The extension's documentation (original and fork) wasn't helpful in that respect, either... After fooling around for a bit, I discovered that the "platform information" is actually being printed, in JSON format, inside the browser's Browser Console (CTRL+SHIFT+J), which isn't self-intuitive... @UCyborg, being a contributor to the upstream project, do you think you could come up with code that would implement my suggestion (clicking the "Dump platform information" button will offer to save on disk a "PlatformInfo.json" text file - current behaviour [BC] could be retained) ?

... Without any justification in the commit message, if I might add... But it's fallout from https://repo.palemoon.org/MoonchildProductions/UXP/issues/1909 specifically read: https://repo.palemoon.org/MoonchildProductions/UXP/issues/1909#issuecomment-30813 Since "we" are the first to be exposed to the "upstream" UXP master branch, no wonder I was hit (and reported) that bug on "our" side of things... Better watch out for the revised version of that (and eventual aftermath on the Serpent browsers), if/when it makes it to upstream UXP...

Both reverted in https://github.com/roytam1/basilisk55/commit/355a4b054c990e306b139ded685f146d9bf1ec23 https://github.com/roytam1/UXP/commit/8c7e1338ced4de4fb701bcbfe568faa20518a3db Much obliged!

Dearest @roytam1 In a previous post of mine, I made a point that, apparently, was not given the full attention it deserved... So, I'll re-iterate: Upstream (MCP) are currently further developing their platform (official UXP) with practically only one application in mind, i.e. official Pale Moon (the same can also be said about M.A.T. and his AuraRE platform, intended for his Borealis Navigator and Interlink applications). However, as things stand now, you also use your UXP-fork to build Serpent 52.9.0 (and several other forks, like the bin-oc+hyperbola ones), plus port UXP "patches" to Serpent 55/moebius... While NM28 may have a closer connection to the official PM codebase, both St52+St55 have distinct differences to PM, likely to become wider in the future; thus, one must be very wary/careful of official UXP patches as to eventual detrimental effect(s) on St52 and/or St55 (we've had recent examples of that, with disabled GMP (EME) plugins (CDMs) and "pdf.js" in St52... ) This very afternoon (despite the first heatwave - 37.5C/99.5F - of this summer....) I updated my St55 installation, from "basilisk55-win32-git-20220528-c952169c0-xpmod" to "basilisk55-win32-git-20220604-ea6e33cd0-xpmod" (or was that, perhaps, "basilisk55-win32-git-20220604-5600fe37e-xpmod" ? ) ; soon I discovered that the extension update feature was broken... While official PM has the "Tycho" AOM (add-ons manager), both St52+St55 have a "WebEx" type one, because they do also support Web Extensions (à propos, St55's WE support has declined to St52's levels, what with the recent Sync with UXP, but this is material for a future bug report ) ; also, in both browsers there exists the "extensions.update.background.url" pref, which can allow for setting up two different extension repos to watch out for add-on updates... In my copy of St55, I have extensions.update.url;https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=53.0&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=53.0&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% so that AMO would be monitored for updates of installed WEs, and extensions.update.background.url;https://addons.basilisk-browser.org/?component=aus&reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=52.9.2022.01.27&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=52.9.2022.01.27&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% so that ABBO would be monitored for eventual Basilisk XUL extensions updates (NB that, according to a MC statement I can't locate now in his forum, the ABBO repo may soon cease to exist...). The above "arrangement" used to work as expected until (& including) build "basilisk55-win32-git-20220528-c952169c0-xpmod"; "about:addons => Check for Updates" will produce an alert (View Available Updates) for, at least, four suggested WE updates from AMO: When moving on to "basilisk55-win32-git-20220604-ea6e33cd0-xpmod", "Check for Updates" stalls seemingly forever (being grayed-out), the AOM is in a permanent "Updating add-ons" state: The Browser Console is flooded with extension update manifest errors (for each checked extension), plus 19:22:10.249 1654446130246 addons.manager WARN Exception calling callback: ReferenceError: can't access lexical declaration `url' before initialization (resource://gre/modules/addons/XPIProvider.jsm:6686:1) JS Stack trace: UpdateChecker@XPIProvider.jsm:6686:1 < findUpdates@XPIProvider.jsm:7574:5 < doCommand/<@extensions.js:1168:15 < safeCall@AddonManager.jsm:191:5 < makeSafe/<@AddonManager.jsm:206:25 < process@Promise-backend.js:917:23 < walkerLoop@Promise-backend.js:801:7 < scheduleWalkerLoop/<@Promise-backend.js:737:11 I have verified locally that the culprit for this breakage is in fact: ported from UXP: Issue #1909 - Guard against empty update manifest URL (7b3f9fb7) "UXP: Issue #1909" shouldn't apply as-is on Serpent 52.9.0 and 55.0.0, because they have Extension Managers different to the one in official Pale Moon; so please, revert both https://github.com/roytam1/basilisk55/commit/5600fe3 (for St55) and https://github.com/roytam1/UXP/commit/7b3f9fb (for St52) Thanks for understanding, best regards

That last commit, ea6e33cd0, is nowhere to be found currently in: https://github.com/roytam1/basilisk55/commits/master Was it simply forgotten to be properly committed in the GitHub repo or was it never included in the latest builds? I attempted to load https://github.com/roytam1/basilisk55/compare/c952169...ea6e33c for a more detailed changelog between latest and previous builds (needed for a bug to be reported in a future post), only to be notified by GH that: "There isn’t anything to compare."

This one DOES NOT officially support NM28, only the official Pale Moon releases are... Excerpt from install.rdf file for latest version 1.11: <!-- Pale Moon --> <em:targetApplication> <Description> <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id> <em:minVersion>28.14.0</em:minVersion> <em:maxVersion>31.*</em:maxVersion> </Description> Even if force-installed (you'd have to lower minVersion to 28.10.6a1), v1.11 is not guaranteed to properly work with NM28, because it now selectively applies polyfills/workarounds based on Pale Moon's platform version value : ; sadly, NM28 does not follow PM's platform version numbering (for latest NM28, it's 4.8.5) ... Any other extension that used to install and self-update in palemoon-28.10.6a1.win32-git-20220528-d849524bd-uxp-0855ba43d-xpmod but does NOT in palemoon-28.10.6a1.win32-git-20220604-d849524bd-uxp-e8b114fe4-xpmod ?

... Which add-on and from what repository? FWIW, in the latest UXP releases, there's at least one commit imported from upstream that deals with extension updates: Issue #1909 - Guard against empty update manifest URL

While being logged in, load: https://msfn.org/board/attachments/ Tick the box in the far right on the attachments you want to delete, then click the trashcan icon; beware: can't be undone! Your original posts where the deleted attachments used to be in will now have empty placeholders (in the case of images...)

Sadly, no idea - as I've posted previously, I don't own a "Smart" device, so Android/iOS aren't able to "outsmart" me ... But I'm sure an online search will get you all the info... It will: Google Extends Chrome Support for Windows 7 Users They have already: Firefox DNS-over-HTTPS (DoH)

... That still requires access to a non-XP machine for the actual patching... BTW, the author of FlashPatch recommends "Windows 7 and above", however a fully updated WinVista SP2 + .NET Framework 4.6.x should also do the job : https://github.com/darktohka/FlashPatch/issues/24#issuecomment-1063519569 https://github.com/darktohka/FlashPatch/issues/24#issuecomment-1066203448

libstagefright fix by @roytam1, committed more than two days ago, as a response to a bug report by yours truly : libstagefright: relax ctts flags checking. libstagefright fix by Moonchild ("official" UXP), committed 21 hours ago: No issue - relax ctts flag checking in media/libstagefright MCP's code is almost identical... Conclusion/Question: Is Moonchild now following "roytam1/UXP" ?

I have a portable "installation" of 360EEv11 here, so it's not associated with the ".pdf" file extension, however, when I open a new tab there and drag-n-drop a local PDF file, it does render as expected: Visit "chrome://plugins" and verify BOTH "Chromium PDF Plugin" & "Chromium PDF Viewer" are "enabled" and "Always allowed to run":

... The "desktop" app does NOT, as it's electron-based... OTOH, I'm not sure about current support status of Git-For-Windows ; I have an old version here, "2.22.0.windows.1", that works OK on Vista SP2 32-bit: CLI version also available (using mintty terminal):

https://bonkersabouttech.com/what-is-a-tor-exit-node/

Coming to a "theater near you", even on Windows, starting with Google Chrome v103 : https://support.google.com/chrome/a/answer/7679408#winDNSdef Non-Enterprise ordinary users won't have the option to "disable", unless, of course, the "community" juggles something up...

Many thanks indeed for identifying the root cause of that "small annoyance" (I'm not that often on Twitter, anyway ...), congrats for managing to fix it, after all! However, it seems I "attract" Serpent bugs "like a moth to a flame", because I just bumped on a new regression I consider far more serious than the inability to play back a specific GIFV Twitter clip: Currently, Serpent 52's native (JS-based) PDF Viewer (pdf.js) is BROKEN . STR 1. Install latest Serpent 52 32-bit build; package filename: "basilisk52-g4.8.win32-git-20220521-3219d2d-uxp-1e871780f-xpmod.7z" 2. Launch a fresh, pristine, St52 profile 3. Load "about:preferences#applications"; you should be able to verify that the default action (handler) for PDF files is "Preview in Serpent": 4. Open a new tab and try to load the remote PDF file below: https://helpx.adobe.com/pdf/coldfusion2021-support-matrix.pdf Alternatively, drag-n-drop onto that new tab a locally saved PDF file 5. Expected Behaviour: The PDF file should be rendered in St52's native PDF viewer (pdf.js); actual result: An empty tab : I do understand ; time is also precious here, but to save you some precious time, I narrowed down a regression range: Last GOOD build: "basilisk52-g4.8.win32-git-20220423-f94c0da-uxp-059e35a46-xpmod.7z": First BAD build: "basilisk52-g4.8.win32-git-20220430-3219d2d-uxp-cf4e046f9-xpmod.7z": Hopefully, this can be identified and remedied in time for Saturday's UXP "releases" ...

Many thanks! I'd have expected an auto redirection to take place to the new hostname ("thedndsanctuary.eu" -> "dndsanctuary.eu"), but it's probably just me being "grumpy" ...

Finally, some good news! After a faulty 1.367.4xx.0 series of WD definitions, which included buggy mpasdlta.vdm files of versions 1.367.413.0, 1.367.415.0, 1.367.423.0, 1.367.432.0, 1.367.435.0, 1.367.447.0, 1.367.457.0, 1.367.472.0, 1.367.487.0, 1.367.491.0, WD defs of v1.367.494.0 and higher are, once again, "OK", i.e. they no longer cause WD's Windows service to crash under Vista SP2 ; series "5xx" is already "out", I successfully ran a "Quick Scan" with v1.367.502.0 : ... I won't go as far as saying that MS staff monitor this thread (), but either via internal testing or via some other party reporting it to them, the issue has been identified and mitigated... Until the next c*ck up and until Jan 2023 (when I expect WD+MSE standalone defs to be retired by MS) ...

A definitive "CloudFlare Browser Check" is trying to log-in to GitLab: https://gitlab.com/users/sign_in BTW, this happens when site admins - who are CF clients - have enabled a feature called "Browser Integrity Check" (BIC) ... CF have recently abolished the CAPTCHA challenges as part of BIC, replacing them with automated checking (JS) scripts, requiring the browser to pass mathematical "challenges"... It was those scripts that were being "racist" towards non-mainstream browsers and thus those browsers (including the UXP ones) were outright denied access to sites CF intend to "protect" from "unwelcome" traffic... That CF issue (please search this thread for more details) finally made it to prominent web sites/forums, not to mention the "loud voices" of some Pale Moon users (to which we owe big thanks ) on CF's Community Forums, so it had to be acknowledged and acted upon by real CF devs... It was "them" who fixed it for us (but some more "obscure" web browsers, like the Qt-based Otter Browser, are reported to still suffer from this "racism" ) ... OT: @Dave-H : Do you, hopefully, know what happened to https://thedndsanctuary.eu/ that used to post invaluable info about the Otter Browser ?

... issue persists with latest v1.367.457.0:

WD x64 definitions, version 1.367.386.0 (engine version 1.1.19200.6): https://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/1.367.386.0/1.1.19200.6/amd64/mpas-fe.exe WD x64 definitions, latest version: https://definitionupdates.microsoft.com/download/DefinitionUpdates/amd64/mpas-fe.exe BTW, I need some feedback from Windows Vista SP2 users (x86 and/or x64) running the nag-free version (4.4.304.0) of Microsoft Security Essentials: Are you able to update MSE's defs past v1.367.386.0 without MSE's Windows service crashing? Manual download links: https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpam-fe.exe https://definitionupdates.microsoft.com/download/DefinitionUpdates/amd64/mpam-fe.exe

Well, it looks like Microsoft have managed to kill Vista's native antispyware, Windows Defender (not to be confused with Microsoft Defender Antivirus for Windows 8.1+) for good , either inadvertently or deliberately... I won't be discussing the "merits" (or lack of...) of WD as a proper ASW solution, but I still have its real protection ON, along with my third party Security Suite, and have it scheduled to perform a "Quick Scan" every night at 23:00 (in my timezone). For those not following this, MS have, since long ago, stopped issuing WD definition updates via Windows Update, those were used to be called "Definition Update for Windows Defender Antivirus (!) - KB915597" and the last one on this machine (v1.297.531.0) was received and installed on July 6th 2019: A few days later in that July, Vista SP2 was severed from the WU servers , due to the SHA-2 implementation in those endpoints... It is unknown to me when exactly MS stopped altogether the production and distribution of the KB915597 updates (they're no longer to be found in the MUC either, unlike the KB2310138 ones, which are definition updates for Microsoft Security Essentials, still offered via MU on supported platforms - namely Win7 SP1). But MS continued to offer these definition updates (for Win7 SP1 & WinVista SP2) as standalone mpas-fe.exe files, accessible from their "Microsoft Security Intelligence" portal - it used to be called otherwise in the past, but the old name eludes me now... For the x86 architecture, the DL link is: https://go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x86&eng=0.0.0.0&avdelta=0.0.0.0&asdelta=0.0.0.0&prod=925A3ACA-C353-458A-AC8D-A7E5EB378092 An alternative, more "user-friendly", link is: https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe Running the downloaded "mpas-fe.exe" file would update WD's definitions/signatures in a matter of ca. 20s (YMMV). In mid-October 2019, the file, as well as its internal constituents, ceased being dual-signed and was henceforth only SHA-2 signed; in order to make the "updated" files install on Vista SP2, updates from WS2008SP2 were necessary, that backported SHA-2 file signature verification to Vista itself... Since that time, Microsoft goofed-up on several occasions, by issuing 1. a "mpas-fe.exe" file with SubSystem version 6.1, that wouldn't run under Vista/WS2008 (6.0) 2. internal components of said file (e.g. mpengine.dll, MpSigStub.exe) also with subsys version = 6.1, or 3. internal engine file (mpengine.dll) compiled to target Win7 SP1 as minimum OS, calling functions missing in Vista's kernel . HexEditing the infringing file(s) would invalidate their SHA-2 file signatures, making them not verify and not install... These "hiccups" were, one way or the other, reported to MS, especially by WS2008SP2 ESU paying customers, and they were eventually mitigated (within several hours or, more commonly, days). FWIW, I have the following batch file I run daily, to update my WD defs: @echo off start /min /wait cscript "create_restore_point.vbs" start /min /wait wget -S -N --unlink --secure-protocol=TLSv1_2 "https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe" if exist mpas-fe.exe start /min /wait mpas-fe.exe The .vbs script (not posting it here, unless asked) creates a restore point prior to the update, while wget only downloads the file if it's newer (on the server) from the one previously fetched on disk... Come Tuesday May 24th, 2022 - file "mpas-fe.exe" is now at versions 1.367.3xx.0, engine is at version 1.1.19200.6, all looked fine, including version 1.367.386.0 (signed on 24/05/2022): https://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/1.367.386.0/1.1.19200.6/x86/mpas-fe.exe BTW, that direct link will expire soon (in a day, two at most...); with that version installed, WD is "happy", ... I even performed a "Quick Scan" to completion: But 1.367.386.0 was to be the last of the "3xx" series, then came the "4xx" ones: 1.367.413.0, 1.367.415.0, 1.367.423.0, 1.367.432.0 (latest at the time of writing), which did keep, however, the same engine version, 1.1.19200.6. Each one of these will cleanly install on top of 1.367.386.0, but won't install in the normal fashion on top of one of the previous "4xx" ones (e.g. 1.367.423.0 updating 1.367.413.0, etc.); in fact, installing any of these "4xx" ones on top of "386" will go fine initially, but after 20-30s WD will "crash", due to the WD service having stopped: If you try to perform a "Quick Scan" before WD crashes, you'll get a similar breakage: So, there's something inside files "mpasdlta.vdm" (the actual defs file) of the "4xx" series that makes the WD service crash under Windows Vista SP2 ... The release of that "1.367.4xx.0" series signals the death nail of WD under Vista, because it becomes unusable/non-updatable anymore... Mind you, returning WD to a working state, with 1.367.386.0 installed, wasn't an easy thing either (but I did it), as running file mpas-fe.exe (of that version) doesn't cut it... But I probably shouldn't go into specifics, because, in reality, it's a moot point: in 2-3 days' time, WD will nag me about "out-of-date signatures", however, if things haven't been changed by MS (I don't expect them to be ...), the route to update those signatures won't be "enforceable"... Thanks Microsoft, once more ... In all honesty though, I'd have expected them to end WD support in Jan 2023, same time the Win7 SP1+WS2008 SP2 ESU plans end, so am not fully convinced they had a mind to prematurely kill it on Vista... The amount of WD users on WS2008SP2 is probably zero now, so news of this will likely never reach MS staff... To quote "The Doors":