AstroSkipper

If anyone is wondering why I keep referring to the Nightly 114.0.3 rather than ESR or release builds on Windows XP, there is a very good reason for this. The environment variable MOZ_REMOTE_SETTINGS_DEVTOOLS only applies to Developer, Nightly or Custom builds.

In Firefox Nightly 114.0.3, Cloudflare challenges, MSFN and GitHub work fine on Windows XP. 👍

Ok. It was just meant as alternative options to get rid of or curb bot attacks. No more, no less. If you already performed such measures, then it is of course fine and purposeful. 👍

I additionally checked all MSFN accounts. At the moment, there are round about 4800 accounts with zero posts and no real activity. If I were the admin, I would delete them all. And 22 hours ago, a new account has been registered. I'm pretty sure it's also a bot account. Up until now, new ones have been created every 24 hours. So if another account is set up in a few hours’ time with no genuine activity, it is almost certainly another one. Such bot accounts are created as ‘sleeper’ accounts as a precaution for dubious activities later on.

Here is a short catalogue of measures to tackle bot attacks, generated by AI: Effective Anti-Bot Measures for Invision Community (IPS) To effectively mitigate automated bot registrations and HTTP flooding without relying on aggressive Cloudflare JavaScript challenges (which disrupt older browsers and legitimate user sessions), the following server- and application-level strategies are recommended: 1. Custom Q&A Registration Verification Standard reCAPTCHA v2/v3 is routinely solved by modern bot frameworks. Replacing or supplementing it with custom, forum-specific logic questions (e.g., "Which Windows version was released after Windows 2000?" -> "Windows XP") stops automated registration scripts dead in their tracks. 2. Integration with StopForumSpam & Project Honey Pot APIs Enabling real-time API checks during registration cross-references incoming IPs, email addresses, and usernames against global spam databases. This silent check drops over 90% of known bot accounts before the registration form is even submitted. 3. Disposable Email Address Blocking Implement a dynamic domain blocklist for temporary/disposable email providers. Spambots rely heavily on these services to complete automated email verification loops. 4. Nginx / Apache Webserver Rate Limiting (limit_req) Configure rate limiting on critical endpoints such as /register/, /login/, and /search/. If an IP exceeds a reasonable threshold (e.g., more than 2–3 registration attempts per minute), the webserver returns an immediate HTTP 429 (Too Many Requests), preventing PHP and MySQL from being overwhelmed. 5. Fail2ban IP-Jailing at the Firewall Level Deploying Fail2ban to parse access logs allows the server to automatically block IPs via iptables if they attempt rapid-fire POST requests to sensitive endpoints. 6. Targeted Cloudflare Firewall Rules (WAF) instead of Global Rules If Cloudflare is utilized, avoid global "Under Attack" mode. Instead, set targeted Web Application Firewall (WAF) rules that specifically challenge or block traffic originating from known datacenter ASNs (AWS, DigitalOcean, Hetzner, etc.) or restrict access solely to the /register/ URI, leaving general browsing unaffected. 7. New Member Moderation Queue Require manual moderator approval for the first 1–2 posts of newly created accounts. Removing the immediate visibility of spam posts eliminates the incentive for spammers to target the platform.

So, after three hours of downtime, I can now access the site from Germany using my German ISP. We’ll see how long this lasts.

The US IP (New York) assigned by VPN enables me to access MSFN successfully. The German IP addresses allocated by my ISP do not. That is a fact. There is no getting round it.

I can't confirm this. My German ISP is completely blocked by the MSFN server. When using VPN with a US IP (New York), I have no problems accessing MSFN. But my real German IP ranges are blocked (502 Bad Gateway). Just tested. Therefore, this cannot be a bot or a user problem but rather a misconfiguration of the MSFN server. Well, I’m afraid the connection problem seems to be a MSFN server-side issue.

