We did our best but the fact is that sandboxed apps run more slowly, have fewer features, are more isolated, and take longer to develop. Sometimes this cost is prohibitive (see Coda 2.5).
IMO the app sandbox was a grievous strategic mistake for the Mac. Cocoa-based Mac apps are rapidly being eaten by web apps and Electron psuedo-desktop apps. For Mac apps to survive, they must capitalize on their strengths: superior performance, better system integration, better dev experience, more features, and higher general quality.
But the app sandbox strikes at all of those. In return it offers security inferior to a web app, as this post illustrates. The price is far too high and the benefits too little.
IMO Apple should drop the Mac app sandbox altogether (though continue to sandbox system services, which is totally sensible, and maybe retain something geared towards browsers.) The code signing requirements and dev cert revocation, which has been successfully used to remotely disable malware, will be sufficient security: the Mac community is good at sussing out bad actors. But force Mac devs to castrate their apps even more, and there won't be anything left to protect.
The software developers and software companies of today are on average not to be trusted: they will outright steal the customers' private information and sell it or give it away without a second thought.
Absent adequate laws, the success of the iOS permissions model and the complete failure of the Android permission model in protecting customers is perhaps the clearest proof of what a sandbox can achieve.
I am reasonably sure that I can download an iOS app - any app - and that my private information will remain secure.
The platforms of today must offer a secure, privacy-preserving running environment. The free for all is dead, and it has been killed by greedy devs and companies.
So users have been trained to not use the App Store, where apps have to go through an approval process, and instead to install software from the wild west of random websites.
The fact is that Macs are not phones, the iMac Pro costs six thousand dollars, and expecting users to use the crippled selection of software from the App Store is unworkable. Nobody pays six thousand dollars to play candy crush.
You are definitely not in that crowd, but most Mac users definitely are. Frankly, until the App Store came out, they were all terrified of installing anything on their computer without some well known brand attached to it (e.g. Microsoft, Google, Adobe).
The App Store has been a great way for Apple to turn a demographic who was traditionally scared of installing apps into a new market.
> So users have been trained to not use the App Store
Again, you and I have been trained. Most users crap their pants when they see anything happed contrary to the "blessed path."
I don't want to allow any app free access to the file system. And anyway, developers have found creative solutions to this problem also. E.g: by asking the user to open the target location from the app they can circumvent the protection.
The AppStore has its negative sides too: apps can disappear and be replaced by v2, forcing one to pay again and again.
I'd LOVE to offer my app on the AppStore, but its too expensive and too restrictive.
A lot more awesome apps are available outside the AppStore.
Nonsense. The vast majority of users don't need software that does wacky stuff with the file system. They need software that opens documents they made, which all software in the app store can do. I'm a pro (the kind that currently owns the Mac Pro and will likely own the next one or the iMac Pro next), and I basically avoid all software that's not from the App Store. Your ranting sounds delusional to me.
Its not about "wacky stuff" its about basic things. Apps in the AppStore are horribly crippled compared to their not AppStore counterparts.
I'm a pro, and like many other pros, basically avoid all software from the AppStore.
Uhhhh, what? You're justifying a company you PAID thousands of dollars to remain in control of your device? We're fighting this sort of inane thoughts where these ideas are already executed. Look up John Deere, and the Freedom to Fix.
> They need software that opens documents they made, which all software in the app store can do. I'm a pro (the kind that currently owns the Mac Pro and will likely own the next one or the iMac Pro next), and I basically avoid all software that's not from the App Store.
Ok. You can choose to or not to.
> Your ranting sounds delusional to me.
You're calling someone else delusional for calling bullshit on Apple's faux-security? And you're calling for the app-ification of all computers? The person calling bullshit on Apple-faux-security isn't the delusional one here.
This is the bit that you FOSS diehards don’t get. Nobody really cares. What they want is something that they can switch on and go to Facebook or edit their documents on. They don’t want to tinker with kernel exstentions or run servers. For most, computing appliances are far more convenient.
You might want to pack up that opinion and take it to some place called "consumernews" or something (they might call it "productnews" these days). That is where nobody really cares.
While most of the "FOSS diehards" get it just fine. People want convenience. It's not that hard to understand and you're making yourself look like a fool if that's your claim. Doesn't mean convenience is the right way forward, even if people want it or don't care.
Since when is "people don't care" a viable argument for anything, the people that don't care, don't understand this.
So climb down from your ivory tower and make them understand without reverting the usual rhetoric as you have done here.
You would be surprised.
Keep in mind that professional users that buy the iMac Pro use pro apps, like AutoCAD, Final Cut, Logic, ProTools, Creative Suite and the like; these apps are mission-critical to their workflows and are not crippled.
This is an 'unintended side effect' of the software-as-a-service model. When software was licensed the software itself was what made the money, and there was no way that someone would buy a piece of software if it did not at least try to keep the data safe, in one piece and on the users' computer. But with software-as-a-service the user expects to see their data moving elsewhere and once that has happened all bets are off on how it can - and will - be monetized.
The performance and limitations can definitely be improved, if not eliminated, if Apple focused on it. The question is: Will they?
I agree with you but think there should be more emphasis on connectivity.
In the 80's and 90's (less so of course in the 90's) if you got a computer virus it was probably from sharing software ... on a floppy disk. I used a Mac during those decades and like other software viruses were rare on that platform. :-/
The internet changed everything. Not only does the internet serve up compromised software it provides the back-channel so the malware can phone home.
I don't have any suggestions or any sort of panacea. It's nice sometimes just to reflect on how computing used to be. Back before passwords, sandboxes....
If I'm using the App Store stuff, then my text editor can't edit all my files, my video player can't open videos when I double-click them, my Evernote can't print to PDF, my disk usage analyzer can't analyze my disk because it can't ask me for authorization to do so, and so on.
At the same time, though, in theory I do want sandboxing, at least by default. I do want to have to explicitly authorize some random app before it can install a printer system extension, or before it can scan my entire disk.
I feel like the problem is more political/cultural: Apple prioritizes their low-information, low-computer-literacy users (hi, Dad!) so dearly, that they aren't willing to expend resources to find any compromise for their technically proficient ones. And through the sandboxing requirements, they force their third-party developers to either tell their power users to fuck off, or to give up on the App Store.
Or, I don't know, perhaps they just don't have enough engineers left for the Mac after moving so many of them to their higher-volume Candy Crush console business.
Regardless, though, if there were mechanisms for the user to control the sandboxing enforcement to a greater degree, I would be all for it.
If we could tell our Macs "yes, dude, I hereby authorize DaisyDisk to see all the files" and "Computer, hey bud do me a favor, overrule this restriction that says CotEditor can't ask me to authorize modifying root-owned files", then I would actually not only be happy with, but even prefer, the App Store versions.
But we can't, and it's sad.
The problem though, if you allow for user overrides, then the next TotallyNotShadyVideoPlayer will kindly ask you to add the manual override for "can't read the screen" and, if you agree, it'll steal your credentials. That is, regular users will be easy to selfpwn.
I don't think this can be solved on the software side. It's "security vs. usefulness, pick one" kind of situation. Maybe we need to tackle the human factor - make it easier to prosecute malicious code authors - but not sure if that's any more possible to implement than software that's both useful and secure.
That's true, as far as it goes. My view is, maybe you make the dialog to do that scary enough; maybe you have to go enable some security setting to even make the dialog possible; maybe, even so, you have to accept that some users like my dad will get fooled and exploited.
OTOH, it's already a slippery slope; even more secure would be to completely prohibit all third-party software entirely.
I think they are drawing the lines wrong.
This sounds like you're on the right track. Make it a shell command you have to execute with SIP disabled.
I fail to see how the macOS sandbox prevents this. Disk usage analyser can ask you for disk access, sandboxed video players can surely open files double clicked in Finder, sandboxed apps can print to PDF.
A few example: QuickTime Player is sandboxed, Pages is sandboxed.
I think you might be thinking of the reasonable sandbox we wish we had, not the one we have.
(Apple's own apps do not have to follow the rules that third-party apps do.)
* Open dialogs
* A limited number of files that have been opened in the past via open dialogs (intended for e.g. recent files)
* Files that live in the app's sandboxed region of the filesystem.
That's it. So your text editor can't open ~/.bash_profile unless it pops up an open dialog and asks you to manually click it.
This sandboxing would be a problem with editors that naturally work with multi-file projects (e.g. an IDE where you'd want to open a whole Java project of linked files), but in the text editor scenario this limitation seems to make sense.
Yes it can. The print dialog has a whole PDF menu.
That feature is very useful, though; it can save anything, from any app that can print, to Evernote.
To save PDF into Evernote on the Mac:
- if it's a file- use the share option (right click>Share>Evernote)
- if it's in a browser- in Safari click on share (top right hand corner of the browser) > Evernote. If it's in Chrome, AFAIK, you have to use Evernote Web Clipper (extension) which is also available for Safari.
- Of course, you can also copy/paste or drag and drop PDF into Evernote
On the other hand, I am not sure that code signing has been an all-around success. It seems to make life harder for the long tail of one-off apps and open source ports. And bad actors are only blacklisted after they've been caught. https://panic.com/blog/stolen-source-code/ - related: https://github.com/HandBrake/HandBrake/issues/619
I think I would prefer a security model were you could just download and start any .app, but upon first opening it, a dialog would inform you about its code-signing author and the permissions that the app has (with striking red/green color coding). Because right now, there is no way to tell which apps even use sandboxing without opening Activity Monitor, and there is no incentive for non-App-Store-apps to use sandboxing. (There is a dialog when opening a downloaded app for the first time, but it's grey and boring and not helpful at all.)
I agree with the need of a better first launch dialog.
But it's still better than nothing, I'm sure they would offer unsigned HTTP downloads if Apple didn't force them to get their shit together.
This would solve most of my complaints.
I'm not sure Apple should give up on it though, I don't want any old application I download to be able to read through the spreadsheets in my Accounting folder.
Perhaps the emergence of Electron is a wake up call for Apple and Microsoft, there is clearly a demand for creating applications with web technologies, OS developers need to respond to that rather than letting a third party eat their lunch.
But Apple doesn't enjoy the luxury of solving this problem in a nuanced way, because Mac apps are not acting from a position of strength. I suspect you aren't downloading lots of Mac apps today, and the reason is not insufficient sandboxing, but instead the limited selection, annoying install experience, etc. These are the problems that Apple must fix first.
> Perhaps the emergence of Electron is a wake up call for Apple and Microsoft, there is clearly a demand for creating applications with web technologies
34 years ago, the Mac was new and generated developer excitement. But Apple was afraid the Mac would be dragged down via shitty DOS ports of apps like e.g. WordPerfect. Apple's response was to set a high bar via first-party "killer apps" like MacWrite, which would embarrass any such DOS ports. It worked: the Mac set the desktop publishing standard for years, decades even, and arguably still dominates.
Yes, there's a demand for developing apps with web technologies, but embracing that is a losing strategy for Apple. Why should I buy a Mac to run web apps that run equally well on a Chinese Chromebook? That's ceding any software advantage.
Instead Apple should leverage the Mac's unique software strengths. Aggressively evolve the Mac's unique "UI vocabulary" and application frameworks. Empower, not punish, the dedicated and passionate developer community. Ship love to the userbase (perhaps the only one in existence) that's willing to open their wallets for high-quality desktop software. And yes, tolerate web-tech apps too - but embarrass them!
Yes it's still much better than the typical Windows installer experience, but zero-install web apps are now setting the bar.
Web apps in the browser are OS-Agonstic and Electron apps can be easily made cross-platform.
1. Superior performance. Native apps are just faster. They launch faster. They use an order of magnitude less memory. Multithreading via GCD is much much nicer than Web Workers. Large files are better supported. You can have very large tables. etc.
2. They properly implement Mac UI idioms. By comparison even the nicest Electron-like app (VSCode) violates many longstanding expectations: it doesn't properly highlight the menu bar when typing a key equivalent, menu items don't disable properly, the text highlight color is wrong, text selection anchors incorrectly, no column selection, text drag and drop is badly broken, undo doesn't know what it's undoing, undo coalesces incorrectly, hell even arrow keys sometimes go the wrong way. It's an island app doing its own thing.
The theory of the Mac is to establish a set of UI conventions. When you launched a new app, you would already know how to use most of it, because it was a Mac app. It looks and behaves like other apps, so you feel at home already. And as a developer, you get the right behavior now and in the future, for free.
But if every developer builds a cross-platform app with a custom framework and appearance and behavior and UI, then the OS loses its role in defining the platform conventions. In that event, what's the point in having more than one OS?
From a developer point of view, it's just better to make a Web App or a Electron App that will be used by everyone irregardless of their OS. Not only it's less of a hassle to develop but also guarantees that more people are gonna use it.
I'd also argue that VS Code isn't much worse off than most native code editors. Most code editors outside of Xcode don't use NSTextView and so have to implement all of the behavior themselves anyhow. For example, as far as I'm aware Sublime Text pretty much implements just as much of the core editing logic as VS Code does.
I'm not denying your complaints, of course--they're valid--but I don't think the gap between native and Web/Electron is as big as you're implying.
Whereas developing Mac apps seems to rely on a set of arcane knowledge and having been in the scene for years. The documentation for AppKit is vastly outdated and there is almost no blogging/tutorials scene so as a newbie you are basically going to be going through a lot of trial and error.
And then most of the documentation you will find is in ObjC while everyone around you is telling you to develop in Swift, but then Swift changes every few months. You open up a project from a few months ago, it doesn't compile anymore, and you basically have to work at Apple or be a dev god to fix it.
So.... native is easier to develop for? No way.
That’s an okay decision to make if it fits your product and market needs, but it’s important not to forget the cost.
Native apps perform better, integrate better with other system services, are more power efficient, use less storage space… usually technically superior in every way, with the exception that that are less portable and in some cases more time consuming to build.
Clearly the key reason Mac apps cost so much to develop is the platform-specific codebase they require. Mac apps have little in common even with iOS apps, so it's a huge cost. Against that baseline, adding sandbox entitlements is an extremely minor incremental cost.
It's not like eliminating the sandbox would drop the cost of Mac apps by some huge factor. Developers are writing web apps because they can use a cross-platform codebase, plain and simple. That's why I am much more optimistic about the rumor that Apple will lower the delta between Mac and iOS codebases, letting devs leverage their iOS investments. There will always be a cost to adapting a touch-based app to the desktop, but there's orders of magnitude more efficiency to be gained there than in blowing away a whole layer of the security model.
It's used by homebrew during the build steps, I hear it's in progress for Nix, and I may make use of it in the future for archmac. Unfortunately it's been marked as deprecated in the man page:
SANDBOX-EXEC(1) BSD General Commands Manual SANDBOX-EXEC(1)
sandbox-exec -- execute within a sandbox (DEPRECATED)
I mean, you were on the AppKit team, so I don't think I need to list out the oddities/issues/etc it's currently got. Just curious if the general attitude in Apple was akin to "it's fine", or "we know it needs work, but we'll get there eventually".
That said it's easy to overextend yourself, as Microsoft demonstrated with their API treadmill. The art of engineering is to set the right evolutionary pace.
Your question is very good, and above my pay grade. In 2013 I had lots of opinions about how ObjC was evolving too slowly, and I was floored the next year when Swift (a well-kept secret within Apple) was unveiled. Apple is full of surprises, even to its own employees.
Anyway, not looking to derail the discussion, just wanted to say thanks for commenting - wasn't sure if anyone ex-Apple would be comfortable doing so.
> their strengths: superior performance, better system integration, better dev experience, more features, and higher general quality
These are important, but you generally do not want to sacrifice security to get them. The sandbox is opt-in on the Mac so where you have an app you believe cannot live in it, you have that choice. Saying Mac devs are forced to castrate their apps isn't accurate or fair.