Anyway, you have no reason to be afraid. All mayor browsers are dropping support for plugins anyway. An open source flash player will most likely be used standalone, and not in a browser.
(I can't help but wonder if we are making a huge historical mistake here by the way. Because the Flash implementation was so bad, we were led to believe that plugins are bad per se. But at least in theory, it seems to me that the best architecture would be a minimal browser (just a layout engine), and everything as a plugin. Current browser are horrible monolithic giants, that only mega-corporations (and Mozilla ;-)) can maintain. That they are relatively secure is only due to the massive amounts of human-years that went into polishing and bug fixing in the recent decade.)
Plugins aren't inherently Linux-incompatible it's just that for most of them Linux support was an afterthought or actively avoided for competitive reasons (in the case of Silverlight, I would guess). I don't miss fighting to make Flash work in a 64-bit browser, or having to set my user agent to claim I'm on Windows, to make something work (and have it break periodically for whatever reason).
In theory we could create a basic browser with various HTML/JS/CSS spec features created as a plugin
Open source plugins cause a lot less grief. Typically they don't have a feature I want. Often for legal reasons and not technical, or because a proprietary vendor is fighting back (eg; video patents the first case, Skype protocol the second).
The linux kernel is an example how an open-source-only plugin system works technical wonders. A very interesting case study was graphics drivers circa 2005. The closed source drivers (essentially plugins) tethered the linux community to the technically obsolete X server; and would have crippled the kernel in a similar way if the kernel devs had accepted closed source plugins.
Apple did wonders driving open standards on the web with the explicit acknowledgement that popular closed source plugins were too dangerous for their platform to implement .
The issue here is the one Stallman has been harping on since the dawn of time - closed source is unmaintainable in an extremely profound way.
If you need some native feature, browser vendors can force you to use a native app and thus go through their app store (think Safari on iOS). There is a large category of apps that you cannot make in HTML, for example anything truly P2P (not WebRTC, but based on real sockets). You can't make an IMAP client. You can't make a friend-to-friend file sharing tool, without a central server, that uses your Facebook and Google contacts to find peers (I've tried). You can't make the browser window partially-transparent or use native looking widgets. You can't burn a DVD. And if someone invents free-floating holograms, you can't add them to your page.
Granted, these examples are silly. The web is now a very capable platform. But vendors have always been steering what you can and cannot do based on business and other interests. It would be great to be able to break out of that, by having a kind of "C foreign function" interface for the web.
It is probably why we all have flat windows 3 inspired UIs now.
It'll most likely be modified to run in browsers, too, e.g., via compilation to WebAssembly and suitable web-platform replacements for the low-level IO, etc., implementations.
So the W3C would have to define "standard Flash specification" and then everyone would have to implement their own "Flash player". But ain't nobody got time for that.
If the "Flash player" had been a specification rather than a piece of standalone software from day one, I believe the overall security of the Flash players would have been way better.
If website.com embeds a flash file from flash.example, it will run in the context of flash.example, the embedee.
This will and has caused problems with interoperability in so far, as I'd call it an ugly and dangerous wart.
See web security literature like "The Tangled Web" (or https://code.google.com/archive/p/browsersec/wikis/Part2.wik...) for more.