1. 15
  1.  

  2. 11

    I work in information security, Pale Moon kind of worries me. When I worked on a community image board serving some million of hits per month there were a few high-profile users that, for one reason or another, opted to use Pale Moon instead of a more mainstream browser. The most commonly-cited reason effectively boiled down to not liking the user interface change, which I can respect. I have a hard time breaking away from my favourite tools as well.

    However, what was once effectively a fork of Firefox with XUL re-added and the old user-interface restored has turned into a one-person standalone project. Now, this one person - according to their bio - is capable of everything and anything at 10x, but I have my reservations on how far that capability extends. There are only four, perhaps five people that actually contribute to the project on the regular, and I would venture that none of them do it full-time, because the software doesn’t appear to pull in enough to possibly sustain a even one full-time developer salary. Given the fact that they claim this has been an eight+ year project, I would venture that some other form of income has to be required at some point. Even if it’s a part-time gig, that’s a part-time commitment to something else that takes brainpower.

    Out of curiosity, I went back and obtained a sanitised user agent statistic set from the image board I worked on. The staff were gracious enough to allow me to get a percentage figure for Pale Moon users:

    Out of 3656091 hits to the site over a course of roughly 24 hours:

    • 1642179 were from Chrome-based user agents;
    • 387233 were from Safari-based user agents (including iOS devices);
    • 464940 were from Firefox without the Pale Moon user agents;
    • 1156931 were from non-mainstream browsers or bots who were not Pale moon; and
    • 4808 were from a browser using Pale Moon’s user agents.

    This results in 0.13% of the total hits to the site’s front-end being from a Pale Moon browser.

    If we take a look a total unique IP addresses:

    • 80,295 total unique IP addresses in 24 hours; and
    • 99 of those IP addresses were using Pale Moon

    This results in 0.12% of the total unique visitors to the site’s front-end being from a Pale Moon browser.

    This is in a community that has an awareness of it, as - like I said - several high profile users in the community use it.

    Additionally, the individual behind Pale Moon has forked Gecko and created Goanna. In a lot of cases for a lot of types of software, this would be fine. However, there are many, many people who work on Gecko; it’s a highly complex system with a lot of room for error. As the rendering engine, it’s also the foremost part of the browser being exposed to the wilds. Despite the team size issues still occur, and some of them are genuinely concerning issues.

    Furthermore, I can (but I won’t) write a lot of words about XUL. I understand why users want it returned, but I also strongly identify with the justification behind removing it in the first place. While the replacement wasn’t as flexible, it absolutely is considerably more secure on all fronts and, now that the vast majority of extensions have been converted to the WebExtensions API, I don’t think I’ve run into an issue for a long time. Addons that genuinely required the XUL APIs and cannot operate purely on WebExtensions APIs - in my opinion - should not have merely been a Firefox addon.

    As an aside, the justifications behind the non-addition of multiprocessing are, in my opinion, simply a collection of empty talking points. They seem to attempt to justify the entire reason Pale Moon exists: To do things the owner’s way. That in a vaccuum is fine, but other (potentially uninformed) people being encouraged to use an opinionated browser like this without being aware of the consequences, is not.

    I don’t worry about the project though, I worry about its (admittedly small) user base. There is only so much mental bandwidth an individual can expend before they become stretched too thin. Being a systems administrator, rendering engine developer, browser maintainer, plus whatever their full-time job is, cannot possibly be performed with 100% of acuity allocated to each component of their life.

    This isn’t the first time, and it won’t be the last time, that a fork of a mainstream browser is dressed down because the team (or individual) is stretched too thinly. I treat every fork of a mainstream browser with the same scepticism be it Brave (Chrome), Vivaldi (Chrome), Waterfox (Firefox) or Pale Moon (Firefox). At best, on a security front, they are the mainstream browser + n lag time for security patches. At worst, they forego them entirely because they alter the vision of the creator. All of them have a vastly smaller team than the browser from which they forked, and generally they are only forking because of one or two issues with the parent product that they see as insurmountable, so more personpower to their cause is unlikely.

    1. 1

      Thanks for confirming what I’ve been thinking since some time. I too was once on the edge of using pale moon, back in the days before the XUL switch & rust? (so probably 2015). Because there was this rumour that there’s a better, threaded browser experience. As a user I couldn’t really see how many people really worked on this. All you saw was a huge userbase compared to many projects and some nice claims.

      I’ve never made the switch due to various reasons[1], but I left with exactly this impression: If mozilla and google obviously can’t make their browser 100% secure, how will this fork:

      a) keep up with the security patches while b) maintaining their own features (introducing their own security holes) and c) keeping on-par with the features the original projects keep offering.

      [1] One of them was completely switching over to linux.

      1. 6

        Wow, this Github thread was painful to read. Thanks for the reference!

        1. 3

          We had the same issue with the palemoon author for publishing PKGBUILDs on the Arch User Repository (since it patched the build process in the PKGBUILD). I personally can’t take such a project serious and wouldn’t recommend anyone to use it.

          1. 1

            As “upstream” I’d be happy if people came around and showed so much interest in my project that they’d start to package it on their own, even more when they’re more proficient on that platform..

            1. 2

              On the other hand you’ll get bug reports that you can’t reproduce because people will complain with upstream, not with the packager. And then you’ll need to go hunting for whoever messed up the binary with local patches.

              So I can understand projects (which includes Mozilla) expecting such distributors to use a branding that is clearly different from theirs, but the attitude they demonstrated on that issue was completely out of line.

          2. 2

            ok I was about to reply that we shouldn’t further stamp on somebodies project (see V), but this is painful..

            I will not be as educational next time.

            1. 2

              I “”“love””” what they’ve done to about:mozilla (link to git). Not condescending at all!