kaelanirevyruun said:
"and use them locally"

Sadly after flash hit end of life, every time you start up your computer you get a popup saying "Adobe strongly recommends that immediately uninstalling flash player by using the "uninstall" button below". Your two options are...
1: Uninstall
2: Click "remind me later". Rinse and repeat next time you start up your computer.

If you use Flash Player 32 SA you get literally 0 popups, it just works. No install or anything, just a portable EXE that you open flash files with.

If you're getting popups, you aren't using the standalone projector

Is there somewhere I can make a case for Ruffle? I want to make games in flash, but it sucks I can't upload them here when it's possible with ruffle now.

When HTML5 replaced flash, everyone talked about how flash was obsolete. I think this was easy to accept because HTML5 is a lot more powerful, you can use C# within it. And tradable, linkable Unity games would be a pretty impressive step up, if it happened.

But I suppose that was meant to apply to websites. Shortform interactive games became kind of a casualty. When thinking about making something like Corruption of Champions, a Dungeon Crawler, a choose your own adventure, or an interactive animation... when I consider making any shortform games, I think about how I'd have to link people offsite from e621. They're not common in the places I normally browse.

I think back when these choices were made, Ruffle was new, it wasn't clear if it would emulate properly or if it would stick around. But it's been 3 years and Ruffle is working great, and this is crazy, it even works well on cellphones. I think it would be a great addition to e621, and probably single handedly bring people into making flash works.

Everyones talking about archival, but I'm coming at this from the angle of someone who wants to make something in flash.

Flash uploads aren't happening again regardless, and our primary developer has declined adding ruffle numerous times due to security concerns

I also seriously doubt HTML5 uploads will happen, but that remains to be seen

donovan_dmc said:
Flash uploads aren't happening again regardless, and our primary developer has declined adding ruffle numerous times due to security concerns

I also seriously doubt HTML5 uploads will happen, but that remains to be seen

Aaah, I didn't know. I only read this thread on it and the refusals were from several years ago and mentioned things Ruffle apparently couldn't do at the time. Like, it seems to run Actionscript3 just fine now.

It would be really helpful if e621 found a way to support using Ruffle while on the website...

https://github.com/ruffle-rs/ruffle/issues/2201

https://github.com/WebAssembly/content-security-policy/issues/7

wasm-eval has worked for a while in Chrome (so now also Edge) https://issues.chromium.org/issues/41450810 and Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1770468

NewGrounds appears to use Ruffle in an iframe on a different domain to isolate security concerns. E.G https://www.newgrounds.com/portal/view/222350 with a 'content' server name of uploads.ungrounded.net The ruffleembed.html player has HTTP headers access-control-allow-origin: https://www.newgrounds.com AND cross-origin-resource-policy: cross-origin

https://stackoverflow.com/questions/10636611/how-does-the-access-control-allow-origin-header-work
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy

Which says that the player expects to be embedded on the newgrounds page(s) and to render if requested there.

Meanwhile on the page where someone has to log in and do things (newgrounds.com); access-control-allow-origin: none -- says that this page is _inaccessible_ to requests from off of the page; thus preventing cross-site scripting attacks from accessing those pages.

e621 / e926 might need a new domain name for uploaded content. I'd prefer testing and confirming if an iframe contained script from the 'static content' domain is unable to take an action on the source site. That's probably a safer and more general solution than using wasm-eval alone since it establishes an entirely isolated logical security sandbox.

content-security-policy
default-src 'self'; script-src 'self' ads.dragonfru.it js-agent.newrelic.com bam.nr-data.net https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://www.recaptcha.net/ ; style-src 'self' 'unsafe-inline'; connect-src 'self' ads.dragonfru.it bam.nr-data.net plausible.dragonfru.it; object-src 'self' static1.e621.net static1.e926.net; media-src 'self' static1.e621.net static1.e926.net; frame-ancestors 'none'; frame-src https://www.google.com/recaptcha/ https://www.recaptcha.net/; font-src 'self'; img-src 'self' data: static1.e621.net static1.e926.net ads.dragonfru.it; child-src 'none'; form-action 'self' discord.e621.net discord.com