I can well imagine that, following this recent deletion of bot accounts, constant monitoring of Cauldron Filthcare is no longer necessary at all. The forum software is now up to date and surely gets further security updates. It is far more important to prevent the automatic creation of bot accounts here on MSFN by implementing a specific verification process to ensure that the user is actually a human being, of course not by Cauldron Filthcare, but, for example, by a question or something else that only humans understand and are able to answer. One thing is clear. Such a security filter has been completely neglected in the past.

That’s always good to hear. 😃 And Comodo Antivirus also works exactly as it should. You do need to configure it properly, though, as it can be quite restrictive.

Very good decision and action. 👍 As far as I can see, it must have been round about two and a half thousand in total for now: ≈ 68300 - 65800 = 2500 🕵

I think it is very important to address the many, many accounts unused or never visited that have been set up automatically over the last few years and continue to be set up today, which are being or can be used for bot attacks. It must be many hundreds or even more. https://msfn.org/board/search/?&type=core_members&joinedDate=any&group[3]=1&group[25]=1&sortby=joined&sortdirection=desc I have reported on this on several occasions.

The SSUAO posted above works fine with Mypal 78.0.3 when trying to solve manual Cauldron Filthcare challenges only but not the automatic ones. New Moon 28 and Serpent 52/55 actuallly don't need that SSUAO since they are whitelisted to solve these challenges. Luckily, I'm using Firefox Nightly 114.0.3 on Windows XP as of recently which has no problems with MSFN or GitHub, and Cauldron Filthcare. No special SSUAO necessary. All works natively. However, none of this changes the fact that MSFN goes offline at regular intervals, displaying the ‘Bad gateway 502’ error message.

Try this SSUAO in Mypal 78.0.3 for solving manual CF challenges only: You can select the version of the SSUAO up to 78 at the moment. That might change in the next releases. We will see. The current discussion can be read here: Mypal 78.0.3 - Cloudflare challenge loops and their solution And here is my userscript MSFN Navigation Menu Popover Fix.user.js for polyfilling the broken menu positions: // ==UserScript== // @name MSFN Navigation Menu Popover Fix // @namespace https://msfn.org/board/profile/311648-astroskipper/ // @version 1.0 // @description Fixes the navigation dropdown positioning on older browsers without native :popover-open support // @author AstroSkipper // @match https://msfn.org/* // @icon https://msfn.org/board/favicon.ico // @grant GM_addStyle // @run-at document-start // ==/UserScript== (function() { 'use strict'; // 1. Inject a CSS fallback (simulates the @supports duplication) // If the browser does not recognise :popover-open, this CSS rule takes effect. // We use the [popover] attribute if the forum sets it, or we control it via the script. const fallbackCSS = ` i-navigation-menu:defined .ipsNavBar > li > .ipsNav__dropdown { position: fixed !important; left: 0 !important; top: var(--_anchor-v-fixed, var(--_anchor-v)) !important; } `; // Check whether the browser does NOT support :popover-open if (!CSS.supports('selector(:popover-open)')) { if (typeof GM_addStyle !== 'undefined') { GM_addStyle(fallbackCSS); } else { const style = document.createElement('style'); style.textContent = fallbackCSS; document.head.appendChild(style); } } else { // If the browser supports the modern popover, we’ll stop here return; } // 2. DOM monitoring for the "Open" event (setting --_anchor-v-fixed) // As the page resets the variable when it closes, we need to set it when it opens. document.addEventListener('DOMContentLoaded', () => { // We monitor clicks on the menu triggers document.body.addEventListener('click', (event) => { const trigger = event.target.closest('[data-ipsmenu]'); if (!trigger) return; // Find the relevant drop-down menu const dropdownId = trigger.getAttribute('id') + '_menu'; const dropdown = document.getElementById(dropdownId) || event.target.closest('li')?.querySelector('.ipsNav__dropdown'); if (dropdown) { // Determine the current scroll position and the vertical position of the trigger const rect = trigger.getBoundingClientRect(); const anchorV = rect.bottom + window.scrollY; // Set the CSS variable required by the fix on the drop-down menu so that `position: fixed` remains scroll-correct dropdown.style.setProperty('--_anchor-v-fixed', `${rect.bottom}px`); dropdown.style.setProperty('--_anchor-v', `${anchorV}px`); } }); }); })();

