Mathwiz

Well, wouldn't you know: TryAcquireSRWLockExclusive requires Win 7. Sounds like he's way ahead of you....

AcquireSRWLockExclusive was introduced in Vista, so perhaps it will at least run in Vista? As for converting to run on XP, perhaps it and related SRWLock calls could be replaced with a mutex or critical section, at the expense of performance.

Good to hear. It sounds to me like 360 Extreme Explorer includes its own TLS code a la Firefox. Older Chrome versions relied on XP's built-in code.

BTW for anyone needing/wanting to install Shockwave, here's the download link:

IIRC it didn't even come with PIP installed. So you'll need to install it if you haven't done so already. (If you need to install it, there's a Python script get-pip.py that will do the job at https://bootstrap.pypa.io/get-pip.py. Download it and type py get-pip.py to run it.) Once installed, I'm pretty sure you run commands like 'pip help' from the Windows command line, not the Python command line:

It wouldn't have to open a window to do that! It could just slip the .exe into your Startup folder invisibly, and be done with it. In fact, opening a window would be counterproductive from the malware's point of view: you might notice the rogue .exe in there and delete it. At the very least, having an Explorer window open up unbidden would be a tip-off that something was amiss. I mean, security I dig, but you guys are taking it to an extreme if you think it's a risk to let your browser ever open an Explorer window! But, whatever. As I thought I made clear, it's not that big of a deal, especially since running your browser with limited privileges has other benefits. I just thought I'd point out that side-effect in case someone else tries this trick, then later notices they can't open their download folder from the browser any more. Just trying to save some time troubleshooting why that was happening; didn't realize pointing it out would become so, um, controversial....

That wouldn't affect ... ... which doesn't even run on XP. Outlook 2010 was the last version that runs on XP. Not that I'd put that sort of thing past Microsoft; that's basically what they did with Skype Web (although you can get around it with a SSUAO). But this sounds to me more like just a screw-up, so it will probably be fixed soon. Until then, at least it still works in New Moon (and probably MyPal & Serpent).

Yes, of course; but what's the point? The only file updated by KB4462223 is mso.dll, so you're just installing the update then essentially uninstalling it again. Might as well just hide it and not install it to start with.

They're mostly making an argument similar to @Jody Thornton's: if you have PCs with older, unpatched OSes on a corporate network, an attacker can use those as "anchors" to gain access, then spread malware to other, newer PCs. Therefore keeping those PCs on your network can pose a security risk. In that environment, it would make sense to minimize the number of different Windows versions you're using, so as to reduce opportunities for hackers. But I found the article's concentration on XP troubling. After all, the same vulnerability is found in Win 7, which is found even more often than XP and is still in support (at least until January). But the article didn't bash Win 7 users; only XP users. I suspect the not-so-secret agenda was to try once again to kill off that 2-3% of the market still running XP with yet another dose of FUD. It hasn't worked so far, but why not give it another try? Indeed, it's major point seems totally irrelevant: XP is old. So? Software doesn't "age;" in fact, unlike living things, it often gets better with age, as bugs are found and patched. If the bug is particularly serious, as in this case and the Wannacry case, you may even get a patch after the official EoS date. For individual XP users, though, the time to worry will be the day a major vulnerability is found but not patched. Hmm.... I wonder if the recently-discovered vulnerability exists in Win2K? There's no patch for that OS (although I suppose you could just disable the probably-unneeded Remote Desktop service).

Pale Moon 27 and up don't run on Windows XP, but you've been running FF 52, so I can't think of any reason New Moon 28 won't work for you. Try i430vx's installer: https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-fork-targetting-xp/?do=findComment&comment=1163175

Oh, I do that already! Google is never my first choice. But most of us will have to use Google's services from time to time, and some folks prefer their search engine too; so we have to take additional countermeasures against their data collection.

Preventing the writing of registry keys is one thing, but why would malware want to open a folder window, and what possible security exposure would that pose if it did?

Multiple containers look like two different browser profiles on the same PC, with separate cookies, etc. Google's algorithms will likely interpret that as two different users in the same household, only one of which has a Google ID. Containers are just a more convenient approach than using a separate browser or profile for Gmail and YouTube. (BTW, another, similar option is private tabs, which you can create via the "Private Tab" add-on. Same idea, except you'll have to sign into Google each time. And the Private Tab add-on works with other FF-derived browsers besides St 55.) I'm sure Google employs browser "fingerprinting" techniques; thus you should employ additional countermeasures: disable Flash, which you don't need with YouTube; use an anti-canvas-fingerprinting add-on like Canvas Defender; use add-ons like uBO and Privacy Badger to block, or at least minimize, Google's tracking on other sites; and most importantly, just minimize your use of Google! Just because you're forced to use them on occasion doesn't mean you should give up. You may not be able to stop them completely, but at least you can slow them down a bit and make your info less valuable to them.

