Topic: [Feature] Ability to upload Flash content

Requested feature overview description.
This feature would return users the ability to upload Flash content.

Why would it be useful?
Even to this day, there are lots of old furry Flash content that is not on e621. Besides, thanks to projects like Ruffle, Flash is experiencing a slow but sure revival, which means we will likely see many more furry Flash works in the near future.

What part(s) of the site page(s) are affected?
Flash content uploads would no longer be rejected.

electricitywolf said:
Requested feature overview description.
This feature would return users the ability to upload Flash content.

Why would it be useful?
Even to this day, there are lots of old furry Flash content that is not on e621. Besides, thanks to projects like Ruffle, Flash is experiencing a slow but sure revival, which means we will likely see many more furry Flash works in the near future.

What part(s) of the site page(s) are affected?
Flash content uploads would no longer be rejected.

as someone who worked with flash in the distant past.
please stop trying to make flash happen in 2025.

valthar said:
as someone who worked with flash in the distant past.
please stop trying to make flash happen in 2025.

it's not about "making flash happen" it's about archiving furry art so it doesn't get lost to time.

I'd much rather we leave flash in the past, e6 stopped accepting flash uploads for a reason
a ruffle integration has been denied multiple times so flash posts are useless to most people

donovan_dmc said:
a ruffle integration has been denied multiple times so flash posts are useless to most people

There is the Ruffle browser extension. This site does not need a change in that regard.

electricitywolf said:
There is the Ruffle browser extension. This site does not need a change in that regard.

An extension that less than 0.5% of users will bother installing still results in the posts being useless for >99% of users

electricitywolf said:
There is the Ruffle browser extension. This site does not need a change in that regard.

Not everyone is using a pc, not even a majority of users

snpthecat said:
Not everyone is using a pc, not even a majority of users

And before anyone tries to mention mobile browsers with extensions (like I would), the browser used on almost 3/4 of mobile devices is chrome and does not support extensions

Make your own Booru, with Blackjack and 20072024 UI? :P

Actually, it would not be a bad idea to have a Flash focused Booru, if it's strictly things uploaded by the OP. There's sites that do SWF archives but e621ng has a far nicer experience.

I do still constantly bump into content that was interactive flash but no longer possible to be uploaded as original file and I also do not like this.

The main reason for flash uploads to be disabled wasn't because people weren't able to view them, it was security. Software is EoL, so if there's any vulnerability that's found and utilized, there would be no updates to patch that.
However we do have whitelist and we do have websites which do have a lot of content and have also disabled new flash uploads, including Furaffinity.
Also I'm not entirely sure how huge this risk is considering websites like Newgrounds still actively allow SWF files to be uploaded.

donovan_dmc said:
I'd much rather we leave flash in the past, e6 stopped accepting flash uploads for a reason
a ruffle integration has been denied multiple times so flash posts are useless to most people

The discussion around this has been around time when half of the staff was differend and it was just around the time where people still had flash player in their browsers and it was just getting cut off forcibly to some.
Also the stage of Ruffle was that it wasn't that great and implementation would've required at least some amount of work hours from someone, at the same time when there was much bigger project on table and nothing was really advancing.

Ruffle seems to be at the stage where it does actually support Actionscript 3, that was one of the biggest drawbacks because it felt like a toy that could only really do some extremely old flash stuff or videos looping, where now it should actually do majority of things that native flash player did.

Also we are still going to keep the old SWF flash files in here, available directly on search and even the thumbnails have been broken for some time now, so even I'm now moving on board to actually maybe do something about this as the situation has changed and we have moved past the "FLASH IS DYING, EVERYONE PANIC!1!" phase.

I think it would be a great feature! Flash is fortunately dead (My Pentium 4 probably still wants to kill Adobe programmers) and with Ruffle having become way better I think there is no better time to add Flash uploading than now since a lot of content is now useable again.
Even just FA has a lot of fully unarchived stuff that is just rotting there (and FA does support Ruffle so they can use it if people stumble upon it)

