Tuesday, October 11, 2011

Sandboxing and the Mac App Store

In a recent Macworld Editorial, The App Culture, Jason Snell argues that an overly restrictive approach to App security "risks dumbing down the Mac app ecosystem as a whole".

A good example is system preference panes or plugins which are not permitted [Apple guidelines 2.15 Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations].

In recent months, I've seen two former system preferences panes rewritten as status bar items to the consternation of their existing users (PinPoint and Growl). The right hand side of the system menu bar is being over-crowded with "status items" that don't easily fit anywhere else. The status bar is intended for items that need to present system status and be available at all times without disrupting other applications, not as a mechanism for accessing system preferences. Unfortunately, the mechanism designed for accessing 3rd party system preferences is no longer permitted.

My own Phone Amego for example is a status bar item because I don't want to interrupt whatever else the user might be working on each time the phone rings or you want to make a call. Keyclick on the other hand is a System Preference pane because it reflects a system wide preference that runs in the background, not an application you need to interact with frequently.

The problem Apple is trying to solve is how to make finding and installing software safe for non-tech savvy users, but the challenge is how to apply this without dumbing down the Mac user experience.

By limiting what applications are allowed to do, their security exposure is greatly reduced. But some applications need or want to do more, and this is where things get interesting. Apple has already defined a set of "Entitlements" that allow applications to declare specific types of system access or privileges they need to do their job, so the application can be granted just enough access without exposing any more of the system than is necessary. The combination of sandboxing and entitlements defines a contract between the application and the system, so that even if an application is compromised, it can only do the limited set of things it was designed to do and nothing more. The issue is what entitlements to allow in the Mac App Store and how to present this information in a way that allows users to grant their informed consent.

Apple's current policy is to disallow installing plugins of any type, but this might not be the best answer since users can already install any software they want directly. The effect of banning plugins or startup items is to dumb down applications and push developers and users outside the Mac App Store. My own Phone Amego for example points users to a web page where they can download a set of "Phone Amego Extras" to manually install the pieces the Mac App Store wouldn't allow.

The combination of application sandboxing and entitlements could provide a more elegant solution if it is applied carefully. Apple doesn't need to solve the entire problem all at once, but it does need to recognize there are important applications beyond self contained productivity or entertainment, and begin thinking about how to include some of them in the Mac App Store.

To help get the conversation started, I'd like to suggest a rating system similar to the already familiar film-rating system:

   "G"  for General use or everyone

"PG" for Parental Guidance suggested
(security implications should be noted,
such as anything that installs a plugin)

"R" for Restricted
(requires more extensive system access
such as a network or disk utility)

The point here is that Apple could offer a better user experience by allowing a broader range of integrated solutions to be offered in the Mac App Store.

No comments:

Post a Comment

Post a Comment