3 ms·
Maybe what we need is a granular permissions model for all executables, including those in the terminal. Instead of the binary choice between "this code is allo
by _bxg1 6y ago
Maybe what we need is a granular permissions model for all executables, including those in the terminal. Instead of the binary choice between "this code is allowed to rewrite my operating system if it wants to" and "this code can 'only' read and write all of my user files", what if we had to explicitly give binaries access to specific directories? Network access? The desktop environment? Drawing to the screen anywhere outside of their designated windows?
IMO this is the real innovation of iOS: not simply locking everything down, but locking everything down by default and putting the user in control of where to release those valves. Catalina introduced a fairly ham-fisted version of this that doesn't work super well in practice, but I think they've got the right idea.
Improvement ideas for the Catalina model:
- A terminal interface. Right now if you run a program that tries to access Documents you get a pop-up. If you ran it from the terminal, why not get a terminal prompt, a la sudo?
- A central place to manage all of the permissions you've allowed and disallowed (this may already exist and I just don't know about it)
- No special status for folders like "Documents" and "Downloads"; a generalized way of specifying any arbitrary directory (recursive and non-recursive, maybe with patterns). For regular users there can be a simplified UI overlaid on top, while power-users could manage these directly.
- Separate read and write permissions for files and directories
Imagine if you ran all those NPM install scripts and they only had write permissions to their subdirectory of node_modules, only had read permissions to your path, and would dynamically prompt you if they had a reason to request something beyond that
EDIT: What if you could also designate certain programs as trusted "authorities" that can then automatically delegate these permissions to other programs? Running with the example, you could allow NPM to dole out narrow permissions to postinstall scripts as needed, coming back up to prompt you in unusual cases. This would hugely improve the user-experience issue and these "authorities" wouldn't really have any more power than they already do today.
- oneplane 6y agoThat does exist: we have ACLs, containers (no, not docker, but the filesystem views and isolation in macOS - and to some extent windows), chroot etc. Beyond that there are systems like AppArmor and SELinux on the Linux side of things. Problems with all of those: it becomes too much overhead and the additional moving parts create additional places for things to break (and they do break - even in a preconfigured distro).
- _bxg1 6y agoAnd this is what Apple has always been best at: taking technologies that already can work and making them into a product that does work, without hassle, for most people.
- mason55 6y agoIMO there are two problems. The first is that no one actually wants to manage that kind of access. Especially not your every day computer user. The second, related, problem is that if every app is asking you to review 20 permissions, people are going to stop reading the list and blindly accept. Or at least the people who need the guardrails the most will blindly accept. For all the crazy granular permissions I just don't see a way for it to work other than a source like Apple doing the review, saying that this app is trying to read your documents for no reason and so it's rejected. But now you're back to all apps going through the app store sandbox.
- _bxg1 6y agoA highly-granular system can be organized under a simplified, streamlined, user-friendly interface. I fully believe that this could be made to work well.
- auggierose 6y agoAnd the end result would be Catalina ;-)
- saagarjha 6y ago> Imagine if you ran all those NPM install scripts and they only had write permissions to their subdirectory of node_modules, only had read permissions to your path, and would dynamically prompt you if they had a reason to request something beyond that This sounds entirely possible to do within the existing macOS sandboxing framework.