Thanks for restoring Flash! (and some Linux banter)

[Mæstro]

I cannot help but wonder whether the other browsers’ Flash support failed because of regressions like this late in Flash’s lifespan which their developers never bothered to mend. It means a lot to know that I can rely on this browser for accessing some of the joys fo my childhood for years to come in their original form, and I want the developers to know the effort behind maintaining this is appreciated.

[moonbat]

No, they just decided that the entire NPAPI plugin architecture was insecure and tossed out the baby with the bathwater. It would've been better to let it stay for serving DRM content or other proprietary stuff than adding those to the HTML spec.

[suzyne]

I can't comment on NPAPI plugin architecture, but wasn't a bigger problem that Flash was closed and proprietary technology and so the tech heads were saying that this is bad for the internet, which is supposed to be "open"?

In that context, wasn't it less a case of the mainstream browser developers not being "bothered" to keep Flash working, but more like a decision to try and improve the internet for the longer term? (While still acknowledging that yes, it was very annoying for fans of NeoPets etc...)

[Moonchild]

wasn't a bigger problem that Flash was closed and proprietary technology and so the tech heads were saying that this is bad for the internet, which is supposed to be "open"?

No, the only angle they pushed (and pushed hard) was that "any and all plugins are insecure and should be shunned". I never even heard the angle you're mentioning here (probably because just thinking 5 minutes about that I could probably come up with a whole list of arguments to shoot that down).
But the truth is, they aren't insecure. In fact, the whole "restricted process" approach they boasted about with electrolysis is exactly what is being used by plugins, especially so by Adobe Flash who built in a version of process isolation of their own.

Key security features of plugins that you will not find in in-browser "replacements":

• Plugins can be easily restricted to certain websites (i.e. "click-to-play") meaning the user has full control over permissions to use each plugin in each location.
• Plugins run in an "out-of-process" container in most cases (including any UXP browser), i.e. it spawns a separate process just for the plugin with limited access.
• Plugins operate in a walled-off content container and do not have direct access to the content they are embedded in (not to be confused with process isolation in previous point).
• Plugins will only load when embedded code requests it and permissions allow, greatly reducing or removing possibilities of exploits on them, since common exploits use vulnerable code in memory -- if the plugin is not in memory/loaded, there's nothing to exploit.
• Similarly, plugins are removed from browser memory again when no longer actively used in our implementation. Again: nothing in memory to exploit, unlike "always-on" gadgeteering Web APIs.
• Plugins off-load specific functionality and requirements to third parties, instead of making it the responsibility of browser developers (who may not be as well-versed in the intricacies of the functionality provided by the plugin). Segmentation this way improves security.
• Plugins can be blocked/disabled immediately without having to worry about building in complexity into a browser for selective disabling or releasing a changed browser version.

There's probably more, but that's off the top of my head some real good security points pro-NPAPI. And you can list more non-sec things to further prefer NPAPI, like performance, privacy, potential licensing issues with things that are "black box" like DRM...

[suzyne]

I must try to find where I got my ideas from because I dont think that I made them up myself. Maybe it was only one article that stuck in my mind?

But I am pretty sure that long before the security issues were being discussed there were real concerns and discussions that websites using Flash caused issues with search engine indexing, stopped page accessibility like screen readers, wasn't controlled by a standards body, and tech people were worried that the web was going to become isolated blobs of code that only ran on a proprietary technology that wasn't HTML. 

wasn't a bigger problem that Flash was closed and proprietary technology and so the tech heads were saying that this is bad for the internet, which is supposed to be "open"?

No, the only angle they pushed (and pushed hard) was that "any and all plugins are insecure and should be shunned".

Did I really just imagine those debates happening in the past?

[Moonchild]

Maybe it was only one article that stuck in my mind?

It's quite possible, and I could see someone trying to make that argument to try and somehow justify the movement to phase out NPAPI when it was already in swing, but I'm pretty sure it must have been very short-lived; I've not seen it, that I recall, at least.

[suzyne]

It's quite possible, and I could see someone trying to make that argument to try and somehow justify the movement to phase out NPAPI when it was already in swing, but I'm pretty sure it must have been very short-lived; I've not seen it, that I recall, at least.

