Flash used some unusual methods of authorizing network access (like crossdomain.xml [1]) which are significantly different from standardized HTTP cross-domain policies, and which can authorize some forms of network activity which are never otherwise permitted to web content (like connecting to arbitrary ports and transmitting arbitrary data, or sending HTTP requests with forged headers).

[1]: https://www.adobe.com/devnet/articles/crossdomain_policy_fil...

Worst case, you can use a helper server... The flash content tries to do an HTTP request, the container intercepts that, sends it to a proxy somewhere on the web, which does the request and pipes the response back.

Sure, someone has to run that proxy, but I'm sure flash games sites wouldn't have trouble doing so.

Flash sockets don't transport HTTP requests. You might be able to tunnel them through WebSockets, but that'd turn the "helper server" into what would amount to an open network proxy -- it'd be trivial to abuse.

It's kind of a moot point, though; I doubt that the networking servers that these games depended on are still online. That's a whole separate preservation problem.

No need to make it an open server. For applications that require a limited number of resources, you can implement a whitelist--only allow connections to certain IPs or addresses. Inspect the connections if you have to. For everything else? Make the user run it locally, have your runtime try to connect to a local instance before connecting to a remote instance.

Alternatively, figure out a way to ship remote dependencies alongside the swf file, and define a patch format that allows replacing network requests.

All of this is more work to do, but all of it is also workable solutions.

The worst part of that preservation problem is, that as a DRM measure, some games will "phone home" to download a swf component that implements some critical path of the game. If the server goes down, those games are dead in the water unless you can reimplement the missing pieces.

Why was this ever allowed to be a browser plugin

Because people wanted it and nobody thought too hard about it at the time.

because the web sucked in terms of functionality then, especially as an application delivery medium.

There is a parallel universe somewhere where Javascript was designed as a Turing incomplete basic interactivity template and now node runs ECMAFlash2019

Ain't this because crosdsomain.xml came before CORS?

Partially yes. Partially because the developers at Adobe didn't fully think through the implications of their "XML sockets".

I'm sure there's a more scientific explanation involving cognitive bias and rationality and so on, but all I know is that few phrases send more chills down more spines of experienced developers than "it should be easy, why don't you just..." It's up there with "ship it now, we'll fix it later" and "if we can't agree which way to go, let's just make it an option in the prefs" on the Mount Rushmore of famous last words in software development. I've been burned by it so many times, I literally have to catch myself when I hear those words coming out of my mouth (or anyone's mouth, but I can only be responsible for myself), which they still do sometimes, because I'm just as subject to human nature and cognitive bias as anyone.

Hey now, the preferences panels of yore were glorious outposts of customization and power-user-centric software. Computing was way more fun back then. Don't lump anti-option sentiment in with those other, far more worrisome things.

That approach to preferences tends to cause combinatorial explosions in your QA department. You can do it if you're careful, but being careful is the opposite of the "then just make it a preference" approach.

I'm not against preferences and lots of options in general when appropriate, I just don't think they're zero-cost. It's like the surprisingly huge difference between a service being "free" vs. "almost free". But anecdotally (I know...) when fundamental differences between developers are resolved as, "let's just do both and make it an option", it's either people assuming that allowing both behaviors either has no cost, or it's a failure to resolve differences that inflicts one of the thousand tiny cuts that will someday overwhelm the code base.

At the same time, I don't want to be dogmatic about anything, those are just general tendencies. Emacs for example is a beautiful example of an almost opposite design. The software is like a computing instrument that the user has to first learn how to play, but the more effort they put in to it, (up to a point at least, and depending on what they want to do) the more they get out of it. Ultimately it depends on what you're trying to accomplish and who your users are.

My /favorite/ is "ship it now, we'll fix it later" or "do it this way now and we will come back and do the better way later" and then never going back.

I've watched a few products "grow" using this method then project managers be surprised when down the line it's all held together with duct tape and chewing gum and a "simple" change is a week of work. There have been a number of times in my past where I have purposefully not suggested or the team decided not to bring up an "option" because we knew it would be abused.

"why don't you just" is called out in Evan's "The hard parts of open source" [0] talk.

He goes into some of the reasons it's a bad phrase and some of the problems behind it. I'd recommend the talk.

[0]: https://www.youtube.com/watch?v=o_4EX4dPppA

Well, "why not just..." is only bad if it's rhetorical; sometimes it's a genuine question: "why not just?"; there usually is a reason, and it's important to find out what that reason is, rather than repeat someone else's mistakes.

But this is right question. It should be easy to replace part of the binary, it should be easy to run several programs at the same time, it should be easy to type on keyboard so computer executes commands.

These are insanely hard problems yet they are solved because someone asked and someone tried.

And what adjustment should you do when it makes a request to, for example, ` https://mms.cnn.com/aaldXQhJ0VycCFqfnQhcGp1fkojSDwxbG5ueiJ5I... `?

Why should you need to do any adjustment? Web browsers allow such requests by default.

User-adjustable restrictions work for only a small fraction of the population. That fraction gets smaller the more fine-grained you make them.

I don’t see the problem here, just have reasonable defaults. (e.g. port 80,443, perhaps deny private networks by default)

Oh, it is easy - just bundle server together with application. The same way we bundle static dependencies (resource files).

For that you need server snapshot, that should be easy - just require it (maybe with source) to be provided with each application that use network. But some servers aggregate data from several users.

That's easy too - require it to be possible to deploy by user on some generalized network architecture.

So technically it is easy, but as society we select other priorities. Personal gain, time to deploy versus stable platform and culture preservation. It is not impossible - early internet was non profit only.

We have same conversation again and again - The Right to Repair, Internet Archive, Open Source. Flash was part of that rhetoric too - that's why it is so polarized. Brilliant tool, so much creativity and yet closed source, poorly supported, bug ridden. It was a public stance - if Flash become standard it would be new IE once again.