Let's keep the sandbox as simple as possible. We can build complexity inside it, and not make complexity part of it. This makes security guarantees much simpler.
While technically, complexity is not necessary, pragmatically the sandbox offers next to nothing for users or developers without OS vendors enforcing its usage, or the sandbox being so compelling a target for developers they accept the limitations of the sandbox - which is why the only platforms with robust sandboxes are mobile and the browser.
Android gives lip service to the NDK, but in practice you can't really run many useful C/C++/Golang/Rust/etc programs on Android, because the system breaks POSIX. You can't keep a simple webserver running without starting a foreground service, which requires Java/Kotlin. There's no /etc/resolv.conf for DNS resolution, so you have to use custom servers or use the Android NDK compiler (which can be a huge pain). Plus they lock down the filesystem more each year. Android 10/11 are a complete mess on this front. Fortunately they've rolled back some of the more draconian changes, but only because of developer outcry. The fact that they even wanted to do some of the things in the first place is sad.
I'm not saying this is an easy problem to solve, but it's obvious that the big boys have only made a token (if that) effort to build a good, open way of doing it.
I don't know of a justification for removing /etc/resolv.conf, but I guess "applications' networking should be under the control of the user" is sorta necessary; I think it'd make more sense to do it with network namespaces or iptables rules or something, but /shrug.
I was thinking about that recently and my conclusion will be highly controversial.
In the same way Wayland implements security that X never could, I think the GUI might be a place to implement file and folder access permissions. If the user does not grant access to a file through a dialog, the app couldn't read it. Same for folder access, which would grant an application access to an entire folder or perhaps an entire hierarchy.
Obviously this would break some things, but real change may require some of that. How much, I don't know.
IIRC flatpak has something similar too, though I believe it’s opt-in for the apps.
That's a good thing. We should break "decades of convention in how to write POSIX-like applications" if we want to get any further than POSIX-like OSes and programming models...
https://developer.android.com/ndk/guides
> Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.
> Reuse your own or other developers' C or C++ libraries.
Writing POSIX CLI applications is not a goal.
ISO C and ISO C++, alongside OpenGL ES, Vulkan and OpenSL are more than enough to have something like Qt running.
That said, it's not:
(a) as if there aren't cross platform photo apps that run on iOS and "regular computers". Photoshop and Lightroom come to mind immediately, Affinity Photo also. And those aren't just iOS and Mac, they're also on Windows. So there's that.
(b) as if what would slow you down / prevent you from doing such a cross platform photo app would be the iOS capability / image access request feature.
the only thing in common between the mobile and desktop versions is the name
Linux is slowly moving toward capability-centric design with more and more comprehensive namespacing and file-descriptor-based interfaces to things like pidfd and memfd, but there's still a long way to go before we can jettison ambient authority such as the filesystem entirely. Meanwhile, Google's Fuchsia may deploy a capability-based operating system to the masses, but it will likely only be used to sandbox applications written for Android anyway. The real potential of capabilities is to simplify the interface of a power-user operating system by eliminating the race conditions, side channels, privacy leaks, firewalls, virus scanners, and unix-style permissions from developers' and users' day-to-day experience completely.
There will still be memory-safety zero days, of course, until we abandon languages where humans are statistically incapable of writing memory-safe code.
Fundamentally, sandboxes restrict the possible functionality of executable code to prevent it from violating some preconditions within the context a user invokes it. Rarely do developers desire that behavior (it makes it harder for your app to work!), and users complain about it too (when MacOS began requiring explicit permissions for many entitlements, many users complained about the constant nag screens). Browsers have historically needed to reinvent every wheel provided by operating systems to provide features developers require that can't work within the sandbox (cookies, websockets, etc) which prevented entire classes of application from existing.
Browsers have enormous business incentives behind them, I'm not sure why you think that ruins the idea. Google spends gobs of money to prevent anyone from developing a competing non-Google browser, for example. Apple bans any non-Apple browser from existence on iOS and iPadOS.
Replicating a significant fraction of the functionality of a browser ends up being a lot of code and data. For a web-like experience with instant navigation between apps it will be necessary for these shared libraries to be really shared, as in almost all apps use the same libraries and the same version of those libraries. Otherwise you'd be downloading and unpacking and JIT compiling dozens or hundreds of megabytes of code and data before you could display a single line of text, every time you click a link to a new site. The linkable nature of the web would be lost. (Yes, many websites are dozens of megabytes already, but the bulk of that is delay-loaded and happens in the background after the initial content is displayed).
In order for the standard libraries to be actually shared, everyone would have to agree on the standard libraries to use, and the standard libraries would have to be designed to be backwards compatible so that older sites could be force-upgraded to use newer versions. This is essentially the role that browser updates play today. But the browser evolved over decades and it's not clear how you'd get everyone to adopt a new set of standard libraries today, nor how you'd get everyone to agree on what functionality to add over time (the role that W3C plays today).
For libraries outside of the standard set, it sounds tempting to allow them to be shared too. But this is actually an unavoidable privacy violation. If you have a shared cache, then any app can discover the set of previously loaded libraries with a timing attack, thus revealing information about the user's browsing history. This is why all browsers are now moving to partition all caches by site: https://www.jefftk.com/p/shared-cache-is-going-away. Even if multiple sites reference the same wasm blob, it must be downloaded and JITed separately with no sharing.
As I said, I like the vision of a tiny low-level runtime executing shared libraries inside a sandbox. But I'm not sure how it could be done in an efficient and privacy-respecting way if you want to replace the Web with it.
I think we can expose standardised APIs to applications for this stuff, but the API will probably need on the order of hundreds of methods.
Speaking of moving complexity into sandboxed code, browsers could potentially run js engines inside the wasm vm, reducing a lot of complexity there.
You can compile existing GUI libraries you just need to port the rendering backend and input.
Flutter, Qt, GTK, etc.