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.