This works for some type of software, but not all type of software. For example a file server or a file manager wont work. A VCS client wont work. A game engine that needs to keep track of imported resources (especially when you want automatic imports when the file is saved via a 3rd party tool - e.g. saving a model on Blender or a texture on Krita causes an automatic reimport/convert to the engine's format). Basically any sort of content management software that doesn't provide everything itself but relies on 3rd party tools already installed on the user's machine wont work.
Software like clipboard managers also wont work. Screen sharing and remote desktop software similarly wont work. Screencast software wont work. Hotkeys software wont work. Most desktop automation software wont work.
I could go on and start looking at what i have installed to extend this list (i'm sure most of the software i have on my PC wont work), but i guess you get the idea. Almost everything that doesn't fit in the media consumption model that you'll often find on a phone or a tablet wont work (and amusingly enough, at least on my Android, stuff like a file server does work, though i've heard Google wants to remove that functionality).
It is possible to still make all of these work by having frameworks that hold the permission to access the functionality, or by having entitlements to more tightly restrict which applications have access to a feature.
For example, some backgrounding modes on iOS require an app to get an entitlement to act as a VOIP client, or a mapping directions app. The system access is limited to only give access to the things which a VOIP client or map should need in the background.
On iOS, ReplayKit allows apps to participate in screen casting - both with first party support for an app being cast, and for an app which wants to share a video stream out.
Screen sharing on macOS also will likely move to ReplayKit, but it currently requires the user to approve a request to share the screen.
You can open a 'folder' rather than individual files to gain access to a full project structure.
Clipboard managers are difficult in a sandbox model where the clipboard manager has no permission to stay running in the background. Similar applications like custom keyboards on iOS solved this by having a smaller 'extension' stay resident, and having that extension run with a very restricted set of permissions. For instance, no access to shared storage, IPC, or to the network. A keyboard must work without these permissions to get in the App Store, but they may prompt the user to elevate permissions.
> It is possible to still make all of these work by having frameworks that hold the permission to access the functionality, or by having entitlements to more tightly restrict which applications have access to a feature.
I agree with this, but I can't fully get on board with it.
I've worried about the lax security model of desktop software too. Apps these days need to ask permission before accessing my documents, or my desktop, or my downloads folder, but they can still access all my company's code and SSH private keys. It feels wrong for this to be open-by-default. Same with accessing the clipboard, or drawing on the screen, or changing system settings, or injecting code into the Finder: these all seem like things I want to opt in to doing.
But my problem with this — and it's a stretch, I know — is that if the only extra entitlements a program can have are the ones that Apple explicitly allows, then no developer can have any ideas outside of what's already been thought up. As we increase security, we also dry up the innovation well.
For example, there's a Finder API that allows you to add badges to files in a directory to reflect their syncing status. This is an API that Apple allows apps to use — but it was originally implemented by Dropbox, which injected code into the Finder. They had the idea, and the idea turned into a general API.[1] (Now that I think about it, there's almost certainly prior art to this, but Dropbox was where I first saw it)
Similarly, I use a whole bunch of background utilities that currently use the "Screen Recording" or "Accessibility" Privacy permission on macOS, even if they aren't screen recorders or accessibility helpers: things like letting me move windows by holding Option, or switching apps by using the keyboard, or a Spotlight replacement, or adding a delay to ⌘Q, or the snippet manager I just used to insert the '⌘' character there. The entitlements that allow these applications to continue existing were developed after the applications themselves, and to use them, I have to opt-in to functionality that was previously allowed. If the entitlements didn't exist, we'd have to rely on Apple to think it up, and the way they're behaving, I doubt they'd be as generous as allowing one like "can read any pixel and draw anywhere on the screen".
Clipboard managers are another thing that wouldn't exist if OSes started out locked down. Not only do you need to access the keyboard, you need to do so from the background! It was the openness of desktop OSes that gave developers this idea — on iOS, nobody would have thought it up.
Way back when, in iOS 4, Apple gave apps the ability to run in the background, but only certain types of app — music playing, voice calling, and location-based apps received dedicated APIs to do that. Again, Apple waited to see which types of program were popular on other platforms, and based their APIs around allowing those specific kinds of app. If all platforms started life locked-down, maybe one or two of these categories won't be available today.
f.lux, the program that runs in the background and dims your screen red in the evening, is another example. I used to love using it on my desktop computer. But in iOS, they asked for the API, and weren't given it. And honestly, I'm kind of on Apple's side with this one: tinting the screen is the sort of system property I want only done by the OS itself, not an app, so now I use Apple's implementation of the same idea, Night Shift. But again, if the ability to tint your screen did not exist on desktop OSes, I'm willing to bet that Apple would not have come up with the idea.
And even if the idea is there for an entitlement to exist, that doesn't mean that Apple are going to allow it: adding one costs developer time, testing time, and documentation time. In a recent episode of Accidental Tech Podcast, I discovered that Switchglass (a Dock replacement I use) isn't allowed to Quit other apps, a feature I've sorely missed, because it's disallowed by the macOS sandbox. The idea for the entitlement is there, and the need is there, but Apple isn't bothered about apps opting in to such fine-grained functionality as quitting others. Ask me it through a prompt! That would be great!
I hope you see what I'm trying to say here. It used to be the case that macOS "allowed" iOS to exist, because it soaked up all the complexity — and slowly, features that proved popular on the desktop were allowed to exist, in a secure fashion, on mobile. I'm worried about how when I run random programs on my Mac, they have access to all my important files. But I'm also worried about the future. The tighter the grip OS manufacturers have on what sort of code can run on users' machines, the less innovation we'll see, and the worse computers will become.
Sure it does! We just need sufficiently granular permissions for all of this stuff. “Do you want to give ClipboardManager access to your clipboard?” Yes. “Do you want to give TikTok access to your clipboard?” No. I agree that clicking a million permission boxes is annoying but ideally it should only be something needed for apps that don’t fit the media consumption model.
The real problem is that the desktop security model is outdated - it was designed for a world where software developers are trusted by default and users need to protect their data from each other. Today we can’t trust that developers will respect my data. I mean, the fact that any application I run or any npm module I transitively install could upload or delete any of my personal documents is insane. We absolutely need to preserve my ability to run software I write, and run screencast software, file servers, etc. But permission to read my data should not be given by default to any software I happen to run. The Epic thing makes me nervous but generally I think Apple’s direction here is the right one.
> I agree that clicking a million permission boxes is annoying but ideally it should only be something needed for apps that don’t fit the media consumption model.
Media consumption apps are nice and good but I think pretty much all innovation is dependent on media production apps. A permissions model that treats media consumption as the most important use case will necessarily inhibit artistic expression and utility.
> The real problem is that the desktop security model is outdated - it was designed for a world where software developers are trusted by default and users need to protect their data from each other. Today we can’t trust that developers will respect my data.
Why is it any different today? You can always only install applications you trust. It would be useful to have sandboxing for untrusted applications (especially when said sandboxing would also allow you to monitor what the application is doing), but not all applications are untrusted.
The UNIX permission system was designed when computers cost millions, they had lots of users through timesharing (many of whom were programmers themselves). And computers had comparatively little software. And most of the software that was on the computers was installed by the system operators; who could be trusted to not install software from disreputable developers. The threat model was malicious users accessing each other's files; so user accounts with limited permissions kept us safe.
Today I have several computers. Each computer only has 1 user. And yet my /etc/passwd file still has 110 entries somehow. And it doesn't really help - the thing I need to protect the most on my computer is my data, and most programs on my computer could read and modify all my data with impunity if they wanted to. The permission model nothing to protect my own files from the programs I run.
Using tools like homebrew I install new software very frequently, and I don't have time to vet the code I run. There is a staggering number of software developers who have contributed code that runs on my computer. Some of them work at companies in direct competition with each other. Some of those companies I don't really trust. (Hi Facebook). So I rely on sandboxing in the browser and on my phone to keep my data safe.
The UNIX user permission model just doesn't meet modern needs.
> A game engine that needs to keep track of imported resources (especially when you want automatic imports when the file is saved via a 3rd party tool - e.g. saving a model on Blender or a texture on Krita causes an automatic reimport/convert to the engine's format)
A game engine isn't likely to do that in a production build. Even if it wanted to though, these sorts of "file ticket" sandboxes still has support for "directory ticket" and "file watchers". Even if storage specifics like "drive" or "path" are opaque to the application, they can still ask the user for permission to an entire directory (either explicitly in an "Open Directory" or implicitly in directories they naturally own such as "app data" and "resources" directories). Figuring out "where" that directory is for the user in Blender or Krita might not be straightforward, but just because those "tickets" are designed to be opaque to applications doesn't mean they have to be opaque to users and the operating system has lots of interesting possibilities to answer user questions about where things are, such as smarter Save File dialogs that are "ticket aware". ("Open Tickets > Game X has an Active File Watcher on this Resource Directory")
Almost all the same applies to other similar tools like file servers, file managers, VCS clients. Opaque/transparent is a "cone" in "ticket" based systems. It probably should be opaque where exactly my "file share" folder is stored, and all of my folders that are not my file share folder to a file server, so long as the contents inside that file share are transparent enough. The hard thing is defining those "cones", but the past default of "everything is transparent" is a problem and the over-correction in some systems to "nothing is transparent" sometimes blinds us to finding better ways to define these visibility cones rather than complain that they exist at all.
(Fwiw, all of the above is possible in the strict UWP Windows sandbox today: you can ask for directory tickets, you can ask for file watchers with those tickets. This isn't entirely theoretical, there have been practical applications, if not enough.)
> A game engine isn't likely to do that in a production build.
I actually have worked on two AAA game engines that did exactly that. The entire idea was to make importing stuff easier and minimize the time between the artists editing content in their content editor and having it imported and visible in the engine.
> Even if it wanted to though, these sorts of "file ticket" sandboxes still has support for "directory ticket" and "file watchers".
How are those given exactly? You'd need to ask for permission for every directory? If you cannot have the program monitor the directories, how would it know that a file changed before asking permission? Or the permissions will be asked at startup (since it is very common to edit existing content instead of only importing new content - the editor remembers the original paths for all content and can start monitoring it at startup).
TBH this all sounds like a UX nightmare, especially when the entire goal is to make the process smoother.
Software like clipboard managers also wont work. Screen sharing and remote desktop software similarly wont work. Screencast software wont work. Hotkeys software wont work. Most desktop automation software wont work.
I could go on and start looking at what i have installed to extend this list (i'm sure most of the software i have on my PC wont work), but i guess you get the idea. Almost everything that doesn't fit in the media consumption model that you'll often find on a phone or a tablet wont work (and amusingly enough, at least on my Android, stuff like a file server does work, though i've heard Google wants to remove that functionality).