ketsueki said:
It would be really helpful if e621 found a way to support using Ruffle while on the website...

https://github.com/ruffle-rs/ruffle/issues/2201

https://github.com/WebAssembly/content-security-policy/issues/7

wasm-eval has worked for a while in Chrome (so now also Edge) https://issues.chromium.org/issues/41450810 and Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1770468

NewGrounds appears to use Ruffle in an iframe on a different domain to isolate security concerns. E.G https://www.newgrounds.com/portal/view/222350 with a 'content' server name of uploads.ungrounded.net The ruffleembed.html player has HTTP headers access-control-allow-origin: https://www.newgrounds.com AND cross-origin-resource-policy: cross-origin

https://stackoverflow.com/questions/10636611/how-does-the-access-control-allow-origin-header-work
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy

Which says that the player expects to be embedded on the newgrounds page(s) and to render if requested there.

Meanwhile on the page where someone has to log in and do things (newgrounds.com); access-control-allow-origin: none -- says that this page is _inaccessible_ to requests from off of the page; thus preventing cross-site scripting attacks from accessing those pages.

e621 / e926 might need a new domain name for uploaded content. I'd prefer testing and confirming if an iframe contained script from the 'static content' domain is unable to take an action on the source site. That's probably a safer and more general solution than using wasm-eval alone since it establishes an entirely isolated logical security sandbox.

content-security-policy
default-src 'self'; script-src 'self' ads.dragonfru.it js-agent.newrelic.com bam.nr-data.net https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://www.recaptcha.net/ ; style-src 'self' 'unsafe-inline'; connect-src 'self' ads.dragonfru.it bam.nr-data.net plausible.dragonfru.it; object-src 'self' static1.e621.net static1.e926.net; media-src 'self' static1.e621.net static1.e926.net; frame-ancestors 'none'; frame-src https://www.google.com/recaptcha/ https://www.recaptcha.net/; font-src 'self'; img-src 'self' data: static1.e621.net static1.e926.net ads.dragonfru.it; child-src 'none'; form-action 'self' discord.e621.net discord.com

Saying no for "security concerns" is BS for "I'm too lazy to do it properly" Don't waste your energy. Allow wasm-unsafe-eval and just click the open in new tab button when it fails to load due to CORS

rock48 said:
Saying no for "security concerns" is BS for "I'm too lazy to do it properly" Don't waste your energy. Allow wasm-unsafe-eval and just click the open in new tab button when it fails to load due to CORS

Have you considered our single developer not wanting to devote time to obsessively updating ruffle every time some security issue is found? Or extensively testing it to ensure it actually works properly? He's a volunteer. He isn't paid. He's said he doesn't want to implement it, security issues was just one of the concerns.

Donovan DMC said:
Have you considered our single developer not wanting to devote time to obsessively updating ruffle every time some security issue is found? Or extensively testing it to ensure it actually works properly? He's a volunteer. He isn't paid. He's said he doesn't want to implement it, security issues was just one of the concerns.

What if they use the second domain name idea mentioned by Ketsueki, and use that second domain to just allow wasm-unsafe-eval.. But not host Ruffle on the server?

Cross-site scripting attacks from within the iframe won't work, but Ruffle as a browser extension will, and Ruffle won't need to be kept up-to-date by the server administration staff.

This would seem to address literally all of the issues being presented.

please just use ruffle im begging you people

whats so hard about implementing it to the site when other sites have already been doing it

thefollowone said:
please just use ruffle im begging you people

whats so hard about implementing it to the site when other sites have already been doing it

If it's that easy, implement it yourself then. E621 is open source.

kyiiel said:
If it's that easy, implement it yourself then. E621 is open source.

The challenges are more to do with the server administration side of things, not the code side of things.

Which is why I proposed that they let people just use the browser-side extension, but to secure against cross-site scripting using a second domain name. Incurs minimal admin-side work, but lets people play their games and porn animations.

