zlacker

>>natebc+(OP)
I am running a lot of tools inside sandbox now for exactly this reason. The damage is confined to the directory I'm running that tool in.

There is no reason for a tool to implicitly access my mounted cloud drive directory and browser cookies data.

>>ashish+q9
I almost feel like this should just be the default action for all applications. I don't need them to escape out of a defined root. It's almost like your documents and application are effectively locked together. You have to give permissions for an app to extra data from outside of the sandbox.

Linux has this capability, of course. And it seems like MacOS prompts me a lot for "such and such application wants to access this or that". But I think it could be a lot more fine-grained, personally.

>>taftst+qa
I've been arguing for this for years. There's no reason every random binary should have unfettered, invisible access to everything on my computer as if it were me.

iOS and Android both implement these security policies correctly. Why can't desktop operating systems?

>>joseph+hb
Windows has had this for over a decade, but no one wants to put their application in a sandbox.

>>IcyWin+Cl
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

>>akdev1+zm
The containers are literally the "bolting on". You need to give the illusion of the software is running under a full OS but you can actually mount the system directories as read-only.

>>okanat+Bn
and you still need to mount volumes and add all sorts of holes in the sandbox for applications to work correctly and/or be useful

try to run gimp inside a container for example, you’ll have to give access to your ~/Pictures or whatever for it to be useful

Compared to some photo editing applications on android/iOS which can work without having filesystem access by getting the file through the OS file picker