10 ms·

I was an AppKit engineer when the Mac app sandbox was introduced in 10.7. Much of our effort that release (and in following releases) was dedicated to making Ma

I was an AppKit engineer when the Mac app sandbox was introduced in 10.7. Much of our effort that release (and in following releases) was dedicated to making Mac features work within sandboxed apps. Think open and save panels, copy and paste, drag and drop, Services menu, Open Recents, etc. 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.

intelhearts 9y ago
I still don't understand why the multitouchframework is private
tonyedgecombe 9y ago
It does strike me as something that is very difficult to retrofit. 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.
- javajosh 9y ago
  One way to isolate applications, common for server daemons, is to run them under their own user. The real "human" user can sudo into any application account, and does so on application execution. Marketing would have to rename things and slap a GUI over the feature, but I don't see why it wouldn't work for arbitrary Cocoa apps. (And the screen-capture API should be limited to capturing parts of the screen the application is currently drawing to, with overlaps clipped out, etc.)
  - deecewan 9y ago
    That's clearly not viable, as displayed in the linked article. One of the examples of a good use for this was 1Password reading QR codes from a browser. Additionally, how would screen capture software work?
    - javajosh 9y ago
      So if I argue that Clojure is a great language, you'd reject that claim because you can't write drivers in it. Got it.
- ridiculous_fish 9y ago
  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. > 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!
veidr 9y ago
I agree, it's terrible. As a user, I often go to pains to avoid getting the App Store version of an app, if an alternative exists, because those apps are crippled to such a degree that they aren't worth using. 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.
- TeMPOraL 9y ago
  I feel completely the same. 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.
  - veidr 9y ago
gurkendoktor 9y ago
I'm a big fan of desktop sandboxing, so thanks for the hard work. I dreaded running the unsandboxed Office:mac 2011 with its constant stream of "critical" security updates. That was definitely my worst experience using native apps. 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/ https://panic.com/blog/stolen-source-code/ - related: https://github.com/HandBrake/HandBrake/issues/619 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.)
- galad87 9y ago
  The only thing required to get a Developer ID signing certificate is a valid credit card (and I guess is not so hard o stole one) Tranmission malware was signed, Eltima Player malware was signed. I agree with the need of a better first launch dialog.
  - blub 9y ago
    Yes, many developers sign, and then fail to offer a secure way of verifying that the signature belongs to them. 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.
    - HHad3 9y ago
      I'd argue that Apple fails to offer a secure way of verifying the signature: Finder only shows me that an app is signed when I first run it. It does not provide me with a signer name or team ID that I can match with information I got from the developer. The information is available via command line by running "codesign -dvv", or by installing a Finder extension such as WhatsYourSign [0]. [0] https://objective-see.com/products/whatsyoursign.html https://objective-see.com/products/whatsyoursign.html
Klonoar 9y ago
I'm not sure Cocoa's dev experience is a plus right now though - isn't Marzipan intended to fix that? 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".
- ridiculous_fish 9y ago
  Mac Cocoa dev has been evolving slowly and incrementally due to the small team size and strong backwards compatibility culture. It's fallen behind as a result. But fundamentally a platform-specific API and toolset can move much faster than a standards-limited web API. 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.
  - Klonoar 9y ago
    I don't disagree re: the pace, but I think it's important to note that when it's really just Electron (Chrome) that people are shoving everywhere, it's not _really_ a standards-limited web API... it's whatever Google opts to give them. Electron is sadly the first really approachable "build your app in a virtual machine and it'll just work" approach. 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.