From what I just read, wasn't the movement to phase out in full swing from 2015 onwards? But here's a link that talks around the issues that I mentioned as far back as 2002 (and the second is questions still been asked in 2010).

http://mdcc.cx/rants/swf-considered-harmful.html
https://stackoverflow.com/questions/2824343/why-shouldnt-i-use-flash

I imagine if I spent more time I could find a lot more that don't relate to the later Google/Mozilla security excuse push.

[vannilla]

Flash itself was a security nightmare, but that doesn't mean other plugins were.
The "openness" of the web falls flat the moment anyone points out DRM is baked into the Web standard and that's anything but open.
Vendors annihilated the whole plugin ecosystem entirely based on one popular product.
This argument is actually still used whenever a piece of software allows for third-party plugins: "this one specific item is bad, therefore everything building on this technology is bad!" and then you have people parroting "plugins are insecure by design because it's native code!" without understanding how the host platform handles them.
If the developers cave in, at best they move popular plugins inside the core, which means if you don't care about a certain feature you cannot disable it, in the worst case they end up integrating a limited scripting language which will make certain plugins impossible to port over.

tech people were worried that the web was going to become isolated blobs of code that only ran on a proprietary technology that wasn't HTML.

This is ironic because nowadays the Web is made of isolated blobs of code that aren't HTML. The only difference is that neither Javascript nor WebAssembly are proprietary, but as of 2025 there is no difference between minified Javascript, WebAssembly and native binaries.

[back2themoon]

Wasn't Java even worse than Flash? I remember a lot of bad publicity from that. They kept releasing security fixes/updates.

[Moonchild]

The bigger risk with Java isn't necessarily that the plugin itself is insecure, but rather that it is a general programming language interpreter that has access to your PC, so it comes with the risks of running remote code "as native" and you have to make sure you trust what java program you run. And like most general language interpreters its complexity causes a lot of potential exploits as it's a prime target for hackers.

[suzyne]

The only difference is that neither Javascript nor WebAssembly are proprietary

But isn't that actually a huge difference? I think to say only is minimising and dismissing something that philosophically and practically has major consequences. It is also good to remember that JavaScript is part of the HTML5 standard.

I must admit, I am a little surprised (maybe shocked?) that in the Pale Moon forums there is much love for a proprietary technology that was controlled and supplied by a single company. It seems to go against some much of the sentiment that I have seen here over time.

[Moonchild]

I must admit, I am a little surprised (maybe shocked?) that in the Pale Moon forums there is much love for a proprietary technology that was controlled and supplied by a single company. It seems to go against some much of the sentiment that I have seen here over time.

There's something to be said for both though. I've never dismissed something just because it was proprietary, myself, and I personally think that that notion is misguided. If you have a tool that works and works well, you should use it. I'm not on board with "everything must be open/non-proprietary no matter the cost" because often the cost is that you are not using the best tool for the job, the tools you have access to are inferior, and on top of that being "open" doesn't even guarantee something being safe: not everything FOSS is audited, or even checked nearly as diligently as it reasonably should. Compromised supply chain issues exist and are on the rise, too.
A proprietary technology developed by a single company makes it a lot less likely there is a bad actor messing with it. After all, the company's reputation and livelihood is on the line in that case so it's a self-securing environment that FOSS lacks.

So no, my sentiment is definitely not one of "free or bust" and I do love my proprietary tools. Pale Moon for Windows wouldn't be nearly as good if I were to use a fully FOSS compiler toolchain, for example. And I'd promote Adobe Flash player from a trustworthy location (and verifiable kosher by e.g. codesigning) over an incomplete, janky and buggy attempt at emulation of it any day.
If the results are equal, then I'd promote the Open solution (if properly maintained!). Once more it's something you need to balance for yourself; what has priority for you? Functionality or philosophy?

[suzyne]

what has priority for you? Functionality or philosophy?

When it comes to the transmission of information via the internet, I do think philosophy should be considered more seriously over function.

For software used in the privacy of your own home, I agree that proprietary tools are wonderful. I use the Affinity Suite, which I gladly paid for, and I am not an open-source fanatic in any way. When I save my zine in the afpub format, I am not hurting anybody but myself if at a future time, the product is discontinued, or I can't get it to run on my next computer.

But isn't a real problem with propriety technology that when the support (or the company) vanishes, all that content becomes more difficult and maybe impossible to access fully. I am not a FOSS zealot, but really think that archives and preservation of creativity and knowledge content and information is super important and very valuable.

So getting back to Flash, the current situation great content produced not much more than a decade ago and going back to the early 2000s is for many internet users effectively lost. And for the more sophisticated users it is at least problematic and awkward to access, it's a sad and regrettable cultural loss which would have been avoided if people thought beyond, this is okay because the proprietary software is secure and has a good reputation.

In my opinion, when thinking about the internet, talking about tools that work for you or me on the desktop is entirely beside the point.

[athenian200]

As far as I know, Pale Moon simply never got rid of NPAPI, and that is one of the things I still recommend it to people for even though I'm less active lately in development.

But yeah, I use a lot of Flash-based content, as well as other plugins, and appreciate Pale Moon's continued existence for this niche, in addition to the other features it provides.

I am thinking that other browsers may have just removed NPAPI because maintaining compatibility with an array of older plugins does involve a degree of legacy cruft as the underlying operating system changes, and can carry a maintenance burden which they were happy to ditch when given the opportunity. Which is unfortunate because there were a lot of good things lost when they did this, much like with XUL extensions.

As for the proprietary vs. open-source issue, I think at the time of Flash's creation it was a moot point... there wasn't an open-source tool or protocol that could do what it did, and it emerged as an early defacto standard because it was freely available. By the time a proper standard was created, it was a bit behind Flash, and there was a lot of existing Flash content it couldn't play. Eventually that proper standard was aggressively pushed, and backwards compatibility with existing content was pushed to the side.

So, I would say one can believe that it's better to create new content using open standards and open-source standards, but also still not want older stuff created in a proprietary way to be lost just because it was created with proprietary tools and been neglected for a while. I feel like this is one thing Linux has never cared enough about, and one of the things keeping it from replacing Windows. The open-source developers expect everyone to be able to recompile everything, and show little to no sympathy for people using older binaries that they don't have source code for. This negatively impacts things like native Linux games, and creates a perverse incentive for things like targeting WINE or Proton because it has a more stable ABI than most Linux distros.

In my opinion, in terms of open-source being a good thing, it would have been better if Adobe open-sourced Flash so the community could do what they wanted with it or maintain it themselves. Instead, they killed it unceremoniously and told everyone to use HTML5 or something, not really caring how the migration was done or whether the new tools were suitable. So now it's one of many applications that are neither making money for their creators nor easily available to be used by those who still need them. And in my opinion, that's the real tragedy open-source was meant to prevent, and has prevented as some companies approached bankruptcy.

[moonbat]

Off-topic:

The bigger risk with Java isn't necessarily that the plugin itself is insecure, but rather that it is a general programming language interpreter that has access to your PC

Used to be a Java developer from when it was new. In the beginning, they introduced 'applets' - which were analogous to Flash, offering a sandboxed subset of the whole Java API with limited network access (restricted to the originating host), and some animation capability to run as embedded objects on a webpage. You could also build full desktop applications using Java which would be shipped with a Java runtime and installed like any other application. MIcrosoft saw the writing on the wall about OSes becoming obsolete in the face of cross platform programs and tried to sabotage Java by offering a virtual machine that had Windows specific APIs in addition. Sun filed a lawsuit successfully against them.

Java in the browser flopped because every time you opened a page with an applet the browser would freeze waiting for the JRE to initialize and then display it; the system requirements were bloated for the average desktop of the late 90s and applets ran very slowly and struggled to even repaint their UIs on the non hardware accelerated displays of the time. Once Flash appeared applets became obsolete, and Java's cross platform 'write once, run anywhere' only really shone on the server side.

[vannilla]

But isn't that actually a huge difference? I think to say only is minimising and dismissing something that philosophically and practically has major consequences. It is also good to remember that JavaScript is part of the HTML5 standard.

The Javascript and WebAssembly standards might be freely available (i.e. "open") but implementing them is not something anyone can do. Between semantic details to be handled ad-hoc and whole interfaces for highly specific use cases which are not trivial to implement, the only feasible way to implement Javascript is to either have a full team handling the task like a job (or make it their job) or to inherit an existing codebase and extend it with new features. And all that without taking performance into consideration. Comparatively, writing a compliant C compiler is a lot easier.
When only big businesses with infinite programmer power can implement a standard, it doesn't matter if it's open because it's no different than a fully proprietary item.

I must admit, I am a little surprised (maybe shocked?) that in the Pale Moon forums there is much love for a proprietary technology that was controlled and supplied by a single company. It seems to go against some much of the sentiment that I have seen here over time.

I'm defending plugins as a concept and NPAPI as an implementation, and that requires me to "defend" Flash too. I don't really care about it otherwise.

[Moonchild]

Just in case it wasn't exactly clear (from the topic title): We never removed support for Flash or other plugins. The temporary inability to use plugins was limited to v33.8.1.1 in which a crash fix had the side effect that plugin objects no longer loaded, which was a straightforward bug to fix in the current latest release. The stoppage wasn't intended, and we have no intention of removing NPAPI support.

[frostknight]

There's something to be said for both though. I've never dismissed something just because it was proprietary, myself, and I personally think that that notion is misguided. If you have a tool that works and works well, you should use it. I'm not on board with "everything must be open/non-proprietary no matter the cost" because often the cost is that you are not using the best tool for the job, the tools you have access to are inferior, and on top of that being "open" doesn't even guarantee something being safe: not everything FOSS is audited, or even checked nearly as diligently as it reasonably should. Compromised supply chain issues exist and are on the rise, too.

Off-topic:
good examples of open source software that isn't auditted or is bloated:

systemd
rust & cargo
openjdk
dbus
pulseaudio
network-manager
pipewire
avahi
openssl
implementations of wayland (not the protocol itself)

Probably others too

So yes, something being open source or as some prefer libre software, doesn't make it foolproof or even necessarily good, it just means you can see most of it for what it is and audit it easier.

Some things are almost always better libre no matter the cost
It depends if security/privacy is involved.

If not, then, I think it can go both ways depending on the user's preference.

[Moonchild]

Off-topic:

libre software, {...} means you can see most of it for what it is and audit it easier.

Not in practice. The big and increasing issue is that this doesn't work: sure, you can audit a piece of FOSS. But if you adopt it in your organisation, then you need to audit every subsequent commit to it as well. And every subsequent commit of its FOSS dependencies. That is just not practical so in the end, auditing FOSS is rare and often incomplete. Since there are no responsible entities for open development, there is also no pressure to keep doing this.
And FOSS and their dependencies go unmaintained all the time as well, because there is little to no development pressure without a company behind it.
So is FOSS safer than proprietary? I'd say no, despite it being possible to audit easier (because it's not practical to actually audit).

Some things are almost always better libre no matter the cost
It depends if security/privacy is involved.

Security/privacy actually leads me to the opposite conclusion and that in many cases the cost (not in terms of expense, but in terms of work and risk) of adopting libre is just way too high because there's little to no accountability; something you would likely have with proprietary/business-driven software.

[frostknight]

Security/privacy actually leads me to the opposite conclusion and that in many cases the cost (not in terms of expense, but in terms of work and risk) of adopting libre is just way too high because there's little to no accountability; something you would likely have with proprietary/business-driven software.

Off-topic:
Problem is, proprietary code gets fixed slower in my experience. The only exception would be Google probably.

Microsoft takes their time in my experience unless its really bad.

There are enterprise support distros out there. Whether you like them or not of course.

Ubuntu is one of them, although I think meh about that one. But still better than proprietary OS in my opinion.

What price do you speak of btw for adopting libre being too high?

Do you mean learning, using, or fixing in particular? I assume learning and using if nothing else.

If you know those three things, you are usually less likely to have stability problems if nothing else.

Btw, do you know if windows has improved with layered permissions for their windows 10 or newer?

I wouldn't know this part because I quit around 8.1.



I am only curious, because I wonder to myself how much people are risking their data using it.