kyiiel said:
If it's that easy, implement it yourself then. E621 is open source.

Are you seriously playing the "Go make your own!" card for a website hosting several terabytes of data to an audience of thousands a day just because the codebase is free to copy?

errorist said:
Are you seriously playing the "Go make your own!" card for a website hosting several terabytes of data to an audience of thousands a day just because the codebase is free to copy?

Considering we only have one unpaid developer, implementing it yourself and making a pull request is the best way to request a feature. Though in this case, implementing it yourself isn't really possible. Our one dev (that has to approve PRs as well) has also said he doesn't want to implement ruffle. Just making the pr doesn't remove all the effort he still needs to make towards implementing it.

fluffball said:
Anyone who wants to have flash support indefinitely just needs to keep an old version of their browser installed. I don't plan on updating my browser once Flash support ends.

I do like flash, but you really should update your browser for new security features.

donovan_dmc said:
Considering we only have one unpaid developer, implementing it yourself and making a pull request is the best way to request a feature. Though in this case, implementing it yourself isn't really possible. Our one dev (that has to approve PRs as well) has also said he doesn't want to implement ruffle. Just making the pr doesn't remove all the effort he still needs to make towards implementing it.

Thank you for clarifying. Most of the community is not aware of the fact there is only one unpaid developer, much like myself until now. But people will also continue to ask about ruffle in the meantime so best not get too defensive; people tend to lose interest in reading a forum post several pages long. But I do believe there are also working ruffle plug-ins. Is it worth wild updating the message to link to or ask that people download the ruffle plug in at their own risk?

guiltstar said:
... I want to make games in flash, but it sucks I can't upload them here when it's possible with ruffle now. ... Unity games would be a pretty impressive step up, if it happened. ... Everyones talking about archival, but I'm coming at this from the angle of someone who wants to make something in flash.

Use WebGL export in Godot. Same effect, better graphics, physics and works on almost any modern platform. Engine, assets and code are in self-contained package downloaded from server as any regular content. Works on desktop, mobile, Chrome or Firefox. No need for extra players, plugins or other programs.
E621 could host smaller games. "Small game" being relative as same project exported for tests unoptimized is casually 150MB+ while highly optimized goes down to ≈30MB.

funfact, swivel seems to still work, especialy for converting: https://www.newgrounds.com/wiki/creator-resources/animation-resources/swivel-flash-to-video

You know, instead of implementing Ruffle into the website, you could just allow flash files to be displayed as they used to on the website. That way you don't have to implement Ruffle, but if someone themselves was running Ruffle on their local machine as a browser addon they could still view the content in the website. It would just refuse to play for someone who doesn't have Flash or Ruffle installed, yet still work for someone running Ruffle on their local machine.

pikafan15 said:
You know, instead of implementing Ruffle into the website, you could just allow flash files to be displayed as they used to on the website. That way you don't have to implement Ruffle, but if someone themselves was running Ruffle on their local machine as a browser addon they could still view the content in the website. It would just refuse to play for someone who doesn't have Flash or Ruffle installed, yet still work for someone running Ruffle on their local machine.

they already do that, the embed for the .swf file is still on the page, it just displays nothing unless you have flash player (or something else that can try to load it installed).

Except the site is actively blocking that from working, for some reason. Only the link to open it in its own tab works.

notmenotyou said:

Finding your save files from browsers and migrate them to the standalone flash player projector:

Important information for all instructions: Flash Player saves everything in .sol files in a cached directory, if you follow the instructions below any reference to "save files" means these .sol files.

Does the Chrome method also work on Edge or does it need to go through another process?

dba_afish said:
they already do that, the embed for the .swf file is still on the page, it just displays nothing unless you have flash player (or something else that can try to load it installed).

They are blocked from working in the page, as someone else here has pointed out. When Flash was discontinued, it seems there was an update on e621's side of things to actively block SFWs from being embedded in the page anymore. This is the only site where I've seen this issue with Ruffle as other sites embed the files on the page perfectly.

