8 ms·

Ruffle – An Adobe Flash Player Written in Rust Compiled to WebAssembly

206 points by conroy 7y ago

deleted 7y ago
[deleted]
mgamache 7y ago
I really hope this works, but I fear it will die a shumway death. One of the issues is there are two complete run-times inside of Flash. AVM1 (for AS1/2) and AVM2 (for AS3). AS1/2 is much easier to program and probably emulate. AS3 was much more advanced and was actually a pretty good language. Adobe should release the source, but probably doesn't due to all the security holes that probably are waiting to be found. Of course, that is speculation. [https://github.com/mozilla/shumway https://github.com/mozilla/shumway] [https://en.wikipedia.org/wiki/ActionScript https://en.wikipedia.org/wiki/ActionScript]
- xeromal 7y ago
  Google Swiffy too https://en.wikipedia.org/wiki/Google_Swiffy https://en.wikipedia.org/wiki/Google_Swiffy
- fenomas 7y ago
  > Adobe should release the source, but probably doesn't due to all the security holes that probably are waiting to be found. Of course, that is speculation. The AS3 spec, compiler and runtime/VM are all open source, have been since at least 2008 IIRC. Details are in the wikipedia page you linked, third paragraph. Aside: discussions of Flash or its legacy have an unfortunate tendency to get derailed by FUD, so it would perhaps be useful to avoid speculation like this where possible.
  - mgamache 7y ago
    The AS3 VM is helpful, but only part of the player. The fact remains there is no player source to use as a guide for porting to other languages. It’s similar to the .net scenario. MS releases .net core open source, but didn’t release the GUI parts (until recently).
    - fenomas 7y ago
      I don't think anyone at Adobe is against open-sourcing the whole player; the problem would be relicensing it. It's a massive, hugely complex project, with lots of chunks that were licensed or written by other parties. And the codebase was probably 10-12 years old before anyone even considered the idea of opening anything... I definitely agree it'd be hugely useful, and wish it would happen, but I kind of doubt we'll ever see it.
      - mgamache 7y ago
        Right. I focused on the security, but it's a legacy code base with legal entanglements. Also created in another era.
    - giancarlostoro 7y ago
      They didnt release the GUI cause .NET Core is a rewrite. .NET Framework is only compatible through a common library between .NET Standard. Outside of that as far as I am aware they are similar but different runtimes.
- icemelt8 7y ago
  Even the editor FlashDevelop was very cool.
- robin_reala 7y ago
  The AS3 VM was opensourced in 2006 (as Tamarin) and donated to Mozilla who planned to use it as a back-end inside Gecko: https://en.wikipedia.org/wiki/Tamarin_(software) https://en.wikipedia.org/wiki/Tamarin_(software)
- whatever_dude 7y ago
  Flash Player contains a host of third party, commercially licensed software inside of it. Its source will never be released and it has nothing to do with security.
- brighteyes 7y ago
  > I really hope this works, but I fear it will die a shumway death. Yes, it may find a niche subset of Flash content it can do well, but there have been many attempts at Flash replacements, and all of them have failed, including serious ones with corporate backing like Shumway. Another cool one is Lightspark [1] The only real chance at 100% preservation of Flash content is for Adobe to open source all of it - the VMs, the runtime including the graphics, etc. - and to compile that. [1] https://en.wikipedia.org/wiki/Lightspark https://en.wikipedia.org/wiki/Lightspark
