Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MacRumors

macrumors bot
Original poster
Apr 12, 2001
63,547
30,863



When Apple launched OS X 10.7 (Lion) to the public in July, most of the media focus was on the user-facing changes, such as the iOS-like Launchpad, or trackpad scrolling direction. In Lion, Apple also made a number of under-the-hood changes in their security model that may start affecting Mac App Store customers in the near future.

sandboxing.jpg



Amongst the many new features in Lion, Apple included a more robust sandboxing system that can prevent 3rd party applications from causing unintended damage. In their Lion review, ArsTechnica explains how sandboxing works in general:
Running an application inside a sandbox is meant to minimize the damage that could be caused if that application is compromised by a piece of malware. A sandboxed application voluntarily surrenders the ability to do many things that a normal process run by the same user could do. For example, a normal application run by a user has the ability to delete every single file owned by that user. Obviously, a well-behaved application will not do this. But if an application becomes compromised, it may be coerced into doing something destructive.
Developers of these sandboxed applications must take special measures to break up their application into individual processes that only are able to do exactly what they need. Apple still allows user initiated actions to perform as expected and override the sandbox, but app-initiated actions in sandboxed applications will be restricted. This means that system wide file access and inter-app scripting and interactions will not be allowed.

Apple had originally told developers that sandboxing would become a requirement for Mac App Store apps as of November, 2011. Tonight, however, Apple emailed developers that the Sandboxing requirement will now go into effect on March 1, 2012.
As of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing.
While sandboxing will increase the security of Mac App Store apps, there have been concerns that the restrictions will stifle features and innovation on the Mac platform.

apps.jpg



Mac Apps that may be affected: TextExpander, CoverSutra, Transmit, Fantastical
In October, Macworld published a pair of articles from Jason Snell and Andy Ihnatko expressing their concerns about the new restrictions.

Snell reported that he had heard that some Mac developers will be removing features from their apps or reducing their functionality to fit them in Apple's sandbox.
Not only does this approach risk turning the Mac App Store into a wasteland of arcade games and one-trick-pony apps, it risks dumbing down the Mac app ecosystem as a whole. While developers can always opt out of the Mac App Store, they're reluctant to do so.
Examples of Mac Apps that will be affected include iTunes controllers (Tagalicious, CoverSutra), inter-app communication (Fantastical), apps that browse the file system (Transmit), system-wide keyboard shortcut utilities (TextExpander), file syncing, and backups utilities.

While Apple is offering developers some short term exceptions to get around sandboxing, the company promises that those exceptions will be temporary. Some developers have said there is a lot of uncertainty around how long Apple will allow these apps in the Mac App Store after the deadline. With the new delay until March, some developers are holding out hope that Apple may be trying to come up with a better solution than simply pulling these apps off the Mac App Store.

As Snell points out, developers can choose to distribute their non-sandboxed apps outside the Mac App Store, but those developers would be giving up a huge distribution point.

Article Link: Mac App Store Sandboxing Requirement Pushed to March as Uncertainty Looms
 

Kaibelf

Suspended
Apr 29, 2009
2,445
7,444
Silicon Valley, CA
I'm all for sandboxing. If a dev wants to cry about their "innovation" being stifled because their program only affects what it's meant to, then they can go compromise someone else's machine, because I don't want their crap poking around in my files and logging my keystrokes.
 

Mr Astonishing

macrumors newbie
Sep 3, 2011
13
0
SLC, UT
I'm no genius when it comes to computers, or the whole "sandboxing process," however; I do see that Apple originally told developers they wanted Mac Store apps to have sandboxing as a requirement by November 2011, but all I could think about when I read this post was the Chrome book. I know it's not the exactly the same and I'm not saying Google did it first. I just thought I would bring that up.

http://www.youtube.com/watch?v=U1bzZRxesoQ&feature=player_embedded

EDIT: This will be awesome for the App Store. I'm all for it! Like slrandall said, "More secure, more efficient apps."
 

Stella

macrumors G3
Apr 21, 2003
8,838
6,341
Canada
Absolutely correct - sand boxing is bad for innovation. Already we see differences in the same piece of software that is distributed outside app store vs in appStore - for example 1Password, BBEdit, Drive Genius.. lots of others - the versions in the appStore are crippled vs those outside.

Many existing great software will never be allowed in - due to the functionality they provide, i.e., LaunchBar, BetterTouchTool, PathFinder.

Yes, you can still download from outside the app Store but over time more and more applications will be found exclusively in the AppStore.

Either remove the sand box or lighten up the restrictions.

Mac software flourishes happily at the moment without sand boxing... almost all ( read 99.99% are safe - a handful are not ).

I'm all for sandboxing. If a dev wants to cry about their "innovation" being stifled because their program only affects what it's meant to, then they can go compromise someone else's machine, because I don't want their crap poking around in my files and logging my keystrokes.

Your paranoid, no doubt about it. 99.9999999999999999999999% of Mac applications outside the Mac AppStore are absolutely safe.
 
Last edited:

arn

macrumors god
Staff member
Apr 9, 2001
16,363
5,795
I'm all for sandboxing. If a dev wants to cry about their "innovation" being stifled because their program only affects what it's meant to, then they can go compromise someone else's machine, because I don't want their crap poking around in my files and logging my keystrokes.

