Mathwiz

Interesting that a "native" Basilisk user agent works, given that a "native" FF 52.9 UA does not! It implies that Github has chosen to support Basilisk (at least, the official version), which is hopeful for the future. Once Github stops supporting 60.9, it may be best to move to the above (via a SSUAO) vs. trying to spoof FF 68. Why lie if telling the truth works?

I agree with @VistaLover; it seems to work OK for me. But I do use a user-agent override to Mozilla/5.0 (Windows NT 6.1; rv:60.9) Gecko/20100101 Firefox/60.9 ... which can be implemented either by a github.com-specific SSUAO, a general UAO, or by the compatibility prefs @VistaLover mentioned. Without a UAO of some sort, Github.com hasn't worked with FF 52 or Serpent for quite some time. (I agree that before long, we'll need to start spoofing FF 68 to have a chance, and even that may not work, depending on what new Javascript and/or CSS features Github decides to start using.) Also, if you have enabled either dom.webcomponents.enabled or dom.webcomponents.customelements.enabled, you need to disable them for Github.com to work with Serpent. (I have no idea why.) Everything seems to work fine with these disabled, although disabling them costs you a few points on html5test.com....

Getting back to the original topic, I was intrigued by the discussion of FAT32 alignment. So I ran a couple of tests with a 64GB SanDisk Ultra flash drive plugged into a USB 2.0 port. First, I formatted it with GUIFormat.exe, a popular freeware FAT32 disk format utility. Then I ran the CrystalDiskMark6 benchmark on it: Not very impressive, but I was only using a USB 2.0 port. Next, I reformatted with RMPrepUSB, which aligns the clusters with the flash drive's (presumed) 4K sectors, and ran another benchmark (with the same USB 2.0 port): OK, that's only about a 5-10% improvement in random read speed, but a 40% improvement in random write speed, and a whopping 50% improvement in sequential write speed! With this alignment, FAT32 actually out-benchmarks (slightly) NTFS! Pretty impressive and clearly worth doing if you need a FAT32-formatted flash drive or AF hard drive. Edit: Rezeroing the flash drive (easily done with "format i: /p:1" on Windows Vista or later; WinXP unfortunately does not recognize the /p switch) before formatting with RMPrepUSB produced a bit more improvement: ... although the read speeds dropped a bit from last time, so the previously noted improvement may have been a fluke. Of course, the improved write speeds probably won't last as the flash drive fills up again, but if you're formatting, you might as well start with the drive as fast as possible.

I realize uBlock Origin isn't an antivirus product, but it does support several anti-malware filters, so I think a post on uBO is justified in this thread: It's not just you; Mozilla long ago decided (capriciously, IMO) to remove all "legacy" (by which they mean pre-WebExtensions) add-ons from addon.mozilla.org, and won't sign any new "legacy" .xpi's. They weren't specifically picking on uBO, but that did leave FF stuck with WE version 1.17.4. (Our pal VistaLover detailed a way to get 1.18.4 working on FF 52 in another thread, but it required jumping through several hoops.) As for MCP, they've gone the opposite direction and removed all support for WebExtension add-ons from their products! This bifurcation is why JustOff supports a "legacy" version of uBO (leaving GorHill to focus on the WebEx version): the legacy version is for PaleMoon & Basilisk; the WE version for Firefox, Waterfox, etc. As you discovered, the unsigned legacy versions of uBO will work in FF 52 ESR, provided you turn off code-signing enforcement, so FF 52 ESR (and @roytam1's Serpent, which doesn't support code signing but didn't remove WE support) give you the choice of either a legacy or WE version of uBO. As I've posted elsewhere, I personally prefer the legacy version, since on these browsers, a few features are only available with that version. Regardless of which version you choose, uBO comes with four filter lists of malware domains. I enable all four in my browsers.

Despite the cautionary note I posted above, I still use Avast Free on my XP VM myself. However, my browser of choice is @roytam1's Serpent, which Avast doesn't appear to recognize, so it doesn't set the SSLKEYLOGFILE environment variable. That would normally leave me without browser protection. Luckily, Avast has another, more transparent way to monitor browser traffic: an add-on, a la uBlock Origin. But since Avast doesn't recognize Serpent, it didn't install its add-on into Serpent either! Luckily, that's easily fixed: Start Firefox 52 Go to about:profiles or about:support (either will work) Open your profile folder (you can now close Firefox) Navigate to the "extensions" subfolder Start Serpent Go to about:addons Find Avast's .xpi file in your Firefox profile's extensions folder from step 4, and drag it onto Serpent's about:addons page Accept the prompts, and Serpent will copy the Avast add-on into your Serpent profile and install it. The drawback to the add-on (vs. SSLKEYLOGFILE) is probably speed; Serpent seems to use quite a bit more CPU with the add-on installed - and of course, I'm sure Avast is monetizing the data it collects this way too. So not a perfect solution, but the security vs. privacy trade-off may be acceptable: just remember to disable the add-on if you need to do any truly "private" browsing. Note: When I installed Avast, it also installed a second add-on into Firefox: a "comparison shopping" add-on. I didn't feel I needed its help, and the privacy implications of that one were obvious, so I removed it, but I kept Avast's main add-on installed.

Works in Serpent 55 for me but not in New Moon 27. However I just tried a straight download of NM 27 without any additional filters/codecs/etc. so that may be why.

A word of caution about Avast: https://textslashplain.com/2019/08/11/spying-on-https/ TL;DR: Avast uses an obscure feature of Chrome and Firefox, an environment variable called SSLKEYLOGFILE, to spy on https: traffic. Using Process Explorer, I confirmed that it also does this on XP with Advanced Chrome and Firefox 52.9. Note: it does not appear to do this with New Moon or Serpent. It probably looks at the name of the .exe; basilisk.exe is probably too obscure, and it wouldn't surprise me if MCP removed this support from Palemoon.exe (and hence New Moon), since it could obviously be easily abused. This isn't necessarily a bad thing. The whole idea of AV software is to scan everything coming into your PC for malware, so scanning https: traffic could just be Avast doing its job. However, the article's postscript is cause for concern: But if you think about it, what else would you expect? Avast itself is free; they have to make money somehow....

I agree with @win32; they're probably sniffing the OS version in the user-agent string. Why they suddenly think that matters is beyond me. "Not supported" should merely mean, "if it doesn't work, don't call us;" it shouldn't mean "we're going to deliberately lock you out." In FF 52 or one of its derivatives, go to about:config and try setting general.useragent.override to Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.9) Gecko/20100101 Firefox/60.9 That will tell them you're using 32-bit Firefox, version 60.9, on 64-bit Windows 7.

I don't think it will work if you install it now. Google has moved up to Widevine version 1.4.10. I think version 1.4.8 will still work if you started using Netflix while it was supported, but they won't issue new licenses for version 1.4.8 any more.

Check out this plugin: https://firefox.maltekraus.de/extensions/add-to-search-bar

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: