Preserving Flash: why emulation is better than migration
blog.dshr.org
blog.dshr.org
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
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.
Won't you also need permission to create a derived work from the blob?
Though, I'll agree that technically you'll probably only get widespread compatibility by using the old the binary blobs.
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.
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?
https://medium.com/leaningtech/cheerpx-for-flash-now-general...
I know that's not something you can solve, just unfortunate :(