Not only are there logistically sound reasons not to include Flash anymore (Barely any users interact with such content, a majority of users use browsers that don't support it, etc.) but there are also potential security reasons why we shouldn't allow it, either. Given the year at which Flash was discontinued, and the fact that it's been 5 years - a lifetime when you consider tech and cyber security - allowing people to upload potentially harmful Flash files to the site is just not a good idea.

And, before you ask, no. There's no real safe way to check a flash file for such things unless you decompile the file, which itself can be risky.

bird-tm said:
Not only are there logistically sound reasons not to include Flash anymore (Barely any users interact with such content, a majority of users use browsers that don't support it, etc.) but there are also potential security reasons why we shouldn't allow it, either. Given the year at which Flash was discontinued, and the fact that it's been 5 years - a lifetime when you consider tech and cyber security - allowing people to upload potentially harmful Flash files to the site is just not a good idea.

And, before you ask, no. There's no real safe way to check a flash file for such things unless you decompile the file, which itself can be risky.

This is clearly coming from the standpoint of "artists don't do new content with flash and we only get new content" when in reality, we do not have even fraction of acceptable content from past here and like already said, I have bumped into many instances where I would've needed to upload SWF flash file here, but now nothing is uploaded because conversionjob would've taken way too much time and effort.
Also realistically, if going by the idea that only whitelisted URLs are able to upload content, we would not have malicious files from sites that also disallowed new SWF uploads along e621, this includes major furry websites with thousands of files with legacy content not here yet.

Also considering many sites have not disabled SWF flash uploads, including Newgrounds, SoFurry and Inkbunny as quick examples, security issues could be more of fear mongering than anything else.
This is because Ruffle is not flash, so even if there is Adobe flash exploits in there, they could not be utilized and if they can, Ruffle is in active development, meaning the only way to actually get this malicious act to manifest is to run the file locally on EoL Adobe Flash Player or Projector.

Some points of note about Ruffle is that, as Mairo said, it's different from Flash and in active development, so it could moderate security issues, and being written in Rust and WASM makes it dramatically more secure already.
If it gets installed on a website, it even autoupdates so if they ship a security fix it'll just download itself, and it means compatibility will always be improving instead of being frozen in time (and, being open source, you CAN report bugs to the team and they will fix it).

Also I've seen the "most people use phones, so it's useless!"
But Ruffle works on phones! I wasn't sure, so I tried playing back some stuff from FA on my phone, and after a loading time it just worked perfectly. If anything, adding it would allow MORE people to interact with Flash content after all those years, without the need for being on a desktop and (at least for e621) getting an extension or finding it in a place la FA that integrates Ruffle already

This is better than the original Adobe Flash, which was famously stonewalled by Steve Jobs due to "horrific performance and security issues", which proved to be right because when they ported it to Android it performed HORRIBLY and was deprecated quickly, which is part of why HTML5 became a thing

I would enjoy being able to play goofy furry smut games again without downloading the file. And I'd enjoy seeing stuff that hadn't previously been uploaded.

If e6 continues to host flash files, all the security arguments are nonsense. If you aren't verifying those files, you do not know that they were ever harmless.
I don't even know if e6 goes through the trouble of blocking external links in flash like swfchan did.
Newgrounds doesn't.

Until a valid Flash replacement comes along that .swf files can be converted to that would then be supported, Flash content should be archived. If e6 still takes the stance that it is an archive, it should take that load. Current conversion options are lossy, even if you use a lossless video output as vector graphics have no resolution limit.

"no one uses it"
Okay then delete all the content on the site that hasn't been accessed in 10 years or has been accessed by less than 0.1% of the users. I don't know why you keep all this crap on here no one uses O.o

cormy1 said:
If e6 continues to host flash files, all the security arguments are nonsense. If you aren't verifying those files, you do not know that they were ever harmless.

Considering you can't run the flash files without extensive effort, there is no problem with existing files
New uploads are not allowed both due to new zero days which are not being fixed (most of which are likely not exploited in old flash files), and the fact that you cannot run them under normal circumstances

alphamule said:
Make your own Booru, with Blackjack and 20072024 UI? :P

Actually, it would not be a bad idea to have a Flash focused Booru, if it's strictly things uploaded by the OP. There's sites that do SWF archives but e621ng has a far nicer experience.

I was gonna say, I swear that SWFchan or whatever it's called is exactly that

does SWFChan still exist?

donovan_dmc said:
Considering you can't run the flash files without extensive effort, there is no problem with existing files
New uploads are not allowed both due to new zero days which are not being fixed (most of which are likely not exploited in old flash files), and the fact that you cannot run them under normal circumstances

Even ignoring that Ruffle is not Flash so is not subject to flash vulnerabilities, and that Ruffle is in active development so any vulnerabilities it does have can be quickly patched, AND that it runs in the browser sandbox meaning that even if a vulnerability IS found its damage will be limited to, at worst, locking up the browser, redirecting to another site, or stealing the user's e621 cookies, there is nothing saying this change HAS to be accompanied by adding Ruffle to the main site. You could turn Flash uploads back on and leave everything else as is. Add flash to the default blacklist if people being able to see content most of them won't be able to interact with bothers you so much. If we say we're an archive site, let's commit to it.

tokwas said:
If we say we're an archive site, let's commit to it.

If we ran with that mentality we'd have no quality standards
We are a curated archive, and flash is not part of that curation

Flash has been deprecated for nearly a decade and discontinued for 4 years, move on and accept that this site is not your host for flash content

tokwas said:
Even ignoring that Ruffle is not Flash so is not subject to flash vulnerabilities, ...

It's emulating Flash, making it no more protected (at default) than OG Flash Player. Yeah, I know, "their website says they're more secure than Flash!" We'll circle back to this later, but that still doesn't mean much.

tokwas said:
...and that Ruffle is in active development so any vulnerabilities it does have can be quickly patched,...

It's a FOSS community project, so let's not assume the response time is on par with a commercial effort. Besides, having to maintain compatibility will tie their hands on how they can patch vulnerabilities, further slowing them down.

Additionally, with Flash being dead, the government isn't going to be tracking & profiling security vulnerabilities (that's what CVEs are, if you've seen that before); they'll only hear about vulnerabilities if they're relatively small userbase reports them or they stumble across them on their own. Forgive me for doubting their ability to quickly patch these things. It's not that I doubt their competence, but it's a difficult task.

tokwas said:
...AND that it runs in the browser sandbox...

Firstly, it's also available as native applications, but whatever, in this context, sure.
Secondly, it does run in the browser sandbox... exactly the same way the Flash Player extension did. Clearly that wasn't enough for security experts when it got canned, but what makes you think it is enough now?

tokwas said:
...meaning that even if a vulnerability IS found its damage will be limited to, at worst, locking up the browser, redirecting to another site, or stealing the user's e621 cookies...

...yes, I can see no problem with allowing a third party to redirect a user to a random website; it's not like that's how you get your bank info stolen.
Cookies store a lot of valuable info. To be specific, having someone get into your cookies is how you get your session hijacked. Losing control of your e6 account is one thing, but there's nothing stopping malware from playing the long game & trying to steal your banking info, or your email account. So yeah, let's not pretend this isn't still a colossal problem. You probably won't get a rootkit, but you can still get royally screwed. Iirc, an email/PDF with malicious code that got into the browser cookies is how the LTT channel hack happened. This isn't nihilistic predictions; this is a real, viable attack vector in active use by malware vendors.
That all sounds a lot worse than you thought, right? Don't worry; it gets even worse. Who says it will remain locked in the browser sandbox????

The 3DS emulated the DS in a sandboxed mode that kept any DS vulnerabilities from crossing into the 3DS side... until (to slightly oversimplify) a poorly written game was used to break through DS mode and enable full control of the entire device. Hmmm... do you think a (intentionally) poorly written Flash game could do the same? Just because it's sandboxed doesn't mean it's safe.

Ruffle is probably in better shape than Flash, but it's still a FOSS program that could be exploited through contributions (just like Linux a while back), & even failing that, someone familiar enough with Flash could analyze their code & find what holes from Flash still remain. It's somewhat safer. Don't mistake that for safe.

tokwas said:
...there is nothing saying this change HAS to be accompanied by adding Ruffle to the main site. You could turn Flash uploads back on and leave everything else as is. Add flash to the default blacklist if people being able to see content most of them won't be able to interact with bothers you so much. If we say we're an archive site, let's commit to it.

I'm not saying you shouldn't use Ruffle; I'm indescribably happy it exists & encourage people to use it for legacy content. However, we shut down Flash uploads b/c that would allow new Flash content to be submitted, that might be loaded with malware that took advantage of the deprecated state of Flash to analyze it for vulnerabilities. We are not facilitating that.

Besides, what's to stop people unaware of Ruffle from using an old build of Flash Player or an old Flash decompilation tool & being just as vulnerable?

I'm all for user choice & freedom, but this is my line. Allowing new Flash uploads is unfathomably dangerous, & we are not going to do it.

Flash is dead. We aren't nuking legacy Flash content because we're an archive, but we aren't adding any more. Grieve & move on. Let this go.

aacafah said:
The 3DS emulated the DS in a sandboxed mode that kept any DS vulnerabilities from crossing into the 3DS side... until (to slightly oversimplify) a poorly written game was used to break through DS mode and enable full control of the entire device. Hmmm... do you think a (intentionally) poorly written Flash game could do the same? Just because it's sandboxed doesn't mean it's safe.

not emulated. when doing DS stuff (and GBA stuff) the console shuts down, restarts, and boots into an entirely different mode to do DS stuff natively. and the issue was more on the 3DS side than the DS side, since data written into the DS settings was accessible afterward in 3DS mode.

dba_afish said:
not emulated. when doing DS stuff (and GBA stuff) the console shuts down, restarts, and boots into an entirely different mode to do DS stuff natively. and the issue was more on the 3DS side than the DS side, since data written into the DS settings was accessible afterward in 3DS mode.

Point stands; you can exploit vulnerabilities in the sandbox to break out of it. That's the definition of an exploit chain.

aacafah said:
Secondly, it does run in the browser sandbox... exactly the same way the Flash Player extension did.

Um, that's wrong. The original Flash plugin (not an extension!) ran as a separate .exe application that was launched by and communicated with the browser. (That's what the word "plugin" means in the context of a browser, and that's why no browser has used the word "plugin" to refer to the little add-ons you install in like 15 years. Extensions run in the sandbox. Plugins don't -- that's why they are (were) useful.) The Flash plugin had free rein to access the disk, network, etc., in whatever arbitrary ways it desired. Part of the reason Flash became popular was because it could do things that applications that ran in the JavaScript sandbox straight up could not do, like access files on disk and communicate via arbitrary sockets. Ruffle runs as a WASM application in the JavaScript sandbox. Everything it does has to be done through the browser JavaScript API, which is the same attack surface every website has direct access to. Assuming Ruffle was broken wide the fuck open, like direct arbitrary code execution in the browser, there is nothing it could do that can even know the filesystem exists without explicit user interaction. At absolute worst, it could do what malicious websites do, which is display a prompt saying "Press Windows+R then Ctrl+V then Enter to prove you're not a robot" after copying some nefarious commands to the clipboard, which Ruffle can natively do anyway. If anyone on this site falls for that scam, they need some remedial cybersecurity classes in a big ass hurry, and should probably have their computer confiscated until they've taken them.

Also, I messed up earlier. All of e621's auth cookies are set in the Cookie: header as HTTP-only, meaning they aren't visible to JavaScript (and by extension WASM, and by extension Ruffle) at all, even if something gets hijacked. Turns out the people who manage cybersecurity for this site actually know what the fuck they're doing. No cookie exfil for our imaginary hackers. At worst they could send some API requests to e621 as the logged in user while the user was on the page containing the Flash content. What an attacker would get out of impersonating someone else on a furry porn site is anyone's guess, especially when they'd need the mother of all Ruffle exploits to do it.

aacafah said:
Besides, what's to stop people unaware of Ruffle from using an old build of Flash Player or an old Flash decompilation tool & being just as vulnerable?

Nothing, but no one who doesn't know what they're doing is going to know that they even can do that, let alone jump through all the hoops to do it. Chrome removed support for plugins ages ago. You'd need a 4-year-old build of a browser to even start with the Flash plugin, and since that's insecurity city, browser vendors make it really hard to download old builds. As for a decompiler, no one who doesn't know Flash malware exists even knows what that is.

aacafah said:
Point stands; you can exploit vulnerabilities in the sandbox to break out of it. That's the definition of an exploit chain.

Oh for fuck's sake. Don't you think, if such a vulnerability existed in the browser sandbox, browser vendors would know about it? Or at the very least that sites like Itch.io that let users upload arbitrary WASM files (aka the exact same access someone would get to e621 if they completely shattered Ruffle's security) would be completely infested with malware?

Also, don't you think, if such a vulnerability existed, they'd be exploiting it somewhere people actually type their credit card number and not wasting their time here?

tokwas said:
Oh for fuck's sake. Don't you think, if such a vulnerability existed in the browser sandbox, browser vendors would know about it?

No? Creators of software do not know every little intricate detail that may cause a bug, especially for software as big as a browser, and even more for open source projects collaborated on by thousands of users

log4shell existed as an issue since 2013 and was not discovered until 8 years later (2021)

shellshock existed for nearly 3 decades before being discovered

And just because an explot avenue doesn't exist now does not mean one won't in the future, any small change could have unexpected consequences and introduce a potential exploit at any time
Or like in the case of xz (compression utility) a malicious maintainer could introduce their own code that adds some form of exploit, in this case a backdoor which was only noticed due to performance degradations

And yes while all software can have these issues, software known for zero day exploits and a lack of solid security is clearly at extra risk

donovan_dmc said:
log4shell existed as an issue since 2013 and was not discovered until 8 years later (2021)

and was patched within 5 days

donovan_dmc said:
shellshock existed for 2 decades before being discovered

and was patched within 12 days

donovan_dmc said:
Or like in the case of xz (compression utility) a malicious maintainer could introduce their own code that adds some form of exploit, in this case a backdoor which was only noticed due to performance degradations

the confluence of factors that allowed that to happen were one in a million -- a library with very few, very tired maintainers, that happened to be depended on by a massive, high-profile project with massive amounts of system access (systemd/sshd), that had a convenient way to hide malicious data in a place it was unlikely to be found (it was a compression library whose maliciously modified build script used the decompression tool it had just compiled to decompress some additional code hidden in the test suite which it then stealthily added to the final binary, to avoid any malicious code appearing in the source tree). also the backdoor in xz 5.6.0 was discovered within a month of the first malicious commit and all major distributions rolled back to the last known good version of liblzma within hours. also also the xz backdoor was done by a nation state.

donovan_dmc said:
And yes while all software can have these issues, software known for zero day exploits and a clear lack of solid security is clesrly at extra risk

Flash is known for zero day exploits. Ruffle is not. Ruffle has nothing in common with the original Flash player apart from playing the same files. They share no code. They aren't even written in the same programming language. But even if Ruffle is as vulnerable as you all say -- and given that it's written in Rust, a programming language widely known for forcing the programmer to write code that is resilient to common memory safety vulnerabilities that form the basis for 99% of exploits, I don't believe it is -- the browser would have to be equally vulnerable for that to mean anything, and if that were true, we'd be seeing people getting zero-clicked by malicious webpages left and right. Nobody uses Ruffle, that I'll grant you, but millions of people use Firefox, and billions use Chrome. That's where the vulnerability would have to be. Again, if these vulnerabilities exist, why aren't people exploiting them?

And again, e621 is an infinitesimally small target, doubly so when someone would have to break out of Ruffle (and I really cannot overemphasize how hard that would be) in order to do anything (like fool some incredibly gullible people or abuse cookie permissions to puppeteer e621 accounts for as long as they're looking at the page with the malicious code) for maybe a couple months before moderators noticed the file was malicious and pulled it. Even if we were wide open to attack -- and we're not -- who would bother to attack us for so little reward?

tokwas said:
Um, that's wrong. The original Flash plugin (not an extension!) ran as a separate .exe application that was launched by and communicated with the browser...

Fair point, I got some wires crossed.

tokwas said:
...Everything [Ruffle] does has to be done through the browser JavaScript API, which is the same attack surface every website has direct access to. Assuming Ruffle was broken wide the fuck open, like direct arbitrary code execution in the browser, there is nothing it could do that can even know the filesystem exists without explicit user interaction. At absolute worst, it could do what malicious websites do, which is display a prompt saying "Press Windows+R then Ctrl+V then Enter to prove you're not a robot" after copying some nefarious commands to the clipboard, which Ruffle can natively do anyway. If anyone on this site falls for that scam, they need some remedial cybersecurity classes in a big ass hurry, and should probably have their computer confiscated until they've taken them.

Yet once again, redirection to malicious websites is a bigger problem than you think, & you can do a lot of subtle nefarious work by getting creative. We recently changed the Download button to a Fullscreen button; what if an attacker changed it back & had it directly prompt a file download when pressed... before downloading a malicious file? That idea is just off the top of my head, I'm sure there's a ton more things you can do. Here's another half-baked one; intercept a random/specific page navigation & instead send the user to a fake login site prompting the user to type in their password again "for security"/"for compliance with that new UK law"/"for compliance with that new AZ law" & just send the value somewhere else while forwarding them to their initial destination with the same cookies as before, with them having full access to your account? Spamming porn ads on the screen like it's an anti-porn TV movie from the 90s is the worst you can do if you're not playing the long game.

tokwas said:
All of e621's auth cookies are set in the Cookie: header as HTTP-only, meaning they aren't visible to JavaScript (and by extension WASM, and by extension Ruffle) at all, even if something gets hijacked. Turns out the people who manage cybersecurity for this site actually know what the fuck they're doing. No cookie exfil for our imaginary hackers. At worst they could send some API requests to e621 as the logged in user while the user was on the page containing the Flash content. What an attacker would get out of impersonating someone else on a furry porn site is anyone's guess, especially when they'd need the mother of all Ruffle exploits to do it.

Idk, grab their email from their user settings & send an email posing as e6/BD to get them to open it/it's PDF attachment to grab cookies exactly how I detailed before? It's called an exploit chain for a reason; it's a chain of minor vulnerabilities that are combined to increase an attacker's access. Facilitating that is unwise.

Besides, "at worst they could send some API requests"? So they could upload 10 pics of IRL gore & get you banned? I don't know about you, but that still sounds like something I'd prefer to prevent, thank you very much.

tokwas said:
As for a decompiler, no one who doesn't know Flash malware exists even knows what that is.

Yeah, it's totally out of the question for users to see people posting rips from Flash animations and ask "How did you do that?", receive a simple explanation, try it for themselves & get pwned. Stop assuming people are either rocket surgeons or too stupid to function. The phrase "knowing just enough to be dangerous" didn't materialize out of thin air; knowing how to dodge/disable safeguards doesn't mean you know why they're there in the first place.

In fact, because e6 & users will still prefer the raw files to an interactive container in 9/10 cases, allowing new uploads to be Flash files will increase the chances of a user downloading a new Flash upload to unpack it & upload the raw files for convenience on their mobile Chrome browser/third-party client & getting pwned. And hell, what if that user is a staff member? This is still bad.

tokwas said:
Oh for fuck's sake. Don't you think, if such a vulnerability existed in the browser sandbox, browser vendors would know about it? Or at the very least that sites like Itch.io that let users upload arbitrary WASM files (aka the exact same access someone would get to e621 if they completely shattered Ruffle's security) would be completely infested with malware?

Itch.io is a for-profit company with the resources for content moderation; we're not. They likely already have infrastructure to detect malware & for users to report malware, along with a sizable team to handle it; we don't b/c we don't host (much) interactive software. Itch.io would still need good moderation for malware regardless of supporting this stuff; we wouldn't.

tokwas said:
Also, don't you think, if such a vulnerability existed, they'd be exploiting it somewhere people actually type their credit card number and not wasting their time here?

I'll say it again; this could be an entrypoint for a longer exploit chain. Whose to say someone using this to install a rootkit won't go for someone's bank details?

tokwas said:

donovan_dmc said:
log4shell existed as an issue since 2013 and was not discovered until 8 years later (2021)

and was patched within 5 days

donovan_dmc said:
shellshock existed for 2 decades before being discovered

and was patched within 12 days

Patched in x days of discovery; the longer a vulnerability has been out in the wild, the more chances bad actors already took advantage of it before cybersecurity teams found & fixed it. As I've already said, Flash & Ruffle isn't getting vulnerability detection help from any corporations or the government, so a bad actor that discovered an exploit could play the long-con & create/modify Flash files to take advantage & gain access for as long as they want before it's discovered or they move on the the next stage of their plan. We aren't facilitating that by accepting new Flash files.

"It was patched only a couple days later" - it damn well better have been. That's not a point in their favor, that's a baseline necessity. I'll also remind you updates don't propagate through magic and pixie dust; it's very possible these vulnerabilities persisted for months.

You might be right in your apparent opinion that we're being overly secure. However, it's abundantly clear to me you are being overly blase

tokwas said:
Flash is known for zero day exploits. Ruffle is not. Ruffle has nothing in common with the original Flash player apart from playing the same files. They share no code. They aren't even written in the same programming language. But even if Ruffle is as vulnerable as you all say -- and given that it's written in Rust, a programming language widely known for forcing the programmer to write code that is resilient to common memory safety vulnerabilities that form the basis for 99% of exploits, I don't believe it is -- the browser would have to be equally vulnerable for that to mean anything, and if that were true, we'd be seeing people getting zero-clicked by malicious webpages left and right. Nobody uses Ruffle, that I'll grant you, but millions of people use Firefox, and billions use Chrome. That's where the vulnerability would have to be. Again, if these vulnerabilities exist, why aren't people exploiting them?

Again, you have no guarantee that users aren't downloading & opening the file on their computer, and you have no guarantee that users aren't using OG native Flash Player. "But they'd have to download it, & Ruffle-" You are again making ill-informed assumptions. Firstly, until doing research for my initial response, I had no idea Ruffle had a desktop app, & I bet I'm not alone in that. Secondly, there are apps that convert Flash files into desktop apps (be it through a webview or whatever; idk & idc); how sure can you be that they're secure? Thirdly, you're assuming users aren't running a computer that already has OG Flash Player installed. My computer has OG Flash Player, why would I even think of checking for a safer alternative?

tokwas said:
And again, e621 is an infinitesimally small target... who would bother to attack us for so little reward?

I'm not reiterating the concept of an exploit chain; stop assuming they can only gain access to the site it's hosted on, & stop assuming they can only do so while the malicious file is in access. With iframes, you can redirect to a malicious wrapper around the actual site to continually inject whatever code you want, or you could take a page out of a single-page app's playbook & just pretend to change pages while simply dispatching the request & replacing the HTML with the requested page's while preserving your malicious code.

This only seems 100% fine if you make multiple, baseless assumptions about other users intelligence, knowledge, setups, etc. You have no way of knowing that. You are more than welcome to take your own risks; I 100% support that right & take some similar risks myself. We are well within our rights to avoid those risks. I will say this one final time: you cannot be confident users will not use legacy software to access legacy content, and for the foreseeable future, we are not allowing new content targeting that legacy format to prevent putting users at risk from malware exploiting unpatched vulnerabilities. As time goes on, Flash is less and less relevant, & it becomes less and less worth it to allow more Flash content.

I hope I've illustrated that there are valid concerns here, regardless of how unlikely they are to come true (and for some they are very likely); I don't wanna sound dismissive, but this is not happening anytime soon.

We've made our decision, & we aren't changing it. We are not allowing new Flash uploads. We initially allowed it for animations due to the lack of a native HTML player. We have that now, and you can (& should) just rip the raw files & upload them where possible. I'm very aware of the fact many games & interactive animations were submitted afterwards, & I'm sympathetic, but we're not a site for hosting games. Even if we were, we'd still just add support for HTML5 games rather than reintroduce Flash uploads; more freedom, more well-supported, more creator-friendly, more user-friendly, the list goes on. If we allowed interactive media, how much time would it take for janitors to review those posts? It's just problems on top of problems. The only reason we maintain old Flash uploads is for archival purposes, the exact same reason as grandfathered content. Just like we aren't letting people upload things that don't fit our current rules but would fit those grandfathered rules, we aren't letting people upload legacy executables to this art site, especially when you need a third-party extension/application to even view them.

so much of my favourite furry content was the flash games.

If there is no problem with existing files because you can't run them without extensive effort, then there is no problem with new files for the SAME REASON.
The ability to upload flash files is not the same as the ability to upload NEW flash files. If OLD flash files "likely" don't have any exploits, then it's fine to upload them. Pretty trivial to see if a file is old(and I don't just mean trusting meta-data, it's EZ to hash-check against files of similar names found via search engine), just set the cut off to 2020, Flash had updates 'til the end of 2020.
and while we're on the topic of "likely", let's keep going with the fact that it's UNLIKELY that any new flash files have any exploits, and if we're so wary about the possibility of exploits existing IN THE FUTURE then you probably shouldn't be using a computer at all, since you know any of the code you're using COULD BE EXPLOITED. You don't KNOW that any of the solutions you're using CAN'T be exploited, and it doesn't even matter whether it's being actively maintained or not since you're arguing from the perspective that actively maintained code can still have unfound vulnerabilities for decades. Flash player received patches for nearly 2 decades, it's UNLIKELY to be exploited at this time.

If Ruffle can't be trusted, then don't use it. You can prevent Flash files from loading in-browser at all if you want to, and only offer download links instead.
Even if you DO let them run, again you can prevent any redirects as swfchan had done forever, and any concerns about cookies are unfounded when it comes to Ruffle because as mentioned it does not have the same privileges as Flash had. It cannot hijack banking sessions because that would be cross-site and require a browser fault to allow. That's not on Ruffle, it's on the actively maintained widespread mainstream large company browser code. Flash was installed onto the operating system, not the browser.
I'll also throw in that Flash player wasn't canned because of security, it was canned because it made no money. They didn't fix it because it wasn't profitable, no one was using Flash anymore. It's not because it was impossible to make safer. You can always rewrite code to be better.

and since buddy above is so focused on chains... Well... Again... Why are you letting people connect to e6? You're hosting communications between users. That's just as bad as having a user's email address, and they can ask for an e-mail address here anyway. If you're so security-focused, then you should know that communications between users are a far larger vulnerability than anything in code.
and yeah, hosting DOS games would be chill, but I also understand games aren't in the same category. Allowing Flash doesn't have to be allowing interactive content, it can be animation-only.

Not sure where the HTML player comes into this, we still have no ability to upload any vector filetypes at this time.