Mobile platforms are far more secure than desktop computing software. I'd rather do internet banking on my phone than on my computer. You should too.

We can make operating systems where the islands can interact. Its just needs to be opt in instead of opt out. A bad Notepad++ update shouldn't be able to invisibly read all of thunderbird's stored emails, or add backdoors to projects I'm working on or cryptolocker my documents. At least not without my say so.

I get that permission prompts are annoying. There are some ways to do the UI aspect in a better way - like have the open file dialogue box automatically pass along permissions to the opened file. But these are the minority of cases. Most programs only need to access to their own stuff. Having an OS confirmation for the few applications that need to escape their island would be a much better default. Still allow all the software we use today, but block a great many of these attacks.

There is a middle ground (maybe even closer to more limited OS design principles) exist. It is not just toys. Otherwise neither UWP on Windows nor Flatpaks or Firejail would exist nor systemd would implement containerization features.

In such a scenario, you can launch your IDE from your application manager and then only give write access to specific folders for a project. The IDE's configuration files can also be stored in isolated directories. You can still access them with your file manager software or your terminal app which are "special" and need to be approved by you once (or for each update) as special. You may think "How do I even share my secrets like Git SSH keys?". Well that's why we need services like the SSH Agent or Freedesktop secret-storage-spec. Windows already has this btw as the secret vaults. They are there since at least Windows 7 maybe even Vista.

If a sandbox is optional then it is not really a good sandbox

naturally even flatpak on Linux suffers from this as legacy software simply doesn’t have a concept of permission models and this cannot be bolted on after the fact

Residents of San Francisco ask themselves that question all the time.

The backdoors snuck in because literally everyone is being targeted. Few people ever see the impact of that themselves or understand the chain of events that brought those impacts about.

The XDG portal standards being developed to provide permissions to apps (and allow users to manage them), including those installed via Flatpak, will continue to be useful if and when the sandboxing security of Flatpaks are improved. (In fact, having the frontend management part in place is kind of a prerequisite to really enforcing a lot of restrictions on apps, lest they just stop working suddenly.)

Doesn't it use bwrap under the hood? what's wrong with that?

I assumed the primary feature of Flatpak was to make a “universal” package across all Linux platforms. The security side of things seems to be a secondary consideration. I assume that the security aspect is now a much higher priority.

I would configure mailman with permanent write access to the mailbox area

That's what I with my sandbox right now

The original model of computer security is "anything running on the machine can do and touch anything it wants to".

A slightly more advanced model, which is the default for OSes today, is to have a notion of a "user", and then you grant certain permissions to a user. For example, for something like Unix, you have the read/write/execute permissions on files that differ for each user. The security mentioned above just involves defining more such permissions than were historically provided by Unix.

But the holy grail of security models is called "capability-based security", which is above and beyond what any current popular OS provides. Rather than the current model which just involves talking about what a process can do (the verbs of the system), a capability involves taking about what a process can do an operation on (the nouns of the system). A "capability" is an unforgeable cryptographic token, managed by the OS itself (sort of like how a typical OS tracks file handles), which grants access to a certain object.

Crucially, this then allows processes to delegate tasks to other processes in a secure way. Because tokens are cryptographically unforgeable, the only way that a process could have possibly gotten the permission to operate on a resource is if it were delegated that permission by some other process. And when delegating, processes can further lock down a capability, e.g. by turning it from read/write to read-only, or they can e.g. completely give up a capability and pass ownership to the other process, etc.

https://en.wikipedia.org/wiki/Capability-based_security

A capability model wouldn't have prevented the compromised binary from being installed, but it would totally prevent that compromised binary from being able to read or write to any specific file (or any other system resource) that Notepad++ wouldn't have ordinarily had access to.

No, it's not.

If vim were good enough, neovim wouldn't exist. If neovim were that much better, vim wouldn't still be as popular as it is. And if neither of them did anything worth picking up, then vi would still outrank them.

The conclusion is that they don't do the same things. They just both have the vi interface. But having a vi interface isn't particularly weird anymore. SublimeText and vscode have vi bindings. So does PyCharm/IntelliJ. So does Notepad++! Heck, so does nano! So who gets to claim those editors? Vscode is the most popular editor that supports a vi-like interface. Shouldn't that mean that vscode is the best of the "vi descendants"? Or does it mean that all these people were okay with the vi interface, but had a good reason not to make the choice they did for another editor?

Fundamentally, the issue is: Either choice matters, or popularity doesn't matter. You can't have it both ways.

I love and hate it at the same time, just like my browser tabs hoarding, it means I currently have 218 open documents on Notepad++ (and 96 browser tabs). I might not even need them anymore, but it's always "I'll look at them... later".