The Mac App Sandbox and Non-Native Apps
Felix Krause (tweet, Hacker News):
Any Mac app, sandboxed or not sandboxed can:
- Take screenshots of your Mac silently without you knowing
- Access every pixel, even if the Mac app is in the background
- Use basic OCR software to read the text on the screen
- Access all connected monitors
Nobody tell Felix that Mac apps can also read the clipboard.
This is why I think a network blocker like Little Snitch is more important for protecting users than the sandbox. Anyway, this is not really news, but it prompted some interesting comments from former Apple engineer Peter Ammon:
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.
I still think the idea of sandboxing makes sense, but the actual implementation of it—the available entitlements, the framework bugs, the lack of documentation, and the App Store policies—were botched. And there has been little visible progress since macOS 10.7. Is this because it’s fundamentally not possible to do better, given that the Mac wasn’t designed with sandboxing in mind? Or has it simply not been a priority for Apple?
It’s a hard UI problem. The Mac sandbox overcorrects to requiring capability resources for all file accesses, while on the other extreme we have e.g. Windows UAC which trains users to roll their eyes and click through.
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.
[…]
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!
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?
John Gruber (tweet):
I’m with Ammon: I think the Mac’s (relatively) recent move to cryptographically signed applications — with certificates that can be revoked by Apple — has been a win all around for security. But I don’t think the Mac sandbox has.
[…]
The whole point of the Mac is to be a great platform for native Mac apps. Sandboxing doesn’t help Mac apps do more. If the Mac devolves into a platform where people just use web browsers and cross-platform Electron apps, it might as well not exist[…]
[…]
The real problems facing the Mac are the number of developers creating non-native “Mac” apps and the number of users who don’t have a problem with them.
Andy Ihnatko (in 2011, previously):
Traditionally, the mandate of an operating system has been to enable all of a machine’s potential. Higher-level software is responsible for making a computer easy to use and sometimes that means putting the power tools high enough on a shelf that the kids can’t hurt themselves, but those resources should be there for anybody who looks for them.
[…]
The Mac must never, ever become a consumer product like the iPad, saddled with artificial limitations in the name of safety, reliability, and tidiness.
See also: Jeff Johnson, Dan Counsell, Sayz Lim, Michael Dupuis, Dave DeLong, Marcus Zarra.
Previously: Sandbox Limitation on Number of Files That Can Be Opened, Apple Rumored to Combine iPhone, iPad, and Mac Apps to Create One User Experience.
7 Comments RSS · Twitter
For me, the primary blocker against making native Mac apps isn’t the sandbox (mostly because I wouldn’t use it). The primary concern for me is the stability of the OS in general. I hesitate putting time into making an app for a platform that is getting more frustrating to use over time.
I find myself wanting to hedge my bets with something like Xamarin (or a webapp) so if the time ever comes to jump ship, I can take at least part of my work with me.
I agree with John Gruber. Software signing has definitely been a win in day to day use and for pretty much all commercial software.
The only thing that concerns me though is that signing software essentially straps a time bomb onto the binary. It's the reason that I decidedly do not sign any of the builds I make of the Classic Finder project. Years and years and years from now I want any interested party to be able to download and run any of the builds I make and post online. With the way Xcode and the SDKs work, in five years I won't be able to go back in VCS, checkout a changeset I'm working on now/today and actually build it.
(OTOH, in five years, unsigned applications might be completely dis-allowed altogether...)
@Ben It’s not easy for the end user to do, but couldn’t you always remove the signature or re-sign the binary later?
"Mark my words: history will look back at the recent “iOS-ification” of Mac OS X as as quaint and superficial and meaningless as the Mac-like interface of the Apple IIgs." ( http://wanderingcoder.net/2013/06/10/mac-os-x-new-classic/ ). I like to think I was not too far off the mark. However, my deadline for Apple announcing Mac OS X as the classic of iOS is coming up fast, I think I should start looking for crow recipes right about now…
@Michael Tsai
Ohh that sounds scary! But I have never considered that possibility before - I'm going to look into it. Thanks for the idea!
Leaving aside discussion whether sandboxing is good or bad, I wouldn't agree it's the reason for "Cocoa-based Mac apps are rapidly being eaten by web apps and Electron psuedo-desktop apps". I think that happens because many developers believe web/Electron is the best route (at the moment) to create cross-platform applications and hence save development costs and time working on separate native versions. On the other hand, I'm pretty surprised how many (Mac) users are willing to cope with those applications, which are very slow and unresponsive and freaking BIG. I mean, 170MB for GitHub Desktop application?! 240MB for WhatsApp messenger?! Moreover, most of those application lack some basic (OS provided) features, for example spelling check/correction in text fields.
We've had cross-platform apps for years... either Java, Qt, or whatever. I guess Electron is the new shiny. They've always had a subpar experience, but better than nothing.
I find it sad that Cocoa has not really continued to abstract higher level UI into the API. If you look at the Xcode UI for example, how many of those buttons and controls can be used in our apps? The toolbox hasn't really expanded to be more high-level. :(