And today I’ve made further improvements to ensure the browser runs more smoothly, particularly when loading image galleries. 😜

Nightly 114.0.3 under Windows XP Professional SP3 with all POSReady updates on a single-core P4 with 1.5 GB SD-RAM and a GeForce 6200. 3 tabs and the Browser Console opened, and I have done a lot of optimisations: Bye, bye RAM consumption, CPU overhead, crypto loops, failing tasks, data reporting, unnecessary warnings and telemetry.

Which gang? 🤔 Where are the criminals? 👮‍♂️

Done. Feature request for reducing CPU usage under Windows XP

My browser console is now completely quiet, only one error message NS_ERROR_FAILURE which confirms the successfully fitted muzzle. 🤬 And opening several tabs on my P4 is no problem anymore. But of course, you mustn’t overdo it. 😜

I set the environment variable MOZ_REMOTE_SETTINGS_DEVTOOLS=1 and cut off both, the Background Task (Task Scheduler V2) and the Remote Settings Crypto Feature by creating and installing a UC.JS script in the Nightly 114.0.3 and creating some prefs for stopping these features. Then I rebased all important DLL files inside the programme folder which led to a reduction of more than 50% in RAM usage. Furthermore I changed some ipc.processCount prefs and others to my needs. Finally, I installed my UC.JS script for periodically triggering the Minimize Memory feature. Works like a charm. 👍

Of course! I didn't expect that the developer is also a member of MSFN.

May I kindly ask who the developer is? 🤔

@ED_Sln Don't you think it would be time for a separate, special build for Windows XP only? 🤔 The Background Task (Task Scheduler V2) and the Remote Settings Crypto Loops are poison for Windows XP especially on old, weak hardware and totally unnecessary since they do nothing but consuming resources.

@ED_Sln If you’re interested in what I did to get your Nightly 114.0.3 running on an ancient, single-core P4 with just 1.5 GB of SD-RAM, do let me know. Without some very specific optimisations, the Nightly won’t really run properly due to the enormous RAM usage.

Suggested feature request for the next build: Hi! While deep-testing the Nightly 114.0.3 fork on a Pentium 4 with 1.5 GB RAM under Windows XP, I noticed heavy background CPU/RAM overhead and continuous error-looping in the Browser Console. To optimize performance and stability for low-spec WinXP systems, it would be awesome if you could completely eliminate or silence these two modern Firefox background frameworks in your next source build: Firefox Background Update (Task Scheduler V2): The browser constantly throws NS_ERROR_FAILURE (nsIWinTaskSchedulerService.deleteTask) upon startup. Firefox 114+ expects modern COM APIs (Task Scheduler V2) from Windows Vista/7, which do not exist in Windows XP. Solution: Disable this feature at compile time by adding ac_add_options --disable-backgroundtasks to your mozconfig. Remote Settings Crypto Loops (InvalidSignatureError): The RemoteSettingsClient continuously tries to sync blocklists and CFR message groups in the background. Because modern 2026 Mozilla certificate chains and timestamps fail to verify properly on a legacy OS environment, the engine enters an endless loop of processing corrupt data and retrying, eating valuable CPU cycles. Solution: Set pref("services.settings.server", "http://127.0.0.1"); and pref("messaging-system.cfr.enabled", false); by default inside modules/libpref/init/all.js. Also, patching out the strict release-build verification block in services/settings/Utils.sys.mjs would allow these preference overrides to work natively without requiring users to set global environment variables (MOZ_REMOTE_SETTINGS_DEVTOOLS=1). Baking these tweaks directly into the source code would make this amazing fork absolutely clean, lightweight, and performant out-of-the-box for the legacy community. I did this as a temporary fix by setting the environment variable MOZ_REMOTE_SETTINGS_DEVTOOLS=1and running an UC.JS script in your Nightly. Thanks for your incredible work on this project! Kind regards, AstroSkipper