Mathwiz

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.

Roger. Downloading & installing now.

Big difference: 15 f/s on XP vs. 93 f/s on 7, using Serpent on the same machine. (I'm a bit surprised that my home machine is almost twice as fast as my work machine at this particular task, but whatever.) I assume most of that is due to not using hardware acceleration.

@FranceBB, you should consider Serpent 55 and the Multi-Account Containers extension. Force gmail, youtube, and the like into a "Google" container where you can sign in and stay signed in - but don't force google.com itself into that container. Then sign out of Google in your "default" container, which is where you'll be searching from most of the time. There's no reason to make it easy for Google tie every bloody search you do to your Google ID, and this extension makes protecting your privacy easy and painless. Personally, I'm less worried about the US's NSA and the UK's MI6 than I am about Google themselves. After all, the former two can probably get any info they want about me whether I use Google or not, but Google's entire business model is to collect as much info as possible about their users and sell it to anyone who's willing to buy. You may not be paying for their services with money, but they aren't really free; at least make Google do a little work for their "payment" (your personal info) rather than just giving it to them. As to the original question, I've used Startpage.com as my default search engine for some time. AIUI it's actually a "meta-search" that feeds your searches to several search engines (including Google) and consolidates the results, so you aren't really giving up Google's advantages by using it; but at least you're avoiding "the filter bubble."

I have Flash but leave it disabled unless I come across a site that needs it, so I haven't really tested it with e10s. Not surprising in the least. Code-signing certificates cost money and @roytam1 is building these browsers for free. I'm sure he'd be happy to sign them if you ponied up to buy him a cert. Or you could go with MyPal if their .exe files are signed. AIUI there's very little difference between MyPal and NM (mostly just which of MCP's builds are used). BTW I don't think e10s even works with NM; only with Serpent.

Well, Silverlight and Java tests seem to run OK; I realize that's not a very thorough test, but all plugins use plugin-container.exe AFAIK. That's weird. I got 181 fps on 32-bit St 55 (which AIUI is basically FF 53) on 64-bit Win 7. I wonder if the older FF might outperform the newer one on Win 10? Next week I'll try it on both the Win 7 and XP "sides" of the same PC and see how much difference HW acceleration makes.

Interesting! At first, toggling that pref to true had no effect on my Win7 system; with processCount set to 2 and 2 tabs open, I had 4 processes before, and after, toggling separateFileUriProcess and restarting. But then I read the pref name closely, opened an HTML file on my own PC, et voila! A fifth process appeared. Closing the tab showing that HTML file dropped the process count back to 4. I don't know that it's necessarily worth toggling that pref, even on Win7, but it's another surprising feature of this browser. Yeah, I know; but what I didn't mention originally is that I actually looked at the XP-blocking code at the Bugzilla link you provided earlier: #if defined(XP_WIN) if (Preferences::GetDefaultCString("app.update.channel").EqualsLiteral("release") && !IsVistaOrLater()) { gMultiprocessBlockPolicy = kE10sDisabledForOperatingSystem; return gMultiprocessBlockPolicy; } #endif (This was back around FF 48.) As you can see, it uses an #if defined(...) block to check whether the build targets Win XP, but it does a run-time check of the app.update.channel pref rather than using another #if defined(...) block. Obviously the code has been changed since then - otherwise e10s would work on Win XP in FF 52 ESR since it's not a "release" build - but I figured they probably still did a run-time check, so changing the pref was worth a try. However, it didn't work. Of course I don't know if building the browser as "default" vs. "release" or "esr" would let e10s be enabled the "normal" way. I'll leave that as an exercise for others. As long as there's another way to enable e10s without recompiling the browser, I'm happy; just very curious.

It's quite a bit more responsive. With dom.ipc.processCount set to 1, the active tab tended to "hang" when another tab was refreshing in the background. When set to two, it didn't seem to hang. This was on a Win 7 64-bit system (though it was the 32-bit version of Serpent 55). I don't know if it will improve as much with 32-bit Win XP as it did with 64-bit Win 7, but it seems OK on my Win XP VM even with dom.ipc.processCount set to 1. So you should probably just leave it at 1 unless you're having "hangs" like I was. There's probably not much point in setting it higher than 3 unless you have a 64-bit OS with beaucoup RAM. I sort of expect RAM usage to be higher with more processes, but as long as you have enough RAM, I'm hoping you'll find FF / Serpent to be more responsive. Glad to hear it. That's what e10s was supposed to do.

Q: A: Yep! Apparently there's always one "extra" process when using Serpent 55 on my Win 7 system at home. Edit: Note that this only happens with Serpent 55. Serpent 52 always gives 2 processes when dom.ipc.processCount is 1, and 3 when it is 2; regardless of OS. BTW, browser performance seems to have improved a lot with that simple change.

Well, there is a string pref called app.update.channel. In FF ESR builds, it's set to esr. In "regular" FF builds, it's set to release (I think). In @roytam1's Serpent builds, it's set to default. Note: it doesn't show as boldface in about:config (unless you change the default value); I'm just using bold here to indicate literal values. Originally the code blocking e10s on XP only applied to release builds, but our experience indicates e10s is now blocked in esr builds too. To see whether the block applies to default builds, I changed app.update.channel from esr to default and restarted FF 52. Unfortunately, about:support still indicated 0/1 (Windows XP). So apparently the code was changed at some point to block e10s on XP in all FF builds. My guess is that the code was changed after Basilisk 55 was forked from FF 53, which would have been around the time FF 52.1 ESR was released. I distinctly remember having two firefox.exe processes through several updates of FF 52.x ESR, but I don't remember exactly which version that stopped with. That doesn't explain Serpent 52 though. Basilisk (Serpent) was forked from FF 52, so it would have inherited the same code; so one would expect it to work like either Serpent 55 (where it always works) or FF 52 (where it's only blocked in WinXP). But since MCP eventually intends to remove e10s from Basilisk entirely, I'm guessing that somewhere along the line they changed the code to block e10s entirely unless forced.

Unfortunately Python 3.5 isn't a full package, so it's not as user-friendly as the official Python 3.4.4 package is. I think you'll have to create your own Python 3.5 folder in the Start menu. Put two shortcuts in the folder you create: one to <Python 3.5 installation path>\python.exe, named Python 3.5 command line, and one to <Python 3.5 installation path>\doc\python350.chm, named Python 3.5 Manuals. Hopefully that will at least get you started.

You mean posts? Just ask a moderator, such as @dencorso. I think we used to be able to delete our own posts but we had some abuse, so that functionality was removed

Strange; it now seems to be working for me too, at least on WinXP. (I'm using the 2019-04-05 build of Serpent 55, in case that makes a difference.) I set dom.ipc.processCount to 2 and with two tabs, sure enough; I have 3 processes now. No idea what I did wrong last time. Its behavior on Win 7 is puzzling. I always have 3 processes even though dom.ipc.processCount is set to the default of 1. If I set it to 2 will I get 4 processes? I'll investigate that further tonight after I get home.