Gys 9y ago
The rumor is that Apple wants to unify the iphone, ipad and mac platforms [1]. So my guess is that they will keep the sandboxed apps because ios apps are also highly sandboxed. [1] https://www.bloomberg.com/news/articles/2017-12-20/apple-is-said-to-have-plan-to-combine-iphone-ipad-and-mac-apps https://www.bloomberg.com/news/articles/2017-12-20/apple-is-...
lloeki 9y ago
One thing I quite liked about the sandbox is running marginally (un)trusted code either interactively or as part of some process, and for that sandbox-exec(1) is great. Security best comes in layers and it's a worthy addition to the toolbox. It's used by homebrew[0] 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) NAME sandbox-exec -- execute within a sandbox (DEPRECATED) [0]: https://github.com/Homebrew/brew/blob/master/Library/Homebrew/sandbox.rb#L5 https://github.com/Homebrew/brew/blob/master/Library/Homebre...
jmull 9y ago
I really don't think shrugging and giving up on security for desktop apps is a viable path. > 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.
blub 9y ago
Not having a sandbox was acceptable in the 80s and 90s, when the software development community was reasonably trustworthy. 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.
- namelost 9y ago
  Apple's implementation of sandboxing actually makes computer users less secure. All the good software is distributed away from the App Store, because sandboxed apps are far too limited (especially regarding the filesystem). 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.
  - ahakki 9y ago
    > Nobody pays six thousand dollars to play candy crush. You would be surprised.
  - fny 9y ago
    The App Store wasn't made for the 1000 people with iMac Pros. It's made for millions of average Joes who just want to use their computer without having to worry about ransomware. 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."
osteele 9y ago
Thanks for you effort. I prefer Mac app store apps, when they're at parity with non-store releases, because there's fewer licenses to install and manage (even if they all go in my password manager), and because I can upgrade all the app store apps at one go instead of being nagged by each one separately.
someonewhocar3s 9y ago
Desktop software should be as secure as web software, or users will not trust it anyway. It's incredibly stupid that Apple is failing to deliver that in a nice package. Just copy the 'web application' idea, but do away with legacy and cross-browser bs. Offer a lot of services to software that are unavailable over browsers. By this point it is perhaps more feasible to abandon the operating system idea. All is cloud oriented. All is browser based. This is clearly the superior model. Self contained app containers are the future. Improve systems integration for those and you're actually spending your time in a useful manner.
abalone 9y ago
I think this is really flawed logic. Sandboxing adds some development cost, sure, but the implication here ("grievous strategic mistake") is that it's the key reason developers are building web apps instead of native Mac apps. That just defies common sense. 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.

intelhearts 9y ago

I still don't understand why the multitouchframework is private

tonyedgecombe 9y ago

It does strike me as something that is very difficult to retrofit. 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.

javajosh 9y ago
One way to isolate applications, common for server daemons, is to run them under their own user. The real "human" user can sudo into any application account, and does so on application execution. Marketing would have to rename things and slap a GUI over the feature, but I don't see why it wouldn't work for arbitrary Cocoa apps. (And the screen-capture API should be limited to capturing parts of the screen the application is currently drawing to, with overlaps clipped out, etc.)
- deecewan 9y ago
  That's clearly not viable, as displayed in the linked article. One of the examples of a good use for this was 1Password reading QR codes from a browser. Additionally, how would screen capture software work?
  - javajosh 9y ago
    So if I argue that Clojure is a great language, you'd reject that claim because you can't write drivers in it. Got it.
ridiculous_fish 9y ago
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. > 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!

veidr 9y ago

I agree, it's terrible. As a user, I often go to pains to avoid getting the App Store version of an app, if an alternative exists, because those apps are crippled to such a degree that they aren't worth using. 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.

TeMPOraL 9y ago
I feel completely the same. 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.
- veidr 9y ago

gurkendoktor 9y ago

I'm a big fan of desktop sandboxing, so thanks for the hard work. I dreaded running the unsandboxed Office:mac 2011 with its constant stream of "critical" security updates. That was definitely my worst experience using native apps. 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/ https://panic.com/blog/stolen-source-code/ - related: https://github.com/HandBrake/HandBrake/issues/619 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.)