It looks like this on the page.

donovan_dmc said:
Flash uploads aren't happening again regardless, and our primary developer has declined adding ruffle numerous times due to security concerns

I also seriously doubt HTML5 uploads will happen, but that remains to be seen

donovan_dmc said:
Have you considered our single developer not wanting to devote time to obsessively updating ruffle every time some security issue is found? Or extensively testing it to ensure it actually works properly? He's a volunteer. He isn't paid. He's said he doesn't want to implement it, security issues was just one of the concerns.

donovan_dmc said:
Considering we only have one unpaid developer, implementing it yourself and making a pull request is the best way to request a feature. Though in this case, implementing it yourself isn't really possible. Our one dev (that has to approve PRs as well) has also said he doesn't want to implement ruffle. Just making the pr doesn't remove all the effort he still needs to make towards implementing it.

Can you at least talk to them about updating the CORS policy to allow web assembly to load assets from e6's CDN? I can run Ruffle locally, via Userscripts, on my iPad, and confirmed it works as far as embedding the player and initializing, but e6's CORS policies prevent the WebAssembly from loading content from the static CDN. To reiterate, visiting a flash upload on e6 results in ruffle successfully loading and embedding when loading Ruffle via script; PikaFan15 was wrong; but it is erroring out with a CORS problem the moment it tries to load the SWF.

Resolving the CORS issue itself would allow individual users to assume the risk of using a third party extension or flash player alternative, whilst not exposing users to any direct safety risks or relying on a single extension.

itazuraayagi said:

Can you at least talk to them about updating the CORS policy to allow web assembly to load assets from e6's CDN? I can run Ruffle locally, via Userscripts, on my iPad, and confirmed it works as far as embedding the player and initializing, but e6's CORS policies prevent the WebAssembly from loading content from the static CDN. To reiterate, visiting a flash upload on e6 results in ruffle successfully loading and embedding when loading Ruffle via script; PikaFan15 was wrong; but it is erroring out with a CORS problem the moment it tries to load the SWF.

Resolving the CORS issue itself would allow individual users to assume the risk of using a third party extension or flash player alternative, whilst not exposing users to any direct safety risks or relying on a single extension.

If you're using extensions already, just get one that can edit CORS?

donovan_dmc said:
If you're using extensions already, just get one that can edit CORS?

https://addons.mozilla.org/pt-BR/firefox/addon/ruffle_rs

seems to work if you click the "open in a new tab" button

donovan_dmc said:
If you're using extensions already, just get one that can edit CORS?

This is not possible on Safari. Apple enforces XSS & CORS policies more strictly than most, and in my experience, even extensions cannot typically override this. Ruffle does offer a Safari extension on Mac, which may work, but I'm on iPad, using Userscripts to inject the JS version of ruffle directly into the content.

My primary focus is also just that: Mobile devices. Flash has never been available in these places without 3D party browsers, but scripts like Ruffle bring with them the ability for said content to be viewed on mobile for the first time. This has potential to broadly increase accessibility to said content beyond what it ever was when Flash was actively supported.

Advocating for circumventing CORS & XSS is also not a great precedent, especially if a security argument is being made for not locally hosting a copy of Ruffle and embedding directly.

Apropos of nothing...

Is a nearly-5-year-old, 4-page thread the best way to communicate information on how to view Flash submissions on e621 in 2025?

I would humbly suggest adding something like "OLD - SUPERSEDED" to this thread title, making a final post in this thread that says "Go to the new thread here", possibly editing the first post in this thread to say "This is old information, go to the new thread here", and locking the thread.

The new thread should include information in the first post like...

1. e621 will not implement Ruffle on-site because of x, y, and z.

2. If you're on desktop, here are directions for modern Chrome and Firefox, standalone player on some OSes (with archive.org or equal links as needed), browser forks that still support NPAPI (with links to where to get the browsers and the NPAPI Flash plugin), etc.

3. If you're on mobile, here are your options.