uBO v1.17.4 is the latest signed version of uBO (available from Addons.Mozilla.Org) that's compatible with FF 52*. As with all AMO extensions, it uses the WE API set. Some of us prefer the (unsigned) legacy version, 1.16.4.10, because it lets you enable the WebRTC privacy option that's greyed out on 1.17.4. But FF will automatically update a legacy uBO version to 1.17.4 unless you either: Turn auto-updates off for uBO, or Install another unsigned add-on, uBlock Origin Updater, which redirects uBO update checks to a site that only lists the legacy versions (1.16.4.x) available from GitHub *Strictly speaking, later uBO versions are also compatible with FF 52, but are flagged as requiring FF 55 or later, so FF won't update uBO to those versions.

The other vulnerabilities aren't related to Remote Desktop. That one, we got the fix for! You can safely leave the Remote Desktop service enabled. The other vulnerabilities also aren't terribly serious IMO. The risk is pretty small and XP is still reasonably safe to use. But they're still worth being aware of.

Discovered an unpleasant side effect of using PSExec to launch your browser: It's unable to open any folders! For example, you can't open the folder containing your last download, or your profile folder in about:profiles. Hardly a show-stopper, if you feel the added security is worth the relatively minor inconvenience, but it is something to be aware of.

Vista/Server 2008 can download and install KB4499180 to patch this vulnerability. Unfortunately, Server 2008 uses the same cumulative update model as IE, Win 7, etc., making it difficult to determine exactly what's included in each month's single update. But AFAICS this was the only new security issue patched this month, and we got it on XP too. So luckily, we're current for one more month. Edit: That was wrong; there was also an elevation of privilege vulnerability and an information disclosure vulnerability patched in Server 2008 this month. Of course there's no way to know whether those issues affect Windows XP, but it seems likely. We've started to fall behind a bit....

Sad but true. Thus, I reiterate: I realize not everyone will want to migrate to Serpent 55 just to use one extension, but we all have to use Google from time to time, so it's worth considering at least.

I suppose what you'd have to do is make several consecutive posts: one for each section of the file. Ran into the same problem. I did find the English version, still available on several free download sites. Once installed, Windows Update found the required security update automatically, but we don't have long on that....

There was some reason the latest FF ESR branch was delayed from 59 to 60. I thought it was for Quantum but apparently it's something else?

Hmm - article mentions XP, Server 2003, Server 2008, Win 7, and Server 2008 R2 - what about Vista?

Or you can install ProxHTTPSProxy v1.5, which supports TLS 1.3:

I'm lucky enough to have inherited "Quick Search.exe" from IE5(!) on Windows 98 (before upgrading it to IE6). Amazingly, it still works in IE8 (although most of its pre-provided search engines are ancient history now). So I never really needed to add search providers; I just added another Quick Search and was done with it. I found an article saying that Quick Search.exe was also part of TweakUI for XP, but I don't know if that is still available either. Yep. Unfortunately Startpage doesn't work (it creates HTML/CSS/etc. that isn't compatible with IE8, so the search results aren't readable); but try https://en.wikipedia.org/wiki/Special:Search?search=TEST ... in the first text field, type Wikipedia (or whatever) in the second, then click "Install". You'll be asked "Do you want to add this search provider?" and there will be a check box to make it your default. Click the check box if desired then click "Add." Now it will show under Tools / Manage Add-Ons / Search Providers. <rant>I honestly don't understand why IE (and FF, for that matter) make adding search engines such a complex mess! All any browser should need is a simple dialog box, like this one in Opera 12: But nooooo.... Instead everyone has to over-complexify this seemingly simple task with XML or JSON or some other such nonsense.</rant>

I'm not sure either, but a reasonable guess would be that if Sync sees FF 66 in the user agent string, it sends code targeted toward FF 66 that FF 52 can't run. It's the same reason Instagram doesn't work if you tell it you're on FF 66 when you're actually on FF 52. At any rate, it hardly seems worth worrying about. If a FF 52 user agent works, just use it and don't fret about it. The trick to setting a good global user agent is to find one that fixes more sites than it breaks. Basilisk and Pale Moon now use version 60.9 in Firefox compatibility mode. (IIRC FF 60 was the first Quantum version.) That seems to be a good compromise. It's new enough that sites don't issue stupid "update your browser" messages, yet it keeps the SSUAOs required to fix other sites (that break if they see FF 60.9) down to a manageable number. No doubt this balancing act will become trickier as time goes by. At some point, the number of SSUAOs needed to keep FF 52 viable will become unweildy, and it'll stop working with many sites at all, no matter what user-agent string it sends. Luckily, we haven't reached that point just yet.

Firefox sync? Use rv:52.9 and Firefox/52.9. (IOW the true values.) The SSUAO pref name you want is general.useragent.override.accounts.firefox.com. That way you can set the global pref general.useragent.override to a different value.