Mobile OSes got to rethink everything in an era of constant adversarial connectivity and started off on a better foot in this regard.
Mobile OSes got to rethink everything in an era of constant adversarial connectivity and started off on a better foot in this regard.
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).
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.
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.
[1]: https://developer.apple.com/library/archive/documentation/Ge...
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.
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.
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.
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 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.)
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.
just curious, but what makes it specifically hard?
SPI is system private interface, also known as private API–Apple doesn't document it, can change it at any time, and usually discourages its use.
the term threw me off
Whilst this works for some programs, it gets... Difficult... When dealing with others.
What permissions should sh get, for example? And do the programs it will call inherit the same, or do they get their own permissions, or a hybrid?
The permission model works pretty similar here to a restricted user account. It sees system files as read-only, cannot see the contents of certain files and directories, etc. The root of the filesystem might be of the parent system or of the sandbox itself.
On macOS, reading certain directories (like the user's Desktop) will result in a user consent prompt due the sensitive contents. There is, after all, no guarantee that the request was directly initiated by the user, and not some curl-pipe shell script. There is however a "Developer Tools" entitlement that encompasses all of these sorts of prompts - but this is meant to be enabled through a developer action and not any user-presented prompt.
On macOS, there are basically higher-than-root system integrity protections, such as modifying files that the OS maintains. You can disable this system protection by booting into recovery mode and running a command-line tool.
Generally, the goal with system integrity protection is not to restrict professional work but to restrict the ability to publish software that tells the user to disable system-wide protections. There was recently an issue with the Google installer where a Chrome update wiped out part of the system when these protections were disabled, primarily noticed on hackintoshes and video production Macs where tools require SPI to be disabled to run unsigned kernel extensions, etc. Oops.
Apple has been trying to reduce the need across macOS releases to have applications need to be installed at all, with recent releases making items like browser, system, and kernel extensions bundled inside the application itself rather than being distributed across the filesystem. The goal is likely to eliminate app installation on macOS from needing to be a privileged operation.
For example, say you use pass [0], it's just a Bash script. You want it to be able to access pbcopy/pbpaste, for basic functionality to work. You don't want to give it permission every time.
However, you probably don't want sh to be able to access pbcopy/pbpaste without permission.
Scripts themselves should hold certain permissions, but those permissions are currently held by their host application, because sh /usr/local/bin/pass isn't identified by the system as an application. The app is still considered to be sh.
More importantly, if they see something like a permissions screen, they will have a false sense of security.
And severe restrictions on the app, would hamper user experience. Code signing and developer ID are the most practical means to ensure quality software.
With weak sandboxing we're still left with the problem of LPE -- once you're on the box (with, by default, unlimited network access!) you can gain root quite quickly, because the kernel interface is rather large. So you still need code signing and developer IDs. However dev IDs could be a federated system -- user's shouldn't have to accept Apple as the total and sole authority for accepting or rejecting apps/developers.