tgtweak 7y ago
I'm sort of at a loss to this.. flash was disliked because of three things, for the most part: • Capability of ActionScript (which can harbor malware) along with potential vulnerabilities in the interpreter itself. • Memory and CPU usage • Proprietary Does this rust variant even address all of these? Are we hoping to shim flash support into wasm-supported browsers? What good would this bring, specifically in regards to native flash's shortcomings? Not trashing the project, cause it's actually really cool, just curious why.
- simcop2387 7y ago
  Putting it into WASM at least will deal with a lot of the potential issues that AS could have, simply because WASM doesn't have access to the outside world to attack anything. As for RAM and CPU usage, there's not much that can likely be done. Better garbage collectors and other things like that might help but Flash itself was the cause of a lot of those problems. If this was a full implementation it'd be something open source that could run flash files/movies, so it'd be a bit less proprietary. There still wouldn't be open source editors that could handle doing it all so it wouldn't be complete or even close as an ecosystem. That said, all this could end up creating a good alternative for when all the browsers and adobe drop flash support in the next year (Firefox ESR is the only one I know of that's committed to supporting it until the end of 2020). A sane and safe migration path would be really useful for somewhere like newgrounds or archive.org to preserve internet history.
- sjwright 7y ago
  • Largely assumed mouse/keyboard interaction and had no plausible mechanism for responsive design • Proven track record of terrible security bugs • Was most frequently used for ads
  - pjmlp 7y ago
    * It remains to be proven how WebAssembly is so much better than everything that came before it (hackers are yet to start having fun with exploits) * Flash games market was huge
todd3834 7y ago
This is pretty great! I remember building stuff with Flash back when it was still owned by Macromedia. There is a solid level of nostalgia for me there. I know one of the major concerns became security with enabling the Flash player. I assume with WebAssembly as the compile target we don’t really have to worry about it as much? Does anyone know if we are going to start seeing things like memory leaks and buffer overflows with web assembly or is that not a thing? I know Rust does a lot to resolve memory issues but I’m wondering about the other languages that compile to web assembly. Anyways, nice work!
- thristian 7y ago
  One of the big problems with things like Flash and Java on the web was that they were separate codebases from the browser, but (often) ran inside the browser's memory space, which was kind of a worst-of-both-worlds situation: multiple VMs each with their own individual vulnerabilities, but compromising any one would give you access to all of them. WebAssembly is different because it's built around the high-performance JavaScript VMs that have been developed over the past decade or so. When a browser-maker fixes a security hole in their VM, it's fixed for JavaScript and WebAssembly at the same time, because they're built on the same foundation. So no, you don't have to worry about security as much with WebAssembly - not because of any magical security properties WebAssembly has, but because even though the WebAssembly API is new, the security environment has seen decades of hardening.
- gridlockd 7y ago
  WASM can't magically make memory-unsafe languages memory-safe. You can still have memory leaks and buffer overflows, but (assuming a correct WASM implementation) a buffer overflow can not result in memory access outside the WASM instance's memory space - unless you provide it with the facilities to do so.
pjmlp 7y ago
It is finally happening! Nice to know about it.
tomjuggler 7y ago
This is petty cool, is there anything similar for Java applets, remember those?
- yuri91 7y ago
  There is Cheerpj[0]. You can compile any JAR into js, and there is even a Chrome extension to conveniently run Applets found in the wild[1]. [0] https://www.leaningtech.com/cheerpj/ https://www.leaningtech.com/cheerpj/ [1] https://chrome.google.com/webstore/detail/cheerpj-applet-runner/bbmolahhldcbngedljfadjlognfaaein?hl=en https://chrome.google.com/webstore/detail/cheerpj-applet-run...
vr46 7y ago
One point about this project and others like it is that we really ought to not lose all the content created over more than a decade of Flash development. From Orisinal to Yugop, that work shaped the Internet and web today and should be preserved.
- milchek 7y ago
  I spent several years working primarily with Flash. I started originally with Director and Lingo, then moved to Flash and ActionScript. I built games, microsites, campaigns, competitions, a whole bunch of annoying Facebook apps, you name it. This was back in the day when I was whoring myself out to ad agencies as a freelancer and mostly working on brand/campaign stuff. Looking back on it, I have nothing I can show for it, really, besides some screenshots here and there. Pretty much all of the sites and projects are gone. It's a bit of a shame. This industry changes and moves forward at a lightning pace. Some of the other people from my uni went into motion graphics and they can at least use examples of ads or animations from over a decade ago in their showreels. We can't really do that as web developers because of the dynamic nature of the medium.
  - giancarlostoro 7y ago
    You can always take screenshots and document things yourself. Portfolios are usually pictures of your work and descriptions not a full blown browser executable.
  - vr46 7y ago
    Before everything went south, I recorded screen movies of some of my games in action, and grabbed some other visuals. Of course they're at postage stamp resolution by modern standards, but it's something. As far as looking back on my body of work as an old man goes, at least I have a lot of other things to look back on, but a whole chunk is probably lost to the ether.
enturn 7y ago
I've read that OpenFL supports some features of swf assets.
bobajeff 7y ago
This is really cool. Just imagining all the work involved and the developers seem very knowledgeable and optimistic about it. I think it'd be cool glean some insight from them about runtimes and standards. I wish them the best of luck on their path to full compatibility with Adobe flash.
justinclift 7y ago
Hopefully it can be made to work with Realm of the Mad God, a popular game from years back: https://www.realmofthemadgod.com https://www.realmofthemadgod.com :)
- Wowfunhappy 7y ago
  If you download the swf file (for me, the link was https://www.realmofthemadgod.com/AssembleeGameClient1565688747.swf https://www.realmofthemadgod.com/AssembleeGameClient15656887...), this seems to run fine in the standalone "Flash Player Projector", a great little utility buried in Adobe's website that that let's you load swf files outside of a web browser. https://www.adobe.com/support/flashplayer/debug_downloads.html https://www.adobe.com/support/flashplayer/debug_downloads.ht... I didn't bother creating an account, but the game opened fine and everything.
  - justinclift 7y ago
    Thanks, that seems to work. Couldn't log in properly, but that seems to be a server issue on their end. Support ticket opened, so we'll see. :)
  - JetSpiegel 7y ago
    This on AUR: https://aur.archlinux.org/packages/realmofthemadgod/ https://aur.archlinux.org/packages/realmofthemadgod/
snek 7y ago
I really hope that the web archive can put this to good use, similar to how they emulate MS-DOS games in browser.

206 points by conroy 7y ago

deleted 7y ago

[deleted]

I really hope this works, but I fear it will die a shumway death. One of the issues is there are two complete run-times inside of Flash. AVM1 (for AS1/2) and AVM2 (for AS3). AS1/2 is much easier to program and probably emulate. AS3 was much more advanced and was actually a pretty good language. Adobe should release the source, but probably doesn't due to all the security holes that probably are waiting to be found. Of course, that is speculation. [https://github.com/mozilla/shumway https://github.com/mozilla/shumway] [https://en.wikipedia.org/wiki/ActionScript https://en.wikipedia.org/wiki/ActionScript]

xeromal 7y ago
Google Swiffy too https://en.wikipedia.org/wiki/Google_Swiffy https://en.wikipedia.org/wiki/Google_Swiffy
fenomas 7y ago
> Adobe should release the source, but probably doesn't due to all the security holes that probably are waiting to be found. Of course, that is speculation. The AS3 spec, compiler and runtime/VM are all open source, have been since at least 2008 IIRC. Details are in the wikipedia page you linked, third paragraph. Aside: discussions of Flash or its legacy have an unfortunate tendency to get derailed by FUD, so it would perhaps be useful to avoid speculation like this where possible.
- mgamache 7y ago
  The AS3 VM is helpful, but only part of the player. The fact remains there is no player source to use as a guide for porting to other languages. It’s similar to the .net scenario. MS releases .net core open source, but didn’t release the GUI parts (until recently).
  - fenomas 7y ago
    I don't think anyone at Adobe is against open-sourcing the whole player; the problem would be relicensing it. It's a massive, hugely complex project, with lots of chunks that were licensed or written by other parties. And the codebase was probably 10-12 years old before anyone even considered the idea of opening anything... I definitely agree it'd be hugely useful, and wish it would happen, but I kind of doubt we'll ever see it.
    - mgamache 7y ago
      Right. I focused on the security, but it's a legacy code base with legal entanglements. Also created in another era.
  - giancarlostoro 7y ago
    They didnt release the GUI cause .NET Core is a rewrite. .NET Framework is only compatible through a common library between .NET Standard. Outside of that as far as I am aware they are similar but different runtimes.
icemelt8 7y ago
Even the editor FlashDevelop was very cool.
robin_reala 7y ago
The AS3 VM was opensourced in 2006 (as Tamarin) and donated to Mozilla who planned to use it as a back-end inside Gecko: https://en.wikipedia.org/wiki/Tamarin_(software) https://en.wikipedia.org/wiki/Tamarin_(software)
whatever_dude 7y ago
Flash Player contains a host of third party, commercially licensed software inside of it. Its source will never be released and it has nothing to do with security.
brighteyes 7y ago
> I really hope this works, but I fear it will die a shumway death. Yes, it may find a niche subset of Flash content it can do well, but there have been many attempts at Flash replacements, and all of them have failed, including serious ones with corporate backing like Shumway. Another cool one is Lightspark [1] The only real chance at 100% preservation of Flash content is for Adobe to open source all of it - the VMs, the runtime including the graphics, etc. - and to compile that. [1] https://en.wikipedia.org/wiki/Lightspark https://en.wikipedia.org/wiki/Lightspark

tgtweak 7y ago

I'm sort of at a loss to this.. flash was disliked because of three things, for the most part: • Capability of ActionScript (which can harbor malware) along with potential vulnerabilities in the interpreter itself. • Memory and CPU usage • Proprietary Does this rust variant even address all of these? Are we hoping to shim flash support into wasm-supported browsers? What good would this bring, specifically in regards to native flash's shortcomings? Not trashing the project, cause it's actually really cool, just curious why.

simcop2387 7y ago
Putting it into WASM at least will deal with a lot of the potential issues that AS could have, simply because WASM doesn't have access to the outside world to attack anything. As for RAM and CPU usage, there's not much that can likely be done. Better garbage collectors and other things like that might help but Flash itself was the cause of a lot of those problems. If this was a full implementation it'd be something open source that could run flash files/movies, so it'd be a bit less proprietary. There still wouldn't be open source editors that could handle doing it all so it wouldn't be complete or even close as an ecosystem. That said, all this could end up creating a good alternative for when all the browsers and adobe drop flash support in the next year (Firefox ESR is the only one I know of that's committed to supporting it until the end of 2020). A sane and safe migration path would be really useful for somewhere like newgrounds or archive.org to preserve internet history.
sjwright 7y ago
• Largely assumed mouse/keyboard interaction and had no plausible mechanism for responsive design • Proven track record of terrible security bugs • Was most frequently used for ads
- pjmlp 7y ago
  * It remains to be proven how WebAssembly is so much better than everything that came before it (hackers are yet to start having fun with exploits) * Flash games market was huge

todd3834 7y ago

This is pretty great! I remember building stuff with Flash back when it was still owned by Macromedia. There is a solid level of nostalgia for me there. I know one of the major concerns became security with enabling the Flash player. I assume with WebAssembly as the compile target we don’t really have to worry about it as much? Does anyone know if we are going to start seeing things like memory leaks and buffer overflows with web assembly or is that not a thing? I know Rust does a lot to resolve memory issues but I’m wondering about the other languages that compile to web assembly. Anyways, nice work!

thristian 7y ago
One of the big problems with things like Flash and Java on the web was that they were separate codebases from the browser, but (often) ran inside the browser's memory space, which was kind of a worst-of-both-worlds situation: multiple VMs each with their own individual vulnerabilities, but compromising any one would give you access to all of them. WebAssembly is different because it's built around the high-performance JavaScript VMs that have been developed over the past decade or so. When a browser-maker fixes a security hole in their VM, it's fixed for JavaScript and WebAssembly at the same time, because they're built on the same foundation. So no, you don't have to worry about security as much with WebAssembly - not because of any magical security properties WebAssembly has, but because even though the WebAssembly API is new, the security environment has seen decades of hardening.
gridlockd 7y ago
WASM can't magically make memory-unsafe languages memory-safe. You can still have memory leaks and buffer overflows, but (assuming a correct WASM implementation) a buffer overflow can not result in memory access outside the WASM instance's memory space - unless you provide it with the facilities to do so.

pjmlp 7y ago

It is finally happening! Nice to know about it.

tomjuggler 7y ago

This is petty cool, is there anything similar for Java applets, remember those?

yuri91 7y ago
There is Cheerpj[0]. You can compile any JAR into js, and there is even a Chrome extension to conveniently run Applets found in the wild[1]. [0] https://www.leaningtech.com/cheerpj/ https://www.leaningtech.com/cheerpj/ [1] https://chrome.google.com/webstore/detail/cheerpj-applet-runner/bbmolahhldcbngedljfadjlognfaaein?hl=en https://chrome.google.com/webstore/detail/cheerpj-applet-run...

vr46 7y ago

One point about this project and others like it is that we really ought to not lose all the content created over more than a decade of Flash development. From Orisinal to Yugop, that work shaped the Internet and web today and should be preserved.

milchek 7y ago
I spent several years working primarily with Flash. I started originally with Director and Lingo, then moved to Flash and ActionScript. I built games, microsites, campaigns, competitions, a whole bunch of annoying Facebook apps, you name it. This was back in the day when I was whoring myself out to ad agencies as a freelancer and mostly working on brand/campaign stuff. Looking back on it, I have nothing I can show for it, really, besides some screenshots here and there. Pretty much all of the sites and projects are gone. It's a bit of a shame. This industry changes and moves forward at a lightning pace. Some of the other people from my uni went into motion graphics and they can at least use examples of ads or animations from over a decade ago in their showreels. We can't really do that as web developers because of the dynamic nature of the medium.
- giancarlostoro 7y ago
  You can always take screenshots and document things yourself. Portfolios are usually pictures of your work and descriptions not a full blown browser executable.
- vr46 7y ago
  Before everything went south, I recorded screen movies of some of my games in action, and grabbed some other visuals. Of course they're at postage stamp resolution by modern standards, but it's something. As far as looking back on my body of work as an old man goes, at least I have a lot of other things to look back on, but a whole chunk is probably lost to the ether.

enturn 7y ago

I've read that OpenFL supports some features of swf assets.

bobajeff 7y ago

This is really cool. Just imagining all the work involved and the developers seem very knowledgeable and optimistic about it. I think it'd be cool glean some insight from them about runtimes and standards. I wish them the best of luck on their path to full compatibility with Adobe flash.

justinclift 7y ago

Hopefully it can be made to work with Realm of the Mad God, a popular game from years back: https://www.realmofthemadgod.com https://www.realmofthemadgod.com :)

Wowfunhappy 7y ago
If you download the swf file (for me, the link was https://www.realmofthemadgod.com/AssembleeGameClient1565688747.swf https://www.realmofthemadgod.com/AssembleeGameClient15656887...), this seems to run fine in the standalone "Flash Player Projector", a great little utility buried in Adobe's website that that let's you load swf files outside of a web browser. https://www.adobe.com/support/flashplayer/debug_downloads.html https://www.adobe.com/support/flashplayer/debug_downloads.ht... I didn't bother creating an account, but the game opened fine and everything.
- justinclift 7y ago
  Thanks, that seems to work. Couldn't log in properly, but that seems to be a server issue on their end. Support ticket opened, so we'll see. :)
- JetSpiegel 7y ago
  This on AUR: https://aur.archlinux.org/packages/realmofthemadgod/ https://aur.archlinux.org/packages/realmofthemadgod/

snek 7y ago

I really hope that the web archive can put this to good use, similar to how they emulate MS-DOS games in browser.