[microtonal]

It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks.

What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. Most desktop apps probably have a good number of security vulnerabilities that can be exploited when they parse untrusted data. On the Linux desktop, most apps still use decades-old C libraries for parsing XML, images, JSON, etc.

Sandboxing also protects against external attacks.

Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.

Agreed, though for a lot of technical and social reasons, most apps still need privileges that allow trivial sandbox escapes on Flatpak (I don't know or care about Snap). Strengthening app sandboxing should be a top-priority for the Linux desktop, but only a few people seem to care. The same for fully verified boot, etc. Even things like UKIs only go so far, yet almost no distribution has adopted them.

The general security mindset of the Linux desktop community seems to be stuck in the 90ies, levitating between hahah, they cannot get root (as if that matters on desktop Linux) and secure boot and sandboxing is here to take my rights (on open source desktop Linux, seriously?).

[necovek]

I think you are mistaken. Just like neither Windows nor MacOS have really solved the desktop app sandboxing story, so neither has Linux.

Because, as I said in a sibling comment and cosmic_cheese notes further below, this requires rethinking the usage model altogether: files and folders, and even file types, don't work anymore.

If an app needs to access any related files, it basically needs access to my entire $HOME, and once that is granted, well, any sandboxing is out the window.

I think Linux community is well aware of that, and basically what we get from sandboxing of desktop apps is all the nuisance with no benefit.

Android model is also broken from a usage perspective: having files "owned" by an app is just as wrong, and precludes there being multiple apps operating on the same file. Example of VLC with subtitles is a common one, but if you've never used multiple apps on the same file, this is the challenge that is unsolved by any sandboxing approach today, because it is more of a UX problem, than a sandboxing technical problem.

[microtonal]

I don't fully agree with cosmic_cheese's comment. If we take music as an example, you could put your music in a Music folder and open that folder using your music player/manager and that folder gets added to your sandbox. This is how macOS sandboxing works and it works fine. Moreover, you can protect certain directories by default, even for unsandboxed apps, as e.g. macOS does, where a random app that is not sandboxed cannot read your Mail, address book, documents folder, etc. unless you allow this.

All these things make security substantially better than the Linux model of every app gets access to your full home directory.

Sure, a capabilities-based OS or whatnot would work better, but would even be harder to implement in the current desktop Linux. Instead of gradually improving security, you are basically throwing away the baby with the bathwater.

[necovek]

You get exactly that with snaps/flatpaks which are not given access to your $HOME.

But even with your example, you might need access to cover art from your graphics editing app, and very quickly you get to the same state. How about lyrics file from your text editor or a dedicated one? And wait, I'd like to mix in some music into Audacity too. File portals are actually a decent solution there, but they only work for files with supported software.

Yes, you can adapt your workflow, but it's going to be adapting and you will lose some things you might love in your workflow.

[iggldiggl]

> What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside.

The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.)

So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…?

Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.

[cosmic_cheese]

I think had the problem is that the toolbox we can deploy to solve these problems is so empty.

For example, it’s useful for a music player with metadata editing features to have read/write access to the whole filesystem, but that constitutes a significant risk since all we can do is wholesale allow or prevent access to the whole filesystem. What if the system could allow it to access only music files, though? That’d scope the risk back down to almost nothing while also allowing the music player to do its job.

This is the kind of thing I’ve been getting at in the other replies. Nobody has really sat down and given system level security controls a deep rethink.

[iggldiggl]

I think Apple's implementation in macOS is the only one that offers some slightly more advanced features, but even those don't get you that far

(Some sort of way to store permission references with relatives paths in a file, but which most probably wouldn't work with files being exchanged cross-platform, and other than that mainly being able to get automatic access to 'related' files, i.e. same file name, but a differing extension – that solves some sidecar files, like video subtitles, or certain kinds of georeferenced images, but large capability gaps still remain – even the video subtitle example stops working if the file name is no longer 100 % the same, like if you have multiple subtitle files for differing languages, where VLC for example supports prefix-matching the video file name with the subtitle files.)

And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.

[cosmic_cheese]

> And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.

I could very well be wrong, but my inclination is that it's possible, but it's going to take the sort of fundamentals R&D that desktop operating systems haven't seen in decades. It can't just be tacked on, everything to be designed with this new system in mind.

[palata]

Agreed. I want to "own my device" as in "being able to install the system I want on it". Not as in "I want it to behave exactly like Desktop Linux", or whatever it is that people complain about AOSP.

On my Desktop I love Linux. But on my smartphone, I want AOSP.

[microtonal]

Largely agreed, though I think on the desktop I’d also want AOSP in desktop mode with a traditional Linux distribution in a VM pretty much like Android 16’s Linux VM.

But then on desktop/laptop-class hardware, since the thermal constraints are different and it’s nice to have extensible storage and RAM. Of course, all this on the phone is also nice for when you only have your phone with you.

Then one could use fully sandboxed apps for banks, instant messaging, etc. and the VM for development.

AOSP is getting pretty close to this ideal.

[palata]

> AOSP is getting pretty close to this ideal.

Yes I can totally imagine that in a few years, most people will only need a smartphone and a dock station. At home, they will plug their phone (iOS, Android, whatever) to their dock station and it will behave as a Desktop. And it will be good enough for everything they do.