[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.