I suspect it affects more apps than you realize.

arn
 

calderone

Cancelled
Aug 28, 2009
3,743
352
I'm all for sandboxing. If a dev wants to cry about their "innovation" being stifled because their program only affects what it's meant to, then they can go compromise someone else's machine, because I don't want their crap poking around in my files and logging my keystrokes.

That is just it: many apps will no longer be able to do what they are intended to do.
 

Amazing Iceman

macrumors 603
Nov 8, 2008
5,313
4,063
Florida, U.S.A.
I would vote for sandboxing with some kind of security mechanism that would permit sandboxed apps to safely interact with other apps and other parts of the OS. This would allow specialized utilities to run without problems or limitations.

I'm sure Apple will provide a way to accomplish this.
 

the8thark

macrumors 601
Apr 18, 2011
4,628
1,735
I'm no genius when it comes to computers, or the whole "sandboxing process," however; I do see that Apple originally told developers they wanted Mac Store apps to have sandboxing as a requirement by November 2011, but all I could think about when I read this post was the Chrome book. I know it's not the exactly the same and I'm not saying Google did it first. I just thought I would bring that up.

I agree 100%.

You can not have 100% security and 100% freedom for developers. Impossible. You need the right balance between security and freedom to developers.

Most people do not care about this as long as the apps do what they say they should do. I think this though a good idea is Apple's paranoia talking. OS X is already the most secure platform out there. Not perfect. But no platform is perfect.

Apple believe this increased freedom is worth the slight loss is developer freedom. If the developers agree that'a another matter.
 

ScottishCaptain

macrumors 6502a
Oct 4, 2008
871
474
I would vote for sandboxing with some kind of security mechanism that would permit sandboxed apps to safely interact with other apps and other parts of the OS. This would allow specialized utilities to run without problems or limitations.

I'm sure Apple will provide a way to accomplish this.

What makes you think that?

10.7 is the first step towards the iOS-ification of Mac OS X (not the other way around). Just wait until developers have to resort to retarded hacks to move data between applications because absolutely everything is sandboxed and there's no shared storage between apps.

I swear to god, this walled garden ******** needs to stop. Apple is feeling more like a trash compactor then a green garden filled with wonderful things. Everyone and everything is being crushed into their idea of a perfect platform, and since their vision is ultimately flawed (where your desktop becomes a giant iPad, which is just a giant iPhone)- it's not going to end well for anyone.

-SC
 

Rodimus Prime

macrumors G4
Oct 9, 2006
10,136
4
My fear is this is one step closer to App making the App store on OSX the only way to install stuff on OSX.

I'm all for sandboxing. If a dev wants to cry about their "innovation" being stifled because their program only affects what it's meant to, then they can go compromise someone else's machine, because I don't want their crap poking around in my files and logging my keystrokes.


There is a different between poking around and logging and Apps that need access to that low level stuff to work correct. Several examples have been sited.

Apps that say add system wide keyboard shot cuts or overrides can not be sandbox as they need to grab key strokes at all time. (key logger would store them. This one would say be looking with an if statement and then do said action if it happen but does not store anything)


Another App that many of us used that would work like crapped if sandboxed would be dropbox. That is an example of an App that sandboxing would destroy
 

jackrv

macrumors 6502
Jul 14, 2011
300
0
Absolutely correct - sand boxing is bad for innovation. Already we see differences in the same piece of software that is distributed outside app store vs in appStore - for example 1Password, BBEdit, Drive Genius.. lots of others - the versions in the appStore are crippled vs those outside.

This could eventually be fixed by Apple releasing specific APIs (they may already do, I am not an Apple developer). I see this is an ongoing Work-in-progress kind of thing.
 

vitzr

macrumors 68030
Jul 28, 2011
2,765
3
California
It just shocks me at how easily the fanbois with no clue buy into the lip service from Apple. Under the guise of safe & secure, yeah right. Once again proving how quick they are to go with whatever spin Apple puts out. No Kool Aid required.
 

Stella

macrumors G3
Apr 21, 2003
8,838
6,341
Canada
This could eventually be fixed by Apple releasing specific APIs (they may already do, I am not an Apple developer). I see this is an ongoing Work-in-progress kind of thing.

The API is already there to allow the functionality to be implemented. If the API wasn't available, the software wouldn't exist ( or use entirely private API calls - cough *BetterTouchTool* ).

There is a great argument for not allowing private API calls ( because these may change at any time - public API is far more stable ).
 

arn

macrumors god
Staff member
Apr 9, 2001
16,363
5,795
It just shocks me at how easily the fanbois with no clue buy into the lip service from Apple. Under the guise of safe & secure, yeah right. Once again proving how quick they are to go with whatever spin Apple puts out. No Kool Aid required.

There's no debate that sandboxing is more secure. It is.

The question is how much you really care about it at the expense of certain types of applications.

arn
 

smulji

macrumors 68030
Feb 21, 2011
2,847
2,715
I'm all for sandboxing. If a dev wants to cry about their "innovation" being stifled because their program only affects what it's meant to, then they can go compromise someone else's machine, because I don't want their crap poking around in my files and logging my keystrokes.

I'm all for sandboxing as well but I think the March 1, 2012 deadline is too soon. March 1, 2013 is a fair deadline as it gives developers enough time to develop apps with sandboxing in mind.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.