Even Linux has had several: NeXTStep style Application Bundles in GNUStep, AppDirs in ROX filer, and AppImage today. They're just not over-engineered enough for the Linux Desktop community to embrace or something.
Portable app bundles are not the goal here. The goal is portable app bundles that the user can install from arbitrary sources on a whim without putting their OS at risk of malware or their data at risk of exfiltration.
Y’know, like on phones.
But also, since these designs aren’t for consumer electronics appliances with a central vendor, but rather are following the FOSS philosophy, you can’t just use a weak sandbox powered by nominal capability manifests signed by a central code-signer, where the app could do arbitrary things outside of its capabilities and the sandboxing wouldn’t catch it (i.e. the macOS approach.) Instead, you have to have a strong sandbox that will actually enforce the capability manifest to restrict what the app can do.
Oh, and the bundles can update by self-modifying their contents, creating new executable binaries in the process, so your sandbox can’t be based on signing the initial contents of the sandbox, but rather has to sandbox whatever is attempting to run in there right now.
If you can come up with a design that fits those criteria and is simpler than Snap or Flatpak, by all means, share.
This is not now nor will this ever be a thing. If you can run software on the host there will always be a way to compromise the host. It is not even 100% safe to run software in a vm because exploits have been found to break out.
Maintaining security on your phone requires the app store owner to invest time in proactively screening manually or automatically for malware or reactively removing it when found. It requires users to avoid stuff that looks like scammy bullshit or software from unofficial sources.
Both of these layers leak and when they do automated protections usually do as well because malware authors can easily test against existing protections, learn from one another, and distribute what works.
That's... inaccurate. More valid statements would be:
- In a sufficiently complex OS, it is unlikely you will be perfectly safe running untrusted executables even with reduced permissions.
- Popular modern OS desktop distributions are very complex out of the box.
- Sandboxing prevents certain classes of attacks effectively, but should not be relied upon as a sole line of defense.
- Vulnerabilities have been found in VMs and containers, but they afford greater protection and isolation than running a process directly on a host system.
IOW, don't go No-True-Scotsman on security. A vulnerability does not invalidate all benefits of an architecture.
So a well packaged app utilising SELinux|AppArmor profiles?
This condescending idea that users can't be trusted to determine this stuff for themselves and therefore we need a centralized signer and a bunch of complicated management framework to deal with it is part of the reason the FOSS philosophy has yet to produce a desktop anyone cares about.
Your argument, by analogy, is “you should trust people to know not to sleep with people with STDs.” Well, you know what? Some people want to sleep with people with STDs. Sometimes those are their significant others. They still don’t want to catch something.
In both cases, the answer is the same: a condom.
A sandboxed App Store is, basically, a brothel where condom use is enforced. You can meet strange apps, play with them, and not worry about it. Because of the brothel’s policy, nobody the brothel hosts is risky. Your safety is enforced at the level of choosing the source.
Whereas something like Ubuntu’s PPAs, are more like a bar. Who knows what you’ll catch? Any individual app might decide to “wrap it up” with SELinux/AppArmor, but you can’t enforce it at the app-store level.
(Also, completely dropping the metaphor: the iOS App Store is frequently exposed—at least for free purchases—to children or even infants. This is actually a capability people want. This is certainly not a case where the user can determine for themselves whether an app is trustworthy.)