4 ms·

An interactive sandbox UX I like a lot is an app giving me a dialog "Allow", "Deny" with an additional "Remember" button when it does something new (perhaps mod

An interactive sandbox UX I like a lot is an app giving me a dialog "Allow", "Deny" with an additional "Remember" button when it does something new (perhaps modulo some time window, as long as it's clear). In certain situations I'd like to be more granular than that, but it would be much better than what we have today. A good way to be more granular is an "Advanced" button that lets you drill down more specifically depending on the resource that is being attempted to access. Today if I want to send someone a photo I took on <insert newfangled application that can send messages here> I need to grant it permissions to read all of my storage. That's dumb. The OS should delegate access in such a way that I can give the app access to a single file's contents AND be performant/not get in the way for accessing all files if that's what I prefer. What should NOT be possible is an app asking "hey can I read '/*'?". It should attempt to access specific resources in the namespace, and the OS should be responsible for saying "should this app bug you again about reading your <namespace>?" This gives an only-slightly-more complex UX to users that don't know/care, and gives a lot of flexibility to those that do. I'd even be fine if it was one-time opt-in like Android "developer mode" which is basically impossible to enable if you're not looking for it.

detaro 7y ago
As an example, Flatpak has "portals" for e.g. file access, which mirror how this works on mobile OSes. The app asks the environment to let the user pick a file, then the file gets mapped into its sandbox.
ajsnigrutin 7y ago
> Today if I want to send someone a photo I took on <insert newfangled application that can send messages here> I need to grant it permissions to read all of my storage Yes > That's dumb In that context, yes. But: > An interactive sandbox UX I like a lot is an app giving me a dialog "Allow", "Deny" with an additional "Remember" button Everytime you'd want to access any file (eg. upload a saved photo to instagram), you'd get a permissions prompt, and everybody clicks "allow all" after the second time. The workaround is to have the app ask the trusted OS module to open the file selector, and the user then selects the file, and the app only gets access to that one file. This works for instagram for example. ...but! This doesnt work for file browser apps, file synchronisation apps, backup apps, etc. This also doesn't work with instagram, which offers to upload the last photo taken when you select photo (instead of camera), because it doesn't have permission to load it, and that means an additional step just to select the photo. If you want instagram photos to be saved to your device storage, instagram either needs permission to write to some folder, or it has to ask the os (and then user) where to save the photo every time. If you want security, features and user friendliness, you're basicaly fscked
AshamedCaptain 7y ago
But how does this interact with Unix command line tools? Any "sandboxing" system that A) either makes comamnd line usage inconvenient or B) completely ignore command line usage is going to create a rift. Most of these "interactive sandbox UX" approaches basically create a "developer sandbox" where the command line tools can all play together but cannot access external data. And this is where things go downhill. Developers (or even users) DO want from time to time to write a script that accesses their contacts, gets the current GPS position and then does some munching with Perl for whatever obscure reason. Developers DO want from time to time to read whatever stuff Netflix program is storing on their private storage (oh noes!), or what the PDF reading program wants to send to the net. And then you hit either A or B from above. If A, developer is annoyed and disables your sandboxing, and you are back to stage 1. If B, you are already at stage 1 and developer is annoyed seeing that random Perl scripts can apparently read your contacts list. I find that any sandboxing approach that fails to actually think of command line usage is just falling in the trap of the "Android/iOS-centric world view". "Apps" may be glorified websites which are trivial to sandbox, but the more generic concept of "programs" is not. This is not only about command line scripts. Command line scripts interact with pipes. Programs, however, interact between themselves in ways we cannot even think of right now. Which is why year after year you still see completely unsandboxed PCs being used for "productivity" despite tablets and anything else with the Android/iOS model.
- XorNot 7y ago
  The problem with sandboxing is it only works for server processes with very narrow behaviors - it's completely unable to express broad ideas. My file browser should be able to see my whole system - that's what I want it to do. But I really don't want it to scoop up a list of files on my system, and send it wholesale to a network address I didn't type in specifically, after some specific actions. AFAIK no security mechanism anyone currently proposes properly captures this sort of intent: there isn't a firewall which defines what can be done with the actual bytes of data an application has picked up in those terms - when they're in memory. Of course this is a huge challenge: proving that my file browser doesn't have a way to, without gating through a user system, transform my file list into any code paths which can send it via network traffic. But it's what we desperately need.

detaro 7y ago

As an example, Flatpak has "portals" for e.g. file access, which mirror how this works on mobile OSes. The app asks the environment to let the user pick a file, then the file gets mapped into its sandbox.

ajsnigrutin 7y ago

> Today if I want to send someone a photo I took on <insert newfangled application that can send messages here> I need to grant it permissions to read all of my storage Yes > That's dumb In that context, yes. But: > An interactive sandbox UX I like a lot is an app giving me a dialog "Allow", "Deny" with an additional "Remember" button Everytime you'd want to access any file (eg. upload a saved photo to instagram), you'd get a permissions prompt, and everybody clicks "allow all" after the second time. The workaround is to have the app ask the trusted OS module to open the file selector, and the user then selects the file, and the app only gets access to that one file. This works for instagram for example. ...but! This doesnt work for file browser apps, file synchronisation apps, backup apps, etc. This also doesn't work with instagram, which offers to upload the last photo taken when you select photo (instead of camera), because it doesn't have permission to load it, and that means an additional step just to select the photo. If you want instagram photos to be saved to your device storage, instagram either needs permission to write to some folder, or it has to ask the os (and then user) where to save the photo every time. If you want security, features and user friendliness, you're basicaly fscked

AshamedCaptain 7y ago

But how does this interact with Unix command line tools? Any "sandboxing" system that A) either makes comamnd line usage inconvenient or B) completely ignore command line usage is going to create a rift. Most of these "interactive sandbox UX" approaches basically create a "developer sandbox" where the command line tools can all play together but cannot access external data. And this is where things go downhill. Developers (or even users) DO want from time to time to write a script that accesses their contacts, gets the current GPS position and then does some munching with Perl for whatever obscure reason. Developers DO want from time to time to read whatever stuff Netflix program is storing on their private storage (oh noes!), or what the PDF reading program wants to send to the net. And then you hit either A or B from above. If A, developer is annoyed and disables your sandboxing, and you are back to stage 1. If B, you are already at stage 1 and developer is annoyed seeing that random Perl scripts can apparently read your contacts list. I find that any sandboxing approach that fails to actually think of command line usage is just falling in the trap of the "Android/iOS-centric world view". "Apps" may be glorified websites which are trivial to sandbox, but the more generic concept of "programs" is not. This is not only about command line scripts. Command line scripts interact with pipes. Programs, however, interact between themselves in ways we cannot even think of right now. Which is why year after year you still see completely unsandboxed PCs being used for "productivity" despite tablets and anything else with the Android/iOS model.

XorNot 7y ago
The problem with sandboxing is it only works for server processes with very narrow behaviors - it's completely unable to express broad ideas. My file browser should be able to see my whole system - that's what I want it to do. But I really don't want it to scoop up a list of files on my system, and send it wholesale to a network address I didn't type in specifically, after some specific actions. AFAIK no security mechanism anyone currently proposes properly captures this sort of intent: there isn't a firewall which defines what can be done with the actual bytes of data an application has picked up in those terms - when they're in memory. Of course this is a huge challenge: proving that my file browser doesn't have a way to, without gating through a user system, transform my file list into any code paths which can send it via network traffic. But it's what we desperately need.