galad87 9y ago
The only thing required to get a Developer ID signing certificate is a valid credit card (and I guess is not so hard o stole one) Tranmission malware was signed, Eltima Player malware was signed. I agree with the need of a better first launch dialog.
- blub 9y ago
  Yes, many developers sign, and then fail to offer a secure way of verifying that the signature belongs to them. 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.
  - HHad3 9y ago
    I'd argue that Apple fails to offer a secure way of verifying the signature: Finder only shows me that an app is signed when I first run it. It does not provide me with a signer name or team ID that I can match with information I got from the developer. The information is available via command line by running "codesign -dvv", or by installing a Finder extension such as WhatsYourSign [0]. [0] https://objective-see.com/products/whatsyoursign.html https://objective-see.com/products/whatsyoursign.html

Klonoar 9y ago

I'm not sure Cocoa's dev experience is a plus right now though - isn't Marzipan intended to fix that? 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".

ridiculous_fish 9y ago
Mac Cocoa dev has been evolving slowly and incrementally due to the small team size and strong backwards compatibility culture. It's fallen behind as a result. But fundamentally a platform-specific API and toolset can move much faster than a standards-limited web API. 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.
- Klonoar 9y ago
  I don't disagree re: the pace, but I think it's important to note that when it's really just Electron (Chrome) that people are shoving everywhere, it's not _really_ a standards-limited web API... it's whatever Google opts to give them. Electron is sadly the first really approachable "build your app in a virtual machine and it'll just work" approach. 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.

Gys 9y ago

The rumor is that Apple wants to unify the iphone, ipad and mac platforms [1]. So my guess is that they will keep the sandboxed apps because ios apps are also highly sandboxed. [1] https://www.bloomberg.com/news/articles/2017-12-20/apple-is-said-to-have-plan-to-combine-iphone-ipad-and-mac-apps https://www.bloomberg.com/news/articles/2017-12-20/apple-is-...

lloeki 9y ago

One thing I quite liked about the sandbox is running marginally (un)trusted code either interactively or as part of some process, and for that sandbox-exec(1) is great. Security best comes in layers and it's a worthy addition to the toolbox. It's used by homebrew[0] 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) NAME sandbox-exec -- execute within a sandbox (DEPRECATED) [0]: https://github.com/Homebrew/brew/blob/master/Library/Homebrew/sandbox.rb#L5 https://github.com/Homebrew/brew/blob/master/Library/Homebre...

jmull 9y ago

I really don't think shrugging and giving up on security for desktop apps is a viable path. > 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.

blub 9y ago

Not having a sandbox was acceptable in the 80s and 90s, when the software development community was reasonably trustworthy. 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.

namelost 9y ago
Apple's implementation of sandboxing actually makes computer users less secure. All the good software is distributed away from the App Store, because sandboxed apps are far too limited (especially regarding the filesystem). 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.
- ahakki 9y ago
  > Nobody pays six thousand dollars to play candy crush. You would be surprised.
- fny 9y ago
  The App Store wasn't made for the 1000 people with iMac Pros. It's made for millions of average Joes who just want to use their computer without having to worry about ransomware. 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."

osteele 9y ago

Thanks for you effort. I prefer Mac app store apps, when they're at parity with non-store releases, because there's fewer licenses to install and manage (even if they all go in my password manager), and because I can upgrade all the app store apps at one go instead of being nagged by each one separately.

someonewhocar3s 9y ago

Desktop software should be as secure as web software, or users will not trust it anyway. It's incredibly stupid that Apple is failing to deliver that in a nice package. Just copy the 'web application' idea, but do away with legacy and cross-browser bs. Offer a lot of services to software that are unavailable over browsers. By this point it is perhaps more feasible to abandon the operating system idea. All is cloud oriented. All is browser based. This is clearly the superior model. Self contained app containers are the future. Improve systems integration for those and you're actually spending your time in a useful manner.

abalone 9y ago

I think this is really flawed logic. Sandboxing adds some development cost, sure, but the implication here ("grievous strategic mistake") is that it's the key reason developers are building web apps instead of native Mac apps. That just defies common sense. 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.