Mathwiz

Not positive but I think those *xp.dll files were from @Dibya's Extended XP kernel, not from One-Core API. You might PM him, but I haven't seen him around lately.

Just FYI, here's the author's Web page: http://www.gerhard-schlager.at/en/projects/ctfmonremover/ Has info on what CTFMon does and whether you need it. Bottom line AIUI: you need CTFMon if you use Speech recognition Handwriting recognition Multiple keyboard layouts (e.g., for multiple languages) (Probably) Asian languages/character sets (Chinese, Japanese, Korean) If you use none of the above, might as well get rid of it! AIUI it should prevent the vulnerability, which is caused by the CTFMon.exe service not validating requests from clients. The CTFMon remover appears to replace CTFMon with a dummy program that doesn't actually handle client requests, so I'd think it can't be used to compromise your system like the "real" CTFMon can.

Unfortunately, for what Dave is doing - blocking a few Web sites in the hosts file, then bypassing those blocks for a particular browser - he needs a proxy server that's outside of his own PC, where it won't be affected by the hosts file. The Proxomitron might actually work, but it'd need to be on a separate system (although I suppose a VM might be made to work).

That's an elegant solution, @Dave-H! If FF accesses one of the three sites blocked in HOSTS, it instead goes to the proxy server you specified, which does its own DNS lookup (and presumably doesn't have those three sites blocked)! Anything else goes direct.

Well - as long as you never need to visit www.sky.com....

Probably a registry thing: more often than I'd like, 8.3 file/path names are stored in the registry, instead of the long file/path name in quotes. Correct; of course to add to the confusion, the Serpent .exe file is still named basilisk.exe (as the New Moon .exe file is named palemoon.exe). Even more confusing, clicking Help / About opens up a dialog entitled "About Serpent" but containing the text "Basilisk is community software released by the Pale Moon team and Mozilla developers."

That matches @VistaLover's results. (SSUAOs don't work in FF 52ESR unless you install some funky JavaScript to run at startup, or use an add-on like User Agent Switcher.) I wonder if @Dave-H's results are a kind of "runs once" situation? Dave, if you have the time, try creating another clean FF 52 profile (don't forget to turn off the proxy); see if Skype works once, then fails after you exit and restart the browser?

So, XP probably comes with it; 2000/98/ME probably get it with Office XP or later. I wonder what starts the process? Let me try starting an Office 2010 app and see what happens. Edit: Strange; Excel 2010, PowerPoint 2010, and Word 2010 don't seem to start CTFMon.exe. Maybe it only starts if you use one of those alternate input methods. If so, most of us are probably safe.

I suspect that a lot of Win 7 users are either upgrading to Win 10, switching to new Win 10 machines, or just abandoning Windows altogether. That's probably due to all the hype M$ is pushing as Win 7 EOS nears. Win 7 users abandoning Windows would push up the percentages of all other Windows versions. That may explain the apparent rise in Win XP users. To confirm whether the apparent rise in XP use is real, you'd need to see the raw numbers, not just percentages.

I'm probably in way over my head here, but.... CTFMon.exe doesn't seem to exist on either my Windows XP system (even though Office 2010 is installed) or my Windows 7 one (even though Office 2013 is installed). Edit: That was wrong; CTFMon.exe does exist. (I was fooled by SwiftSearch doing a case-sensitive sort on file names.) But it doesn't seem to be running as a process. Also, WinObj's "BaseNamedObjects" doesn't show any MSCTF* object names on either system. On Windows 7, there is a MsCtfMonitor task that is run at log-on. That task doesn't exist on XP. Concentrating on XP hereinafter, MSCTF.dll and MSCTFIME.ime do exist, in C:\Windows\System32\. Per Process Explorer, most processes seem to have MSCTFIME.ime loaded. I assume that's necessary to read keyboard input. At least one (Windows Live Mail) also has MSCTF.dll loaded. This makes me think that on at least some XP versions, CTF is implemented via simple .dll's vs. a client/server architecture; those versions may lack the vulnerabilities discovered by Google Project Zero. But the screen shot above implies that other XP versions do implement clients and a server, so they would be vulnerable. It would be interesting to know which XP versions include CTFMon.exe - perhaps MUI versions, and/or versions with Eastern (Chinese/Japanese/Korean) characters?

Another "about:" URL that might help is "about:support". Try this on your regular profile, and scroll down to "Important Modified Preferences." (Might be easier to print them out.) Compare with your "clean" profile (should be very few there) and see if any look like they might be related.

Does it work if you roll back to last week's version?

Here's how I do a "clean" profile: Start Firefox. (First off, rename your original profile back) Type "about:profiles" in the address bar Click "Create a New Profile" Give it a name; e.g., "Clean Profile" and let the browser build it Under the newly created profile, click "Set as Default Profile" (do not click "Launch Profile in New Browser;" it won't be entirely "clean") At the top, click "Restart Normally" Do your testing To switch back, do steps 2, and 5 and 6 again with your usual default profile You can keep the "Clean Profile" for later tests of this sort. If it works with a clean profile, you can create yet another profile, then start adding back your add-ons, etc. until you find out what's causing the problem with Skype.com.

