Why the Mac App Sandbox makes me sad

Apple announced today that, starting in March 2012, all apps on the Mac App Store will be required to run in the so-called “App Sandbox”.

The sandbox is an environment that locks down the Mac in ways that match (and exceed) the limitations found on iOS. A sandboxed app doesn’t have direct access to any files or frameworks on the system. It can’t access the network or any devices.

For the app, nothing else exists on the system except for those files and APIs that the operating system explicitly makes accessible to it:

By default, the sandboxed app doesn’t really have anything of its own. Even files in its own Application Support subfolder may be deleted by the operating system if it wants to e.g. reclaim some disk space. The sandbox analogy is quite fitting indeed — inside it, an app’s data has all the permanence of a sand castle.

Do you feel entitled, punk?

Since the Mac isn’t a phone, most apps need to do something more persistent than e.g. rendering a nice image of a collapsing sand castle. To enable these apps to perform their job, Apple has created a list of permitted capabilities called “entitlements”.

Here is the complete list of available entitlements:

  • Read-only access to the user’s Movies folder and iTunes movies
  • Read/write access to the user’s Movies folder and iTunes movies
  • Read-only access to the user’s Music folder
  • Read/write access to the user’s Music folder
  • Read-only access to the user’s Pictures folder
  • Read/write access to the user’s Pictures folder
  • Capture of movies and still images using the built-in camera, if available
  • Recording of audio using the built-in microphone, if available
  • Interaction with USB devices
  • Read/write access to the user’s Downloads folder
  • Read-only access to files the user has selected using an Open or Save dialog
  • Read/write access to files the user has selected using an Open or Save dialog
  • Child process inheritance of the parent’s sandbox
  • Outgoing network socket for connecting to other machines
  • Incoming network socket for listening for requests from other machines
  • Read/write access to contacts in the user’s address book
  • Read/write access to the user’s calendars
  • Use of the Core Location framework for determining the computer’s geographical location
  • Printing

That’s it. (There are also a couple of temporary exception entitlements that will be going away. If your app uses Apple Events or Mach ports, Apple may grant you a temporary license to keep doing so, if you can make your case convincingly.)

Need to access hardware using something else than USB, for example Thunderbolt, FireWire or Bluetooth? Tough luck. (Just because these interfaces are on your Mac doesn’t mean Apple wants anyone to use them via 3rd party software.)

Need to communicate with processes that your app didn’t directly start, or perhaps take screenshots? Not going to happen.
Update: Gus Mueller, author of the Acorn app to which I linked, reports that screenshots are allowed in the sandbox. My apologies for the mistake. (Taking screenshots essentially means an app can read the contents of other applications’ windows. This is clearly a security risk in the same vein as opening arbitrary files, so I had assumed that screen capture is disabled in the sandbox.)

Maybe you’d like to read and write files in a known location on a network disk? Not possible, unless you pop up the Open/Save dialog for every file.

It’s important to note that these entitlements are granted by Apple, not by the user herself. App developers must provide justification for their entitlement requests when submitting an app to the App Store. If the Apple curator thinks that your app is not deserving of accessing the Pictures folder or interacting with USB devices, she has every right to turn down your request without additional justifications. (We’ve seen many Beckettian variations of this scenario played out on the iOS App Store over the past years.)

Goodbye plugins

One side-effect of the sandbox model which makes me particularly sad and nostalgic is that it kills the notion of plugins. This will also affect many of Apple’s own pro apps on the App Store.

Traditional plugins are binaries that are installed into a known shared location. On startup, a host app that supports plugins will look for them in the shared folder, and if they’re deemed compatible will make the plugins available within the app. Typical plugin scenarios are image and video filters, file format import/export, and providing direct interfaces to web services.

Many professional apps have a thriving plugin ecosystem. Adobe Photoshop started the boom back in the mid-’90s. Photoshop plugins have faded in popularity since those days, but plugins continue to be important for video and visual effects work, where users tend to have very specific and complex needs that the host app developers can’t possibly anticipate. Plugins are also great for apps like Aperture that focus on workflow management rather than editing tools, allowing 3rd parties to “fill the holes”.

In the brave new sandbox, this is not going to be possible. For starters, sandboxed apps can’t see the shared locations where plugins are traditionally installed.

Even if the app could see the plugins, it wouldn’t be able to load the code because sandboxed apps are code-signed. The sandboxed app binary contains an encryption signature inserted by Apple that tells Mac OS X that this code is safe to execute. Third party plugins wouldn’t have this signature, so they wouldn’t run.

I’m curious to know what will happen to Apple’s own applications that support plugins, including Final Cut Pro X, Motion and Aperture. These apps are only available on the Mac App Store. There is no way to even get a temporary exception entitlement that would allow plugins (at least for 3rd party developers).

If Apple were to keep plugin support in these apps, it would make it obvious that they don’t need to play in the same sandbox as everyone else. I don’t think they would want such a blatant example of two sets of rules on the App Store. Hence, I’m afraid that the days of plugins in Apple pro apps are numbered.

So what?

The obvious counterargument is that it’s Apple’s store, they make the rules, and nobody forces developers to submit their apps. This of course remains true. Mac apps installed outside the App Store will continue to run and enjoy the access privileges that, by and large, have allowed these apps to exist in the first place. (Think of a Mac app that you’ve loved over the years. I’m 99% sure that it does something that is not covered by the App Store entitlements.)

However, the Mac App Store is increasingly the place where Mac users discover apps. Apple’s big push with making Lion and the pro apps exclusive to the App Store has guaranteed this. Since Apple now considers the App Store such an integral part of the Mac platform, they can’t simply pretend that the other stakeholders in this ecosystem don’t exist.

Furthermore, the necessity of requesting entitlements from the App Store curators for basic things like Open/Save dialogs has got me slightly queasy. Until now, I’ve always thought of the Mac as a platform that has enabled me to excel as a developer and make a living. I’m extremely grateful to Apple for building Mac OS X into such a great software environment.

Yet now I feel worried to even speak up about this. If someone at Apple decided they didn’t like me, they can soon take away my ability to show file dialogs. I know I’m just being paranoid… But that’s how people start to behave in situations where they feel they don’t have any power over what’s being done to them.

Is this a shadow of what it felt like to be a sharecropper? I’m reminded of this 3-year old blog post by Tim Bray:

“I don’t want to write code for a platform where there’s someone else who gets to decide whether I get to play and what I’m allowed to sell, and who can flip my you’re-out-of-business-switch any time it furthers their business goals.”

This entry was posted in Business stuff, Mac-related. Bookmark the permalink.

126 Responses to Why the Mac App Sandbox makes me sad

  1. Alex says:

    Is Apple taking away the ability to build applications outside the App Store? I know my MacPorts still works, for example. Once MacPorts stops working, I’ll have no choice but to abandon the platform.

    Look at the sandbox as a means of ensuring that applications are only doing what they’re expected to do. If Apple’s applications do stuff that you can’t do, that’s an indication that there is functionality coming soon that will allow you to do that thing.

    No doubt we’ll hear lots of wailing and gnashing of teeth from developers whose App Store apps will be broken by the tightened sandbox model: there is nothing stopping them selling a “full” version of the application elsewhere (e.g.: BBEdit has two versions, one being the App Store version the other being the “full” version which can do authenticated saves).

    Raise the issues with Apple, eventually they’ll get resolved: just like the “do my downloaded maps or Instapaper documents live in cache or elsewhere” issue.

    • pauli says:

      Look at the sandbox as a means of ensuring that applications are only doing what they’re expected to do.

      To me, this is the crux of the problem. The whole point of having an extensible platform is to enable third parties to create things that the original developers couldn’t even have thought of. Innovation can’t happen in an environment where everyone is “only doing what they’re expected to do.”

      • Mark says:

        Isn’t that an excuse to just run DOS? I thought we got away from all of that. Yes, you could take it to the logical extreme, but when I think about security, this is effectively a MAC (Mandatory Access Control) happening at the app level.

        As long as Apple isn’t cheating, then this should be a good thing.

        • Dan Grec says:

          It’s the neXt step up from DOS – BSD.

        • Henk says:

          This is nothing like Mandatory Access Control. In a MAC-system the system administrator is in full control of which information is available to which processes by means of labeling of subject and objects — where the interaction between labels are enforced by the MAC policy. In the case with the Mac App Store case that control is handed over to Apple by means of cryptographic signatures.

        • Mark Munz says:

          But Apple is cheating. I’m pretty sure Xcode will still be available via the Mac App Store. There is no way that Xcode is sandboxable right now. It would likely be a gigantic effort to do so and honestly, they’ve got enough bugs to worry about.

          Also, most of the apps that ship with Mac OS X are not sandboxed. In fact, only Preview, TextEdit and a few background helpers are sandboxed. I’m doubting that Apple will revamp its entire stock of apps included in the OS without a major OS rev.

          These rules only apply to others. And the people that will mostly be affected are small developers — the ones that typically come up with the really cool ideas.

          • Yet, I tried to load extensions outside of the App Store and received a message that such a thing is not allowed. Here is a hypothetical if GCD, the sandbox, obfuscation of the core that would. Make this a good system reamed out from beyond the grave. That is just a possibility for a dead control freak. A daemon could put the sandboxd in a honey pot. It is also possible that a white hat will step in. I only offer probabilities.
            Everyone could sit on their sizable social capital and follow apple; blindly. It would intrigue me to meet others pondering the same possibilities. mitlyngk@yahoo.com I am only talking about thought, not resolute action. I wonder if Apple tries to own intellectual property from a peaceful assembly?

            Cheers.

  2. Pingback: Why the Mac App Sandbox makes me sad | Naming Things | App Flash

  3. Alex says:

    I am not so sure about sandboxing being a bad thing.

    If your app is no fraud, you will have some additional work to request entitlements, but your app will get approved in the end.

    Besides boosting security for AppStore users, complying with the sandboxing rules will make you rethink and improve the design of your app (like what happens if cached/temporary data will be deleted) which will increase the app’s quality and benefit you and the user.

    I actually see this very positive as there are a lot of apps that do not think their design through and carelessly handle resources or put files where they do not belong. If the OS X platform is not going to become a mess for the user like Windows, where application data is scattered all over the damn place and is impossible to be backupped selectively, it has to enforce certain rules like this data is permanent and lives here, this data is temporary and lives there and if it gets deleted the app will still work. You have to design your app this way anyway if you want it to sync with iCloud.

    So in my eyes, sandboxing – or its intention at least – simply is to enforce sane development of an application. Which is good for everyone.

    • Tom_E says:

      I am sure it is a really bad implementation of an questionable idea.
      Goodbye flexible storage. You want an application that manages your images, but they reside on an external disk? Goodbye, App Store distributed app.
      You want batch conversion to an iPod capable format for movies stored on that external 2TB disk? Welcome to NSOpenPanel each time you want to open one and another time for saving in a different format.

    • Alex2 says:

      If it was only about not letting apps write files in random places, then that might be OK. But it goes much further than that. The set of entitlements today are tiny, and they’re extremely blunt.

      For example, consider an app that finds the largest 10 files on your hard disk. Several such apps exist today, and they’re quite useful: you can free up a bunch of disk space easily. Unfortunately, there’s no entitlement for “read access to all files”, or even something much more benign like “get the size of all files in a user-chosen folder”.

      The current model works if your app only deals with individual documents, each of which is stored in a single file. That describes almost none of the apps I use today. It rules out things from “the TeX typesetter” to “compilers and development tools” to “Photoshop” to “web servers”.

      In fact, it’s hard to imagine many useful apps that would fit this mold. In the Mac App Store today, most of the apps I see are little one-off toys (like 99% of the iPhone App Store), or Apple Apps (which don’t need to live by these restrictions).

  4. Niklas says:

    Don’t really see the problem here. For many years you have been able to distribute your application the web and have people download it. You can still do this.

    Now, Apple opens up a store where users can purchase applications. I think it makes sense for them to this. If someone purchases an application from their store Apple wants to be sure the application won’t accidentally delete any of their files.

    The store will contain a subset of applications that are vetted by Apple. Many (most?) applications will live on as before on the web.

    • Paul says:

      The problem is clear if you think ahead far enough, treat corporate motives with the suspicion they deserve, and consider how this works on the mobile platforms (and Apple’s in particular).

      I’d be concerned about two things:

      1. My app on the App Store might be doing just fine until some curator at Apple decides that it’s overstepping a boundary and they pull it entirely or reduce its privileges. Tim Bray’s “you’re out of business” switch.

      2. So you can bypass the app store now but this is one step closer to a completely closed system just like the mobile iPlatforms where you have to jailbreak the device to install non-app-store software. Developing software which only runs on jailbroken systems is OK if you’re making small, free, niche apps, but it sure isn’t a sound business model. Worse, with a completely closed system you’ll have no choice but to go through the sole gatekeeper, pleading for clemency on the permissions your app requires, paying whatever they feel they can get away with for the “privilege” and hoping that you haven’t fallen foul of some future rule change you know nothing about yet.

      Nothing Apple has done in the last few years makes me believe they aren’t actively seeking to achieve a fully-closed ecosystem on all their product line. They’re closer to doing that than anyone has been since the bad old days when big blue dinosaurs roamed the datacenter.

      Yes, this can make for a much more consistent, safe, integrated user experience. That’s not a bad goal in itself, but as a developer OR as an end-user I don’t want to depend on any platform which could be closed down completely at any time in the future, possibly taking away choices that I would really rather have open to me.

      • Webby says:

        But it’s not an “you’re out of business” switch. It’s a “you can’t sell from our store any more”. I know lots of people making a living selling Mac software outside Apple’s store — far more than I know making any money at all by selling through Apple’s store, in fact.

        Think of renting retail space. The landlord can kick you out, but that doesn’t put you out of business for all time. It just means you need to find a new space.

        Fortunately, we have this big one, called “the web”!

        • Daniel Lord says:

          True for Mac software, but not for iOS software which is the future. Apple ‘s stated intention, if I interpret their statements correctly, is to move the Mac towards iOS— at least for the majority of users (there will always be technical platforms for development, etc. but that’s not a big slice of the market nor ever will be). So if you want to sell to the mainstream Apple user a few years from now, iOS and the Sandbox will be the monkey on your back whether you pick a desktop, laptop, pad, or phone target.

  5. Mike Hessey says:

    This sounds VERY bad news for not only developers, but USERS. I can understand why Apple, Google, Microsoft etc seek to limit what apps may do, but as you indicate, there is a point at which this seriously impacts on the user. The previous iOS (4) had pathetic support for serious photographers, and frankly I’m disappointed that Apple’s own iOS 5 Photos app is only marginally better (at user level). I had hoped that iOS 5 would remove some of the restrictions on developers, rather than the reverse. So is there any alternative? Windows and Linux seem far behind Apple, and Android/Google likewise, so these are not options for photographers.

    Keep up the good work – it really is appreciated.

    Mike

    • james says:

      I don’t know that I would connect “serious” photography and iPhone.

      • ryan says:

        He didn’t mention the iPhone, he mentioned iOS. And why shouldn’t the Photos app support photos taken on serious equipment? The iPad could be a fantastic platform for showing off hard core photos. (I don’t know if you’re making some sort of crack about the iPhone camera, but the Photos app is NOT restricted to showing pictures taken with that cam.)

        • 4thletter says:

          Show photos on a 10″ 1024X768 screen ? Whats the point ? You want to be showing off photos on a big screen laptop or TV at 1920X1080

        • Bernard SG says:

          It’s not “The iPad could be a fantastic platform for showing off hard core photos.” It already is, using the camera-kit, you directly import the content of your SD-card and there you go.

          • Tom_E says:

            Where exactly accessing the Camera Kit is not open to 3rd parties – which would give a lot of external opportunities (review / rate / delete images already on the camera, selective importing, tethering and changing camera settings….)

    • PeteG says:

      Neither Microsoft nor Google try to limit what apps may do. This is an Apple problem, and normally I would say, “So what, switch to Linux” but some of us HAVE to use OS X in order to develop iPhone/iPad apps and make a living. It’s awful. I have never been so angry at Apple.

      • Ken K says:

        I’ll say this as a MS guy- yes MS is doing this… at least to some degree in their new windows 8 store. All the ‘app stores’ are doing this and maybe ‘should’ to a degree… it just seems like the mac apps are being a bit draconian.

        I can see some benefit to the user, but all security is a balance of useability and protection, this is skewing too far in the protection realm.

  6. Sander says:

    You’re assuming that Apple will never change the entitlements based on third party feedback. A Mac App store without apps will not be very interesting. As you know Apple initial implementation is doing a few things right and then adding things to it as time goes on. I expect that additional entitlements will become available over time and that existing ones will get adapted based on developer and internal feedback.

    • Mark Munz says:

      No, the App Store will have apps — games will likely fit this sandbox scenario fairly well. Simple apps that are isolated and don’t interact with or try to leverage other apps will also be fine. But I’m easily running 6-12 apps that can’t be really be sandboxed.

      As for listening to feedback, I know Apple says they are listening, but there has been zero evidence that they are making any changes based on what they’ve heard. Other than the deadline (which went from Nov 1 to Mar 1), absolutely zero has changed since Apple announced the sandbox at WWDC.

  7. Bruno says:

    yeah man, this is really annoying, imagine the day when they remove the shell. it will be the day when i’ll leave the OSX. It really started to piss me off when I discover that I can’t edit the /etc/hosts on Lion, it is locked (if you do the “clean installation”).

    • Styx says:

      sudo vim /etc/hosts

    • Ville Hising says:

      You can still do it via Terminal, it’s just GUI apps that seem to have been locked out.

      • Sandy says:

        Re Ville Hising’s comment: That’s been true since about 10.6.0. “consumer”-type (i.e. GUI-centric) users can’t change (or even see) most system files, while “developer”-type (i.e., terminal-centric, as root) can. That’s a reasonable way of protecting your system from casual damage.

    • Matthew Frederick says:

      Non-Mac App Store apps can still access hosts, e.g. non-MAS BBEdit or TextWrangler.

    • Sam says:

      Just FYI this is a good thing. If a nefarious application running with your privileges decided to change /etc/hosts before 10.6 there was nothing stopping it. Requiring superuser privileges for /etc/hosts is simply a good idea.

  8. Ben Nicholas says:

    Many of the issues you bring up are actually anticipated and addressed by Apple. The concept that Apple is going with in the future is that applications are going to become constellations of services around a single application that does pretty much only UI. This is so that, for example, if there is a security issue in a web client, it can’t trash your filesystem because it doesn’t have access. The sandbox model in general has worked very well for them on iOS, so they have decided to start using it on OS X. Since there are other systems to interface with, they can’t use an identical model, which is why they’re including XPC. Apple sees XPC as a big part of their security plan going forward, and it addresses many of the problems you have with sandboxing. I admit I’m not sure how plugins are going to work in concert with sandboxing and XPC, but I’m sure there were discussions internally at Apple.

    • pauli says:

      Currently XPC can’t be used for plugins, because XPC services must be located within the host app’s main bundle and they must be appropriately code-signed.

      I’m sure the issues have been discussed internally at Apple. But isn’t it entirely possible that the conclusion of those discussions is that this functionality won’t be supported in the future? (This happens all the time at Apple. Look at Final Cut Pro X for an extreme example of this kind of rethinking process.)

      • foljs says:

        Look at Final Cut Pro X for an extreme example of this kind of rethinking process.

        Can’t we please stop that idiotic meme? Apple didn’t “dumb down” FCP X, and it didn’t “cut features to make it more consumer friendly” or whatever.

        Instead of pushing an incremental update and charging top dollar, like Adobe usually does, Apple spend tons of money, engineering time and effort to REWRITE the bloody old FCP codebase to serve as the basis for the next stage of FCP development. Essentially, it’s a new program.

        Yeah, FCPX misses some old FCP features. You can *never* deliver everything on a 1.0 version. Instead of pulling TextMate 2.0 and having us waiting forever, the got FCPX out of the door. Coming versions are gonna be even better and features will be added. Remember how people complained when OS X replaced OS 9, and lacked some of their favorite features?

        That’s why you rewrite from scratch actually, to make the codebase easier to add additional features.

        • pauli says:

          I didn’t write anything about “dumbing down”. That’s your interpretation.

          FCP X lacks some features from FCP 7, and Apple is not going to add those features back. This happened as a result of rethinking the app’s workflow and target market. (Software features are not absolutes, everything comes at a cost. To a different group of users, the simplification of certain things is a feature in itself.)

        • Mike Sanchez says:

          Ask any seasoned developer and they’ll tell you that “rewrite from scratch” is one of the highest risks you could take with a popular and seasoned application code base.

          9 times out of 10, a “rewrite from scratch” is a last resort tactic to solve a major flaw or problem (real or in FCP’s case, maybe just imagined) with the application that the publisher/maintainer felt needed to be addressed.

          • Darcy McGee says:

            Well, Final Cut Pro 7 was a 32 bit app, so that could be considered the fundamental flaw that was addressed.

            It was also based on an decades old “filmstrip” metaphor that’s increasingly irrelevant as more and more production goes digital. Arguably that’s a fundamental flaw that was addressed. It’s also the one that’s annoyed quite a few people…namely the very vocal ones who are still working under that old model.

          • mafro says:

            Fred Brooks, The Mythical Man-Month:
            “The management question is not whether to build a pilot system and throw it away. You will do that. Hence plan to throw one away; you will, anyhow.”

          • As a seasoned developer, I happened to have a strong opinion on this.

            Rewriting a code base, more often than not, greatly enhances the maintainability of the code, if done in a way that learns from old mistakes.

            However, it doesn’t make business sense. It takes a lot of time, and thus resouces, and should never be done while in a features race with a competitor. Example: Netscape vs IE. Netscape lost this race completely after a rewrite. (The cleaner codebase did, however, help produce Firefox)

            So, I think Apple just bit the bullet on FCP and did what they thought was best in the long term interest of the codebase.

            I wish more big players would sometimes sacrifice short-term business sense, and do something good for the future.

      • matt says:

        XPC services does not have to be located in the app bundle. There are essentially 3 types of XPC services: application, user and system services. The latter two are placed in stand alone containers and started using a launchd plist file. There is certainly a lack of documentation in this area, but you could probably roll up a “plugin XPC service”, where the service itself manages different plugins (or have the user name each service plugin that you want to use in your preferences).

    • Alex says:

      “The sandbox model in general has worked very well for them on iOS”

      In one sense, it has: for them. Has it worked well for users or developers? It’s hard to say. I’d love to use my own app on iOS, but I’m developing for a different platform because what I’m building wouldn’t be allowed in the iOS sandbox. How many other apps would have been built or bought there if allowed? What other markets might have been disrupted if Apple had allowed iOS devices to do so?

      Square cleverly worked around it by building a hardware extension. This works for them, because the existing CC-processing hardware is far bulkier. For a pure-software solution, though, it’s a non-starter. If Apple had banned Square and we’d never heard of them, would we still say that Apple’s policies worked well? Sure. How could we have known?

      • Darcy McGee says:

        iOS doesn’t HAVE a filesystem, per se, so there’s there.

        Aperture has taken to deleting my master files that it’s storing in it’s own file right now. My solution? I’m back to storing masters externally.

  9. This isn’t an Apple specific thing. Microsoft too is requiring sandboxed applications for Window 8 Metro-Style apps distributed through their store. They require developers to justify and Microsoft to approve any access to resources outside the standard sandbox set. Seems like this is the next step in basic user security but what’s the cost?

    • “Well, it must be okay because Microsoft is doing it, too!” Uh… not the most compelling of arguments.

      The issue, IMHO, for most devs is the moving target of what’s deemed “appropriate” by the curators or whatever they’re called. The Mac App Store is supposedly “the future” when it comes to software distribution. Forcing devs to beg permission to put something as basic as an Open/Save dialog into their apps seems ridiculously restrictive. Putting that much power into the hands of a relative few is dangerous. The horror stories of iPhone devs having their apps accepted and later capriciously rejected or pulled from iTunes is proof of that fact.

      I’m with pauli on this one: this news is indeed sad.
      -MC

      • JBishop says:

        “Forcing devs to beg permission to put something as basic as an Open/Save dialog into their apps seems ridiculously restrictive. ”

        What is this about? I got permissions (entitlements) by checking a box. How hard was that?

        Are you a Mac developer? Have you tried sandboxing an app? Thought so.

        • pauli says:

          Are you a Mac developer? Have you tried sandboxing an app?

          Speaking for myself, yes and yes.

          You’re missing the point. The problem here is not the difficulty of requesting the entitlement at present. The issue is with the notion that it’s Apple who decides whether an application deserves file I/O permissions or not.

          What is now a simple checkbox could just as easily become a “special entitlement on a temporary basis only”; for example, if Apple were to decide that deprecating the file system is a great way to push developers to adopt iCloud… There’s plenty of precedent about these kinds of moves. (Remember Carbon 64-bit, which was recommended at WWDC 2007 and eradicated the next year?)

  10. Pingback: Mac app store, soon to be as locked down and as annoying as the ios app store | Justifiable Means

  11. Jon Moses says:

    That list of entitlements seems _super_ small to me. I’d be marginally ok if the list of entitlements was exhaustive, _and_ that I, as a user, was responsible for deciding if I was ok with the permissions an app needed. You know, like the android market does. “Hey, this app wants to do, X, Y and Z, that cool?”

    This is just….obnoxious and the totally wrong direction that I’d like to see the app store go in.

    • Giovanni says:

      Quite frankly, are you really reading through all the permissions for each Android app, even when the annoying step is required when updating an app that changed its permission compared to a previous version? The security model that offloads the burden of responsibility on the end user has proven to be fairly ridiculous since the obnoxious Vista days. The “do you *really* want to do that”, “are you *sure* you accept that”, is annoying for both advanced users and casual users. The former will reasonably, or even not reasonably, assume to know what they’re doing, and the latter will never be sure if they really want to this or that. As a result, it’s pure annoyance with no added value. Let’s make safe apps that do not bother any end user but only require proper agreements, discussions and efforts between developers and vendors. Customers first (OK, maybe not the geeky customers, but the growing proportion that just want to “do this, see that, meet them”, which are also the ones extending a market that’s never been this large before).

      • JohnFen says:

        “Quite frankly, are you really reading through all the permissions for each Android app, even when the annoying step is required when updating an app that changed its permission compared to a previous version?”

        Yes.

        “As a result, it’s pure annoyance with no added value. Let’s make safe apps that do not bother any end user but only require proper agreements, discussions and efforts between developers and vendors.”

        I couldn’t disagree more, for two reasons:

        First, my idea of a “safe app” and the vendor or developer’s idea are, in practice, often very different. For example, if an app needs access to something that isn’t required for it to do its job, it’s unsafe in my book. Apps that “need” internet access for no reason other than to phone home, for example.

        Second, this removes me from having control over my machine and leaves everything up to the whims of the developer+vendor. And history shows us that’s a dangerous position to be in.

        The app store business is the primary reason that I am not interested in owning an iPhone or iPad. It makes me feel to exposed to forces that I have no say over. Much better to let me decide whether or not the app is acceptable to me.

        I understand Apple’s reasoning: they’re aiming their products to people who aren’t actually interested in getting the most out of their machines and don’t want to have to think about it. That’s a valid, if limited and (in my opinion) a little sad, market.

  12. I think Apple will extend the entitlements if they see fit. They of-course wouldn’t want to see an empty App Store.

  13. More reasons why I will abandon Apple and terminate a relationship that began in 1986. Their increasingly arrogant attitude and determination they they will actually own your computer and everything on it is unacceptable. I’ll be using something else and someone else’s products. I own my system and all the applications, and files on it. My music, videos, and other files are mine to do with as I want.

    • Trusst says:

      “My music, videos, and other files are mine to do with as I want.”

      Or as whatever PeeCee hacker / malware vendor wants.

  14. Josh Peters says:

    What a downer article. I think you’re overlooking many of the gains the platform gets from sandboxing.

    Firstly, it will be terribly difficult for a rogue process to harm the customer’s computer. This is a good thing. The more customers can trust that apps installed via the store won’t ruin their system the more they will install (and spend on apps).

    Secondly, it is a good thing that Apple starts the offering of entitlements slowly. Adding new entitlements is far easier than removing ones that shouldn’t have been granted in the first place. Any API designer worth their salt can tell you that it’s far harder to get developers to stop using calls. From a business perspective, no one rewrites their software to make use of new technology if the old technology still brings in revenue. See Adobe’s transition to Mac OSX for strong evidence of the difficulty of such “battleship steering.”

    Thirdly, you assume that Apple won’t be adding in calls to make hardware more accessible. I believe this to be false. I would expect Apple to offer (most likely non-DMA access) calls to hardware in the not too distant future, especially in light of their new Thunderbolt technology. Making support software distributable via the app store benefits customers as well as Apple, so expect that policy to open up more than it closes.

    Fourth, the concept of sandboxed apps is essentially one big plugin API. Plugins may be going away, but sandboxed apps will be opening up more APIs to each other, which is a good thing. Encouraging abstractions between apps allows developers to update old architectures without as much fear of breaking third party integration (and pissing off customers).

    In summary, sandboxing is good for the customer, encourages proper API definition and is good for the Mac ecosystem.

    • pauli says:

      Fourth, the concept of sandboxed apps is essentially one big plugin API. Plugins may be going away, but sandboxed apps will be opening up more APIs to each other, which is a good thing.

      What mechanism are you referring to? How will sandboxed apps offer services to each other?

      • Josh Peters says:

        I believe XPC will be that mechanism for allowing apps to communicate to each other via their published boundaries.

        • pauli says:

          Currently XPC is very explicitly intended only for communicating with lightweight child processes. Do you think this will change before 10.8?

          • God of Biscuits says:

            Says who?

            From the Lion docs:
            “The XPC Services API, part of libSystem, provides a lightweight mechanism for basic interprocess communication integrated with Grand Central Dispatch (GCD) and launchd.”

            The *mechanism* is lightweight, not the services. The processes/services you create are child processes, but XPC can communicate with just about anything that has a CFBundleIdentifier. You just have to state up front statically which bundles you’re going to be talking to, like BSD.

          • pauli says:

            I’m not convinced. The “Creating XPC services” document clearly says that services are not available to other applications:

            By default, XPC services are run in the most restricted environment possible—sandboxed with minimal filesystem access, network access, and so on. Elevating a service’s privileges to root is not supported. Further, an XPC service is private, and is available only to the main application that contains it.

  15. w0utert says:

    Correct me if I’m wrong, but my understanding of the sandboxing of OS X App Store applications is that it is not mandatory and entirely up to the developer to choose whether an app runs in a sandbox, or unprivileged. Unless I misunderstood what I’ve read about it, this would invalidate all of your objections.

  16. Andrew de Andrade says:

    AFAICT they are applying OAuth style “permissions” like those for Facebook apps, except instead of the user deciding what permissions are acceptable Apple does for the sake of user experience.

  17. Carl Youngblood says:

    Whatever policies Apple sets up for the App Store will become the de facto standard for all applications. Apple no longer has a strong incentive to update and maintain their existing system API calls or even keep them public. In fact, they have a strong incentive to do just the opposite, so as to coax developers to build app store apps instead of full-fledged system apps. The writing is on the wall. When the time is right, Apple will probably drop the ability to install apps outside of the app store altogether. Even if it doesn’t, there is no doubt that most apps will want to be on the app store and will therefore need to comply with the requirements, and it is unlikely that app developers will have the time or interest to maintain two separate versions of their apps.

  18. Pingback: Sad About Sandboxing

  19. I’m really surprised at all the “not so bad” comments I’m seeing here. I absolutely agree with the poster. The draconian restrictions (such as sandboxing) are the reason I abandoned iOS and got an Android handset.

    You have far more useful apps when there are no restrictions on what they can do. Look in your status bar at the top of the screen, that should give you an indication of what will be impossible with sandboxing.

    -Quicksilver? Impossible.
    -Flux? Nope.
    -Dropbox? Probably not.
    -Growl? Fuck off.

    It always amazes me, the capacity of people to not get angry at Apple for completely inexcusable shit.

    • foljs says:

      You have far more useful apps when there are no restrictions on what they can do. Look in your status bar at the top of the screen, that should give you an indication of what will be impossible with sandboxing.

      I don’t see any of those apps as “impossible with sandboxing”. Tons of apps that do even heavier stuff are already on the App Store, and I don’t see Apple suddenly enforcing sandboxing and removing tons of previously available (and already bought by millions) apps. I also don’t believe that the final set of entitlements will be those presented here.

      • Mark Munz says:

        Apple gives no indication whether any new entitlements will be offered. You’re assuming a lot, given that they haven’t made any changes in entitlements from the original announcement, ~6 months ago.

        What may likely happen is that these types of apps just can’t be updated by the developers. So they’ll die just on the vine. The list Aaron gave is pretty small, I know there are LOTS more apps that fall into this grouping, my own included.

        Interestingly, Growl will probably still work — just that any apps that try to post a growl notification likely won’t make it past the sandbox. So they’d make Growl virtually useless.

  20. Steve Parkinson says:

    Since you’ll still be able to distribute unencumbered apps outside of the app store, why not create a competing app store for ‘the rest’ of the apps that need the additional privileges. Hmm not a bad idea. Maybe I’ll do it, and I’ll only charge a 5% fee instead of apples 30%

  21. Apple is playing divide and conquer here. They can’t simply say every app from here on out will be sandboxed; the outcry would be enormous. So instead, they’re targeting apps sold in the app store, which is a small but growing chunk of the Mac market. Most independent developers are not going to want to maintain two code bases, and since they also would (sensibly) want to sell through the app store, they have no choice but to comply. Thus, Apple gets a much higher rate of compliance without ‘forcing’ anyone. A little further down the line, after the most important apps are sandboxed, then Apple may just decide to lock down the platform and force ALL apps to be sandboxed AND sold in the app store.

    There, in a nutshell, is how the coup plays out. It is how we go from open desktop platforms to closed ones.

    I’m not going to comment on the wisdom or motives for sandboxing. It has been both good and bad for IOS, but I stand firmly in the camp of those who decry it as a loss of freedom and a dangerous power grab.

    Is there no other way of accomplishing the ostensible purposes for sandboxing, perhaps one that serves the Apples interests less and serves computer users more?

    The sense of dread I experienced when I saw the IOSification of MacOS in Lion only increases by the month.

    • Bill says:

      Apple may just decide to lock down the platform and force ALL apps to be sandboxed AND sold in the app store.

      This was definitely the path Apple was going down while Jobs was in charge. With him gone, Apple could change directions.

      • They could change direction, but I doubt they will. It’s a gambit that may backfire, but the potential earnings upside is enormous. Moving to a closed platform means Apple is making a play towards grabbing a piece of every transaction that happens on a Mac, in just the same way they presently do under IOS.

        I seriously doubt Apple’s board would be in favor of reversing course, especially when Jobs himself was the one who steered the boat in that direction in the first place. In death he has been transfigured, from living legend to demigod, which makes the orders he gave while living very difficult to countermand.

        • foljs says:

          but the potential earnings upside is enormous. Moving to a closed platform means Apple is making a play towards grabbing a piece of every transaction that happens on a Mac, in just the same way they presently do under IOS.

          You do know that the don’t make that much money on iOS app, don’t you? Mostly on hardware (iPhones, iPads and Macs). So where exactly are the “potential enormous earnings” if they do the same on OS X?

          Also: don’t they already do the same on OS X? I.e don’t they take a piece of all App Store sales? If that was their motive, the wouldn’t introduce “entitlements” and extra restrictions that force developers to take their apps outside the App Store.

          • jpbaril says:

            When they will get the monopoly of app distribution on macs, they will be in a position to take every piece they want.
            And yes they already take (little) money from every purchase in the app store, but those sales are still little in proportion of sales taking place outside of it. With a monopoly, little money rapidly becomes even big money.

          • I’m not speaking strictly of their earnings from IOS apps, I’m talking about the entire e-commerce ecosystem within IOS: in-app purchases, advertising, iTunes media sales, app sales, and so forth. If Apple’s 30% were inconsiderable, they would’t even be in that game.

            Apple hasn’t been a pure hardware company for nearly a decade.

      • Darcy McGee says:

        Doubtful. They’d lose the creative professional apps, and a hugely vocal and supportive audience with them.

  22. fjpoblam says:

    Tinfoil hat, here, with abounding ignorance. If Apple begins curating the MacOSX platform (the software which may run on it, the permissions and files to which that software has access), then what platform will developers use to *develop* software for the MacOSX platform?

    • pauli says:

      Not sure how these things are supposed to be related. Apple can sell SDKs (“developer program memberships”, I mean) regardless of how open their platform is.

      If they wanted, they could make Xcode for iOS, with direct publishing to the App Store. That wouldn’t make iOS any less of a wall garden.

      (By the way, it’s bizarrely rude to call me “aboundingly ignorant” when you’re posting to my blog. Sometimes I wonder if efficient communications technology has completely eradicated the concept of manners for some people.)

  23. Jaap says:

    If you boil a frog slowly he will not jump out of the cooking pan. You are slowly being cooked ………….

  24. Pingback: Michael Tsai - Blog - Why the Mac App Sandbox Makes Me Sad

  25. Andrew says:

    I too wrote an article with much the same questions earlier today. I can understand the need for security but on the other hand turning my Mac into an old fashioned locked down mainframe isn’t very appealing.

    As a developer I wonder how development tools will work in the future – and the command line. If everything is locked down unix *has* to vanish. If the only tools allowed are Apple’s then the platform becomes frustrating to work with. With Windows 8 going the same way the only platform left is Linux which may not even have popular hardware to run on any more.

    Not a fun future, this.

  26. David Stewart Zink says:

    At the very least they need to make an entitlement to write arbitrary files to permanent storage in some user-approved directory with some user-approved maximum amount of disk-space used. They need to make plug-ins workable (not 100% sure they haven’t). They need to make downloadable content possible.

    Many single usable objects (identified to theuser as single objects) actually consist of many files; the /Applications directory is full of such. We can’t require user approval for each individual file. The fact that we can work around the limitations by going around the app-store is no excuse. The fact we need to work around the limitations means they are doing it wrong.

  27. Yoz Grahame says:

    This whole trajectory makes sense when you look at it with a perspective of what Apple’s priorities are: Apple is a hardware company. Its primary business model – irrespective of the money coming in from its various online content stores – is based on hardware sales. And Apple’s #1 priority in the design of its products is that the user experience should be as smooth, comfortable and empowering as possible.

    The argument here rages around the “empowering” part. Apple’s take is that additional functionality isn’t worthwhile if the quality of experience around that functionality isn’t pretty much guaranteed. Third-party software that can clobber the overall user experience for the rest of the product (for example, Sparrow eating my CPU and making everything else run at a crawl) is a major problem. All OSes now have some protection around this, but Apple is pushing Mac OS much further, in the direction it already sees working very nicely for iOS. And, to some degree, Apple’s OS engineering priorities have worked this way ever since the original Mac OS ensured that the mouse pointer would pretty much always move smoothly no matter what else the machine was doing. (If your mouse pointer stops moving on OS X, you know something’s seriously b0rked.)

    There’s no question that moving things in this direction makes things harder for developers. (Though, at the same time, it also somewhat reduces the variety and severity of bugs those developers have to deal with. I’m looking at you, game developers who’ve accidentally wiped people’s hard drives with a rogue installer bug.) The question about user empowerment is the more relevant one, because people take this as being just about functionality being removed.

    How about this for user empowerment?

    * Not having to hunt & kill rogue processes/plugins that are preventing you from getting anything done
    * Not having your work eaten by a badly-coded app that has access to the same document space
    * Not having to devote a chunk of your much-demanded cognitive energy to simply making your computer do what it is actually meant to do
    * Not having your life ruined by identity-stealing malware

    These are the problems that Apple has set out to solve, right from the start. These are the problems that affect far more people than “my home screen isn’t configurable enough”. I’m not saying that they’re solving this the right way – they’re writing software, and all software has bugs both at the design and implementation levels.

    It does genuinely frustrate me that I can’t configure my iPhone’s home screen the way I want it without jailbreaking. Also, the idea of Apple taking a guardian position around its platform that we have never seen the like of before, and which it has repeatedly shown itself to be only kind-of-okay at when it comes to managing, is deeply worrying. I don’t know that Apple will do it right; you can’t please all of the people all of the time, and I’m sure they’ll drop some major clangers along the way if not utterly screw up the whole thing. Plus, you know, they’re a capitalist company; they’re not doing this out of the goodness of their hearts.

    But the point is that there is a proper user-centric justification for all this. And if you don’t believe me, please: before you respond, have a flip through this PDF:
    http://www.cs.auckland.ac.nz/~pgut001/pubs/malware_biz.pdf
    That presentation is now 3 years old, which means things have probably advanced considerably since then. If that doesn’t scare the living shit out of you, you’re not paying attention properly. Right now OS X is considered by most in the infosec industry to be less secure than Windows 7, and when malware writers and other black hats start giving OS X proper attention, it’s going to be head-for-the-bunkers time.

    Apple’s continued success at creating new classes of devices comes from them understanding the fundamentals of what most people want and need. What makes them happy, what keeps them safe. Their obsession with UI latency, for example; something that has taken the rest of the industry far too long to understand and match. Maybe you don’t think you share these obsessions (though you’d be surprised at how much, underneath, you actually do). But most people do, and if you want to sell them your software, you’d better get used to that.

    • I appreciate what you’ve said and I agree that great user experience is part of what Apple wants to bring to its products. It’s one of the major reasons I use and continue to recommend Macs to my long-suffering PC-using friends when they’ve had enough Windows. But there are in my opinion lines that shouldn’t be crossed. The trajectory of this change leads towards a closed platform, which requires that I become a custodian of a device I don’t control, and place a large part of my life in Apple’s trust. I believe most people would wisely accept the risks of self-custodianship rather than cede such a level of control. Sadly, they may not have that choice much longer.

      ‘Proper user-centric justification’ is just another way of saying this is for your own good. I think I’ve heard that one before.

    • Wilfred Hildonen says:

      Allow me to post the view of a non-technical person such as myself. I think so far Yoz Grahame is the one who best has understood what is happening and what is Apple’s intentions here. I can only speak from an end-user’s perspective and not from a developer’s, but as a user of Macs since 1998, I have been following the development and read up on the history of personal computers, as it is rather fascinating.

      Now, as a user and a creative one who have been using these machines on a daily basis to produce work, from image to text and video and sound as well, graphic design and articles etc., I haven’t felt much need to configure my home screen or anything like that. I see a computer as a tool with which I do my work, not something I want to work on. But as we all know, from time to time, one is forced to do so, just like it was the case with cars once upon a time, if your wallet didn’t permit you to call the garage each time you ran into trouble. So, up with the bonnet and dive underneath it with a spanner in one hand and a screwdriver in the other.

      But that was never my fabourite way of spending my time. I wanted a car which would start when I turned it on and which would take me there, wherever there was. The same goes for computers.

      Developers see it differently. For you the computer is more than a tool. It is your working area. And you are afraid that Apple will close the door in your face and forbid you to enter, as I understand it, just like you cannot just fix a car today like you could a couple of decades ago. It takes more knowledge and one need to invest in advanced and expensive equipment etc. etc. But me, I prefer today’s cars to the ones I had in those days.

      I think this is how Apple sees it; the days of the hobbyists and hackers are over. The OSes as we know them today, belong to the past. We all know how messy they actually are with lots of holes in them, through which scary monsters and super creeps may come crawling. So Apple has set course for the future, but as Yoz Grahame points out; it is not for sure that they will get there.

      Another mentioned the risk involved in rewriting something from scratch. Yes, that is what Apple has been known to do; take risks. It is of course a dangerous game, but if you want to get somewhere, you mostly need to take risks. If you are content with status quo, you don’t but then you run another risk, the one of stagnation.

      As for plugins or apps talking to each other; I think I see that happening already on the iOS to some extent. I am thinking of how I can work with images, jumping from one app to another. Perhaps today there is a very limited list of APIs presented, which would allow apps to communicate, but isn’t that too typical Apple-strategy? First you have a rather limited implementation and then you see how it works out before you add features.

      I know that Apple runs a business, but I still don’t think that they’re main objective is to lock users in, just for the sake of it. As I see it, it isn’t their fault that they are the only company in this area which follows such a strategy, but if you look outside this area, then it seems to be the norm. Cars, dishwashers, TV-sets, hoovers, cameras. If you buy a product, you’re “locked in”.

      But, as a normal user, I feel I am just as locked in with Windows. Yes, I can have a huge variety of hardware but the OS is the same all over. The same user experience wherever I turn. The only difference is that the prison is so vast that the prisoners seldom discover the walls which prevents them from leaving.

      And finally, to Reconsidering Digital: Apple always seems to be crossing the lines it shouldn’t have:)

      OK, this has become far too long, but that is my twopenny worth:)

      • Chris says:

        “”Cars, dishwashers, TV-sets, hoovers, cameras. If you buy a product, you’re “locked in”.

        Huh? When was the last time Ford told me where I can drive my car?
        When did my washing machine start rejecting TShirts that wern’t cool enough?

  28. Bjørn says:

    This is actually part of a natural experiment. Apple with Jobs and Apple without jobs. Apple started with Jobs and it was a great success. Then it had a period without him and it did very badly. Then it had a period with him again and did even better. Now they will forever more be without him and we’ll see how they fare.

    Apple has bent on closing things up as much as possible for a loong time. With Jobs that urge has been balanced by incredible performance on other parts of product design, but if they are going to continue down the path of closing things up they -must- be -incredibly- innovative on other issues to balance out the evil they introduce by closing up the machine.

    Personally I don’t think they’ll make it. I think they will screw up. Apple was built around Jobs’s genius and now he’s gone, so the Apple we know will wither away. I’m in no way happy about that. I like Apple’s current crop of products very much, but I have serious doubts that I will be as enthusiastic about the lineup they’ll have in say three years time when Jobs’s direct influence on project in production or development will be mostly gone.

    • Snafu says:

      Actually, Apple without Jobs did very well for a long while. It could be argued that the Macintosh survived thanks to decisions that went far beyond Jobs’ scope for the platform. My hope is that mid-long term we get some balance back, although I’m not hopeful.

  29. user says:

    Mainframe. Someone said it upstream. Brilliant. Captures the full sense of the direction. Apples 1984 ads will be historic ironies …

  30. Pingback: house of insanity and opinions » add this to the reasons I don’t want a mac anymore, the iphone won’t be far behind.

  31. Vance says:

    This is an absolute disaster, it really is. Applescript is, for all practical purposes, dead. How can Automator or Apple Events work in the sandbox? What happens to applications whose entire POINT revolves around taking data from one application and putting it in a different form? Think of addons for photoshop or Word; Excel, etc. Can you talk to a database and get data from, say, a mysql process? Without building your own freaking copy of mysql inside your application?

    Browsers: Can you open a webpage in Safari from your application in this brave new world of sandboxing? Sure, with a “temporary entitlement.” That is supposed to go away. Basically, and in short, the sandboxing means the death of using applications together. Heck, can you even access the clipboard that has data on it from another application? This is a disaster of epic proportions, and I’m sure Apple knows how much of one it is. That’s why the deadline went to March instead of november.

    • Paul Tuckey says:

      Agreed. The loss of AppleScript would be a disaster. It’s unique ability to script many applications together to create a digital workflow or meta app is one of the main features that separates OS X from the rest.

      Only this summer I developed for a well known IT training company an AppleScript which enables their FileMaker Pro DB to create, update and delete iCal appointments. Take this ability away and I can see them questioning the use of FileMaker and Mac’s in their organisation.

    • Bernard SG says:

      In case you haven’t noticed, neither Microsoft Office nor Adobe CS are sold on the MAS.

  32. Ted Howard says:

    Apple has always put the end-user first. They have never indicated otherwise. Developers are therefore second-class citizens at best (Jobs didn’t want apps on iPhone). Don’t ever be surprised if Apple makes decisions that hurt ISV’s.

  33. Erik P says:

    The AppStore is additive. Developers can do what they always have. Release a boxed version in the app store and a full and trial version on your website, same as you do now or pretend the AppStore doesn’t exist like you did a year ago.

    Better yet, design and write conforming apps. They aren’t doing this arbitrarily. OSX is becoming iOS not the other way around. Consider it foretelling the future. Lament the death of the PC if you want but the times, they are a changin.

  34. Pingback: Sandkastenspiele: Generativität, Innovativität und Apple « the business web

  35. Abe Pazos says:

    This and other news confirm I did the right thing when I got rid of my iMac a few years ago and switched to Free Software. At the same time I find it troubling for all those Apple fans who will some day have a computer like this and still believe it’s the best thing ever :)

  36. Somehow it’s hard to sympathize… that’s what you get for using a closed, proprietary platform where you depend on one single vendor: Nothing prevents that vendor from suddenly being a dick.

  37. so, let’s say i’m really happy with using the built-in option of cyberduck to edit html-files with smultron, saving in smultron, cyberduck taking care of the instant upload and stuff, this is not going to happen with these restrictions, right?

    what about using fw-audio-hardware? damn it, i’ve bought this stuff for quite a lot of money, and now i won’t be able to use this hardware with logic? what about plugins for logic? not going to happen?

    this is insane!

    • Webby says:

      He’s being overly dramatic. Rest assured, Logic Pro is in the App Store, and still supports plugins.

      Logic Pro plugins these days are technically Audio Units, a plugin architecture used by Core Audio, and not specific to Logic. Thus, any application can use them, even in the sandbox.

      The plugin must either set the “sandboxSafe” key, or must declare if it uses the network, the filesystem, Mach names, and so on. It’s exactly analogous to the entitlements system for apps.

      Finally, if you want to write an app that supports user customization, that’s still allowed, as long as you use one of the acceptable mechanisms, which basically amounts to “not binary code from an untrusted source” (which would obviously defeat the purpose of the sandbox). Make your app Applescriptable, or give it a way to run user extensions written in Javascript, or some other safe mechanism. This won’t handle every case but will definitely cover the “workflow” scenarios mentioned above.

  38. Andreas T says:

    Are you sure that the information you present here is really well founded? Last time I checked the sandboxing system you could write your own entitlements using tiny scheme programs, exactly specifying filesystem access, mach access, etc.
    Are you saying that Apple is not allowing that for Apps on the Mac Apps Store? If you’re only speculating, then what you wrote is certainly not very trustworthy.
    Also, I know for sure that Plugins will be supported on the Mac App Store in the future, as I’m involved with their development.

    • pauli says:

      Last time I checked the sandboxing system you could write your own entitlements using tiny scheme programs, exactly specifying filesystem access, mach access, etc.

      Maybe I’m missing something (I’d be happy to admit I’m wrong). The App Sandbox Design Guide document makes no mention of such a capability. Instead, it is quite explicit that file access outside the app’s container is only available as a temporary exception entitlement. These exceptions are available only if App Store review judges it necessary, and the exceptions are going to be phased out as soon as possible.

  39. Hamranhansenhansen says:

    These things make users happy. On Apple platforms, the users are paramount, not the developers. Developers work harder than on other platforms, but they also make better apps with a better user experience, and they have better opportunities for monetization in many cases.

    If there are missing entitlements, those will become apparent. Developers have to let Apple know when the lack of an entitlement is a problem.

    The comments here that rant on about how Apple is closing stuff for their own benefit show psychological damage from Microsoft or Google platforms where carriers and generic hardware vendors are paramount, and there are always corporate dirty tricks. With Apple, everything is about pleasing the user, so that they will generate a repeat device sale or generate buzz that brings in new users. There are no dirty tricks. It is totally transparent. It’s kindergarten business: please the customer. The user pays the bills on Apple platforms, not carriers or generic hardware vendors. The reason for the sandbox is: users want it.

    So for developers, this is just a technical challenge. We have to work with Apple to bring users this kind of security, which the majority of users definitely want and in many cases already think they have. That is our responsibility to our users.

    • JohnFen says:

      These things make users happy.

      Correction: These things make some users happy. They make other users unhappy.

      The problem I have with all of this isn’t that it complicates development. It’s that I, as a user, am no longer in control. This makes the machine less useful.

      There are no dirty tricks. It is totally transparent. It’s kindergarten business: please the customer.

      I believe that you are being entirely too naive here. Apple’s history includes lots and lots of dirty tricks and bad corporate behavior. There is no reason to suspect they have suddenly become nice guys.

  40. ralph says:

    The best thing strategically (for Apple) that could happen now is a big virus/malware attack on OSX, then they would finally have a reason and justification to lock down OSX and make MAS the only way to install applications. All the pieces are already in place in OSX, they just need to flip a switch and the move would be applauded by the masses.

  41. Pingback: Apple's Mac OS Lockdown To End Developer Independence - Forbes

  42. Pingback: Apple Neuters Mac App Store Software | Internet App developer support forum

  43. Keith Cromm says:

    This *IS* a bad thing.
    Steve declared this as his long-term focus / intentions the very day he returned in 1997. I left Apple that same day . I didn’t care to ‘report’ to a total communist-minded freak wanting control over every area of your (developer and/or end-user and/or employee) life.
    However, the challenge is, the more pervasive the Mac becomes (market-wise / percentage-wise), the more developers will want to develop stuff for the Mac.
    Enter Windows and/or Linux developers.
    In order to have an “orderly” product, per se, one that doesn’t have apps doing all kinds of things on the Mac whenever and where-ever they want, the “entitlements” are going to be implemented.
    Your power-users won’t like the idea of limited/dysfunctional apps. However, the general populous user won’t give a hoot as long as things “just work”.

    Makes me wonder if anyone is gonna organize an “Occupy Apple” event….

  44. David W. says:

    I am in favor of sandboxing. Each year in the Pwn2Own contest, Charlie Miller has been able to take control of a new Mac in seconds with security holes he’s found in Safari’s rendering engine. This is because pre-Lion Safari’s rendering engine has full access to the entire machine. This year, Charlie Miller turned his attention to the Mac’s battery because Safari has sandboxed its rendering engine. It no longer has access to all the system resources, thus has rendered Miller’s strategy in the Pwn2Own contest.

    You claim that applications will no longer be able to talk with each other, but Growl is living happily in the App Store. Yes, grants are a pain and it will take a while to learn to use them. However, I remember when the first Macs came out and developers were upset they were suppose to talk to the printer and disk drive through a system wide driver. Or when memory protection and preemptive multitasking became a standard part of operating systems which meant we couldn’t peek and poke memory like we use to.

    • pauli says:

      AFAIK, Growl uses TCP sockets for communication, so it’s compatible with sandboxing. This a great solution for notifications because they are small data packets without critical latency requirements. Only a small subset of interprocess communication needs can be solved like this. (Everyone probably agrees that it’s not workable if e.g. image processing plugins would be required to talk to the host app over a network socket.)

      With the examples you mention, system-wide drivers and preemptive multitasking, it was clear that the advantages clearly outweighed the disadvantages, as those services enabled developers to build better software. The sandbox isn’t such an obvious benefit for many kind of apps, which is why it’s worrying that it’s becoming an unconditional requirement so soon.

  45. DazzaJ says:

    It again shows Apples ridiculous limitations.
    Apple is a closed system and it seems they want to close it even more.
    I’d be surprised if the Mac range is still going in 3 to 5 years, and this may be part of their plan. Get developers used to restricted and controlled apps with Apple dictating the rules, features, price etc, as they merge the OSX to iOS.
    Slowly limit available features to match the limitations of iOS? – Then THEY have full control, all the way to the bank!

  46. Chris R says:

    First they came for the removable media drives, and I didn’t speak out because I didn’t publish my software on shrink-wrapped media.

    Then they came for the App Store apps, and I didn’t speak out because I didn’t publish my software through the App Store.

  47. George Fuller says:

    In my opinion the important post in this thread is.

    Jaap says:
    If you boil a frog slowly he will not jump out of the cooking pan. You are slowly being cooked
    The majority of the posts in this thread are from developers, I am not, I’m a user and hobbyist coder, you all seem to be of the opinion that users are all simple being’s who all want a computer that is simply an over sized smart phone. For a lot of us this is not the case, it is true that I need a machine that I can use to earn a living and therefore be pretty reliable, hence a Mac. But I also use it for recreation and so want it to be highly adaptable and not restrict the range of my imagination.
    I was most surprised and not encouraged buy the direction that Lion is taking and these extra requirements / restrictions for app store inclusion seem to extend that.
    Up until “SL” I thought Apple had the balance between safeness and freedom about right, if they lock things down further I think OSX will be replaced on my Macbook perhaps by Fusion linux or Mint.

  48. Pingback: My initial reaction to the Mac App Store was pretty negative, I could not see much… | Thomas Cox

  49. Hello! I’m the guy who wrote Acorn, and you link to it (“perhaps take screenshots?”) in your post, suggesting that an app can’t take screenshots when in the sandbox.

    It turns out you can. I’ve got it working in the labs over here at FM, so you might want to correct that little bit :)

    • pauli says:

      Thank you for the correction, and my apologies about the mistake. I’ve updated the post.

      I honestly thought that the screen capture API is not available. Taking screenshots essentially means an app can read the contents of other applications’ windows. This is clearly a security risk in the same vein as opening arbitrary files, so I had assumed that screen capture is disabled in the sandbox.

  50. Hmh, it seems quite interesting to see which way this is going to go, but somehow all this also sounds like a lot of speculation before all of the details are revealed. It could be that they make a really poor implementation of this which might have really, really bad implications of the development of OS X apps, but somehow, call me Apple fanboy, I’m inclined to think that they’re not that stupid. Oh, I know they might do it for the business reasons and I might sadly have to take my business elsewhere, but I sincerely hope the result isn’t quite so grave.

    It’s sad that Apple is so secretive and almost rude to the developer community. I do hope that this is all just really bad communication and that they haven’t just released all the details and are devising a cunning plan how to actually make all this work since generally I don’t mind the sandbox concept as I’m all for protecting the stupid users – fingers crossed.

    Thanks for an interesting read anyway…

    • pauli says:

      It’s not speculation, and the details have been out since July, I think. (The primary documentation is App Sandbox Design Guide on Apple’s Mac dev site.)

      I’ve also been waiting for more information and improvements to the sandbox. But all that has happened so far is the new deadline for the App Store sandbox switchover. No new entitlements, no concept of permanent exceptions that could enable workflows that are crucial to many apps.

  51. Pingback: Thoughts on inter-app communication and Siri-izing Android apps | code zen

  52. Pingback: Sandboxing in the Mac App Store splits developers | ZDNet

  53. Pingback: Apple will lock you out of your computer – soon | Matthew Bloch

  54. Can I request an entitlement to quit other applications that the user knowingly starts? I am currently building a Mac app that does this.

  55. Webby says:

    “Need to access hardware using something else than USB, for example Thunderbolt, FireWire or Bluetooth? Tough luck. (Just because these interfaces are on your Mac doesn’t mean Apple wants anyone to use them via 3rd party software.)”

    The sandboxing system has problems, certainly, but this is kind of a strange problem, on several levels.

    First, the sandbox is only mandatory for Mac App Store apps. If you want out, just sell the app on your own. Lots of people do this, and have been doing it for decades. I have not seen any great migration to App Store-only purchasing.

    Second, Thunderbolt and Firewire both provide (by design) direct access to the system bus. If an app could gain access to these, it could have complete control of the system. (You could read directly from any memory, for example.) Requesting this entitlement would thus essentially be a “no sandbox please” entitlement, and make this entire exercise pointless. If you want to be able to write an app that doesn’t live in the sandbox, that’s fine (see point #1) — you just can’t sell it in Apple’s App Store.

    (Note that the slower “safe” interface, USB, which does not provide direct bus access, does have an entitlement.)

    Finally, Apple does want people to use these ports, obviously — they provide APIs and documentation for doing so. You just can’t do direct hardware access from a sandboxed app, obviously. They want you to write a proper device driver, and then access it through APIs with a (sandboxed) app.

    There are legitimate complaints about the sandbox, but yours are not among them. Your issues amount to “I want to do everything the wrong way, in a way that’s less safe for users and defeats the purpose of having a sandbox at all”.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>