Yeah, emulation is the right way of preserving Flash, but I would argue that Ruffle (and other attempts at OSS Flash, including Lightspark, which my younger self wrote) are implementations of the Flash runtime, not truly emulators.
At Leaning Technologies we are working on a x86 virtual machine written in WebAssembly (CheerpX) that allows the binary Flash plugin to safely run in modern browsers.
Adobe will stop distributing the Flash plugin and has removed its archive of old Flash releases. Will Leaning Technologies be redistributing an old Flash plugin or will CheerpX customers need to find and host an old Flash plugin on their own sites?
Also, Adobe's recent Flash releases include an EOL "time bomb" that will refuse to play Flash content after 2021-01-12. Will CheerpX bypass the time bomb in emulation?
I'm glad Adobe is at least willing to facilitate this sort of licensing for the Player runtime, I assumed they would want to bury this platform entirely.
Why did you choose this way? A free software reimplementation of Flash seems to me like a much better idea than emulating all the interfaces required to run the old and unsupported binary blobs from Adobe - possibly on foreign CPU architectures. (Unless you compile to WASM, which it seems that you do - but the emulation overhead is still there.)
The interface is much cleaner than you can expect, it's the Pepper API that Google engineered for NaCl. That idea was not successful in the end, but the clear interface stayed. The old NPAPI would have been more messy, but still doable.
The crucial problem is that the Flash runtime is incredibly extensive, and vaguely documented as well. I started the Lightspark project many years ago, so I know this from personal experience.
OSS Flash has value in itself, but to accurately preserve any SWF content, the original binary is the only feasible solution in the medium term.
And of course, our VM (CheerpX) has many other use cases, so it has value beside this first Flash oriented product.
Getting a reimplementation feature-complete and bug-compatible enough to actually reliably and accurately run old content is hard work that realistically will never be complete. Most current reimplementation attempts cannot play any but the most simple flash games.
Sticking the whole thing into a VM and just running the original code achieves both accuracy and safety, at the cost of resources. Given that Flash died long ago, i.e. hardware has advanced since then, resources are not a major issue, and are going to be even less of an issue going forward.
CheerpX looks very cool, and I think it could be useful beyond just Flash. It could help keep alive niche commercial software that has been left behind by platform changes. For example, there's an old speech synthesizer, ETI-Eloquence, that some blind people love. It was developed in the late 90s to early 2000s, acquired (a few times, ultimately by Nuance), and now seems to be basically dead. There was an Android version, but that had to be discontinued due to the recent requirement that native code on Android must be 64-bit. CheerpX, combined with a non-browser-based wasm runtime, could revive it!
At Leaning Technologies we are working on a x86 virtual machine written in WebAssembly (CheerpX) that allows the binary Flash plugin to safely run in modern browsers.
To read more about our approach:
https://medium.com/leaningtech/preserving-flash-content-with...
https://medium.com/leaningtech/running-flash-in-webassembly-...
https://medium.com/leaningtech/announcing-cheerpx-for-flash-...
https://medium.com/leaningtech/cheerpx-for-flash-now-general...
For questions, you'll find me on Twitter: https://twitter.com/alexpignotti