On a hunch I decided to check skype.com's TLS status at Qualys.com's server test site. This will take a few minutes. I'm sure skype.com will get an A; what I'm interested in is the handshake simulations. Maybe they've "upgraded" security in a way that FF 52.9 doesn't support. Edit: Well, it may have been a nice idea, but ... no banana. Simulation shows FF 49 on XP SP3 successfully connects to both skype.com and secure.skypeassets.com. So it doesn't seem to be a TLS issue. I guess that makes sense, because you can get to the logon screen, but it was worth a shot. BTW, the SSUAO for skypeassets.com doesn't seem to be necessary after all. I just tried without it and was still able to log in. Any chance you could test @roytam1's Serpent? If it works, we'll at least know it's something about the browser, not your PC or location.

I use identical Chrome 73 on Linux SSUAOs for three sites:

No, the installer requires Win 7. You have to download the .zip and install manually.

Still lets me log in with Serpent 55 using the "Chrome 73 on Linux" user agent I stole from that add-on a few months ago. Does the problem occur later, after you've already logged in?

Definitely one of the weirdest (not to mention most frustrating) things I've had happen in a long time. My working theory is that some sort of power surge or interference "stunned" them all overnight, then when I found the problem and unplugged and re-plugged several of them, they woke up and eventually found each other, even though nothing seemed to happen at first. Although that does make me wonder if they're quite a bit smarter than they're letting on

For several years I've been using a set of four TP-Link TL-PA2010 powerline adapters to network various devices throughout my house. Came home today and they were all disconnected from each other. The center LED is off on all four. Normally when this happens to one, I just unplug it and plug it back in, and it reconnects to the other three. At worst I may need to "pair" it with one of the others. But today all four were disconnected, unplugging/plugging back in does nothing, and none of them will "pair" to any of the others. Right now my PC and Roku are limping along on WiFi but I still have two devices completely disconnected from the network. Anyone have any idea what could possibly be going on? Edit: OK, this is getting spooky. Everything just came back on! I did nothing. Do I have a poltergeist?

Thanks for your question, but could you provide just a few more details please? Which browser are you using? Which version? Which youtube video are you trying to play?

Another small advantage of multiprocess mode: if you experience a crash, it won't normally take the whole browser down. Instead it will just take down the tab with the problem, and give you the option to try to reload it; much less disruptive than having to restart the browser and reload all open tabs.

Couple of things: If ABP is too resource-intensive have a look at uBlock Origin. It's purported to be much less resource-intensive. As posted elsewhere I prefer the "legacy" version (currently 1.16.4.11) to the WE version because some privacy features don't work on FF 52 with the WE version. The companion add-on "uBlock Origin Updater" will keep you up-to-date on the latest legacy version of uBO. Feel free to experiment with dom.ipc.processCount. The best setting probably depends not only on available RAM but also on your browsing habits, so the "best" setting will likely vary quite a bit from person to person.

Yes, that's the same problem @Sampei.Nihira was having. Cloudflare seems to have some sort of routing problem between much of Europe (but not all; Greece reportedly is fine) and Roytam's server. @Sampei.Nihira found a free Web proxy that let him work around the problem. Look a couple of pages back and you should be able to find his post.

Well, you're right - but so was I. There are two update mechanisms in FF and its offshoots: manual and automatic. And believe it or not (I certainly didn't believe it until I confirmed it myself) on Serpent 55, they yield different results! As you found, the manual process (where you ask the browser to check for updates) stops at 1.17.4. But the automatic process will eventually offer 1.21.2 (which is broken on St 55, as you noted). What the heck is going on here anyway? I think I found the answer in these two prefs: extensions.update.background.url;https://versioncheck-bg.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=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% 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=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% You'll have to scroll to the right to see the relevant difference (it's subtle). The "appVersion=" query string passed to the server is the variable %APP_VERSION% in the extensions.update.background.url pref, but it's hard-coded as 53.0 in the extensions.update.url pref! As it happens, uBO version 1.17.4 is the latest version claiming to run on FF versions 52.0 through 54.0. All later versions claim 55.0 or later is required. So when you manually check for updates, AMO only offers uBO version 1.17.4. but when the browser does it automatically, %APP_VERSION% gets replaced with 55.0, so AMO offers the latest version (1.21.2). This discrepancy goes back at least as far as the 3/10/2018 version of Serpent 55. I'm surprised no one has stumbled across it before now. I'm guessing the hard-coded 53.0 was meant to fix incompatible updates being offered (Serpent 55 was forked from FF 53, with only a few changes back-ported from FF 54 and FF 55, so many add-ons targeted at FF 54 or 55 won't run, now including uBO 1.21.2), but whoever put it in (MCP?) forgot to make the same fix to the background pref. It would make more sense to hard-code 53.0 in both update prefs and eliminate this oddity. Side note: if you go to about:addons, click Get Add-Ons, then click Find More Add-Ons, what AMO offers depends on your user agent. By default, it won't offer anything except a download of Firefox (even in FF compatibility mode), but if you use, say, a SSUAO to provide a "pure" FF user agent, it will offer either 1.17.4 or 1.21.2, depending on which FF version you pretend to be. If you want to "live on the edge," you could put 55.0 in a SSUAO for AMO. If you also fix the background update pref, you wouldn't be offered any uBO updates past 1.17.4, but could still manually browse AMO and try later versions to see if they work (as mentioned, 1.18.4 will and 1.21.2 won't, but I haven't tried versions in between to find out where the "cutoff" is).

Aside from what @win32 mentioned, Vista can still get updates. Not directly, but Server 2008 updates can be installed on Vista, and they'll keep coming for at least a while longer. But software support is about the same. Pretty much everyone who's dropped XP support has dropped Vista support too :(