Mathwiz

Not sure what's going on with 'pip install theano'. It worked for me (or seemed to). Maybe a Python expert can chime in? On the second screen shot, try executing each 'pip install' command separately; i.e., 'pip install -U conda', 'pip install numpy', etc. Some of these don't seem to exist, but others installed fine for me.

Doesn't seem to matter though. @roytam1 rolled back to 3.43 in the 2019.04.27 builds due to the 64-bit version of NM 27 crashing on startup, so I downloaded the Serpent 52.9.2019.04.19 build, which AIUI has an earlier NSS v3.44b, to test with; unfortunately it still fails to open https://tls13.1d.pw with the SSL_ERROR_RX_MALFORMED_SERVER_HELLO error code. That version does open the other TLS 1.3 test sites just fine though. Edit: By the way it looks like NSS v3.44 is stable as of May 10, but I have no idea whether the issue causing NM 27 to crash was fixed at the last minute.

Very first post: These prefs don't really matter when running FF 52.9 on WinXP, since it's been coded to block e10s on XP unless browser.tabs.remote.force-enable is set to true - in which case e10s is enabled irrespective of these other prefs. These prefs do matter on later Windows versions (and are the preferred method of enabling e10s) but let's stick with FF 52.9 on XP for now. Once e10s is enabled, this controls how many additional processes you can have. There's one "core" process plus one process per open tab up to the limit set by this pref. Personally, I set dom.ipc.processCount to 2. The default of 1 gives me little benefit, but larger values just waste RAM while providing little additional benefit, at least in my experience. But as usual, YMMV.

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: