
Why the Mac App Sandbox makes me sad - pavlov
http://lacquer.fi/pauli/blog/2011/11/why-the-mac-app-sandbox-makes-me-sad/
======
dmbaggett
This is all so well-played by Apple: evolve ever more locked down systems in
seemingly consumer-friendly ways. Once consumers forget they can even install
their own applications (except through the app store), OS X distribution will
be just as heavily moderated by Apple as iOS distribution.

Expect Apple, Microsoft, and Google to exert ever more control over
distribution. The software industry is evolving into the "studio model" just
as the movie industry did decades before: 5-7 huge players controlling
absolutely everything that sees the light of day. Everything else is small-
time "indie" stuff that hits big every once in a while, but is otherwise
irrelevant. (It took Apple to make Microsoft realize this was something they
could actually get away with -- thanks, Apple!)

Nintendo's been doing this for years with their consoles. It's not good for
developers, and not good for innovation. But it's very good for the studios,
because it gives them complete control, and makes a new player emerging out of
nowhere (as Google themselves did circa 2000, or Facebook did circa 2009) much
less likely. The cartel stays nicely entrenched.

How long 'til websites are similarly locked down? Will users forget they can
just type a URL in, and instead install everything through their friendly
neighborhood web app store? (Don't laugh.) Who will approve websites? Oh
right, the 5-7 huge players. Got it.

I don't want to sound like a tin-foil hat here, but having spent my youth in
the console game business (Naughty Dog), this seems all too familiar...

~~~
ootachi
"Will users forget they can just type a URL in, and instead install everything
through their friendly neighborhood web app store? (Don't laugh.)"

Who's laughing? All but two of the Web browser manufacturers (Opera and
Mozilla, both of which are losing market share) seem to have vested interests
in doing exactly this.

~~~
artursapek
This reminds me of Steve demoing the first iPhone, when he pulled out the
numpad in the Phone app and called dialing a number "real last-century."

I think soon we will all have the bookmarked websites we regularly visit as
browser-apps (contacts, if you will) with most of the rest being taken care of
by hyperlinks, and once in a while one will have to pull out the URL bar to
actually type an address in manually.

~~~
xsmasher
It's happened already, with bookmarks and search replacing URLs. Googling for
Sony is faster than typing in sony.com, so why not?

The address bar would have faded into near-obsolescence if browsers hadn't
smartened it up a bit, making it search your history and commonly used sites.

------
nhaehnle
In general, this type of sandbox is a Good Thing. I would love to live in a
world where the default environment for any program is a very limited sandbox
that can only interact with the outside world via standardized UI elements.
That is, outside a data store specific to the application, it can only access
files via the standard dialogs, and so forth.

The potential for malware distribution would be significantly reduced in such
a world, because yes, there will always be stupid users, but you cannot blame
all the stupidity on the user.

Even I as a power user would like to try out little programs that I find on
the internet - and that includes small games and screensavers, which are
cliche carriers of malware. Yet I simply cannot safely try them out without an
exorbitant amount of work. Having a proper sandbox environment as de facto
standard outside of web browsers would be awesome.

That said, it absolutely sucks that Apple combines an idea that is a Good
Thing in principle with idiotic policies - if it is indeed true what the
article claims.

~~~
voxmatt
On what the article claims: my understanding is that the sandbox restricts all
non-user initiated actions. That is, if a user initiates it by clicking,
dragging, OK-ing, etc., then all the old system interactions are still
allowed. If you want to take a screenshot, of course you can so long as the
user hits a keyboard combo to do it.

Where it's a real hurdle, however, is for those programs who have to monitor
and interact with files outside its sandbox without user interaction. Take
fantastical, it has to check the user's iCal calendar (or iCloud, or whereever
that file is these days) persistently. If it can only do that when the user
tells it to, it loses a lot of its appeal and functionality.

That being said, I think these rules actually make a lot of sense on the
balance. But it would be nice to allow the user to authorize complete access
in some sort of double-verified-super-secure-foolproof way.

~~~
halostatue
There's APIs to interact with the calendar store; no calendar application
should ever be accessing the calendar files directly—so apps like Fantastical
are probably already OK.

I haven't deeply examined the sandboxing rules and capabilities, but I think
that this could _improve_ application interoperability because they will need
to work through APIs directly rather than through filesystem backdoors.

~~~
flomo
The prominent API for this type of data exchange is AppleEvents, which
apparently won't be allowed without special permission.

(Perhaps there is some other sandbox-friendly way to get calendar info ... I
don't know.)

------
kstenerud
One problem with sandboxing is that it stifles innovation.

Many of the innovations in computers (dynamic libraries, drivers, plugins,
screen grabbing, password managers, etc) came from being able to do anything
on your computer. Once the sandbox lockdown is complete, you won't be able to
invent new techniques that require entitlements the gatekeeper hasn't thought
of already.

The sandbox marks the end of the open system. Protecting users from malware is
a noble goal, but I don't see sandboxing as an effective enough tool to
justify the loss of freedom. iOS is still to this day being compromised with
ease despite its massively locked-down design, and I don't see the cat-and-
mouse game ending any time soon. In fact, the malware danger from email and
web pages is FAR higher than that from shady apps.

The motivation for the app store is purely financial, of course, which means
that over the coming years it's in their interests to command as much control
as possible, even to the point of eliminating unsigned apps altogether once
the app store ecosystem is mature enough (plus it will allow them to finally
kill Flash off all Apple platforms for good, as well as hobble all competing
browsers, and, well, pretty much any software they decide to compete with). I
don't see this scenario playing out well.

~~~
tomlin
> plus it will allow them to finally kill Flash off all Apple platforms for
> good...

You can't declare that sandboxing will destroy innovation, but also actively
persist that killing Flash is a _good idea_. Not saying you are, but you know
others will.

Flash is often used as a petri dish - a way to create new experiences and test
them with a real audience. YouTube, Blog.tv, many experimental video / social
integration and many other innovative (today or yesterday) ideas have lived
and died because of Flash. If you've never coded a Flash experience (outside
of restaurant websites) and did it well (ie, bother to code it properly), you
might find it hard to see this point - again, I point you to the many examples
available.

When we talk about the "open web" without Flash, you're really talking about a
more closed web, because the average designer / programmer can no longer
contribute to the core functionality of the browser - unless, of course, you
work alongside W3C.

Unless Adobe begins releasing in longer cycles, by that I mean slower than
W3C's snail crawl, the idea that HTML/JS will eventually catch up to Flash is
a logical fallacy given history of technology.

~~~
kstenerud
Sorry, my point was supposed to be that killing flash is one of the things
that Apple wants desperately to do. I'm saying it in the sense that it's a BAD
thing, not a good thing.

Same goes for hobbling or eliminating competing software by banning it from
the app store or playing by different internal rules (entitlements not
available to outside developers, for example), or strategically refusing to
grant entitlements from on high.

Basically, Apple is doing successfully what Microsoft failed to do. The
difference is that Apple is being celebrated for doing what Microsoft was
reviled for attempting. You certainly don't hear mention of the Sherman act
when Apple locks a competing app out of the iOS ecosystem, and I doubt things
will be different in the locked down Mac ecosystem.

------
ryannielsen
Some points of clarification to eliminate some FUD, especially around plugins:

\- Signed and sandboxed applications are not prevented from using plugins. No
code loading restrictions are placed upon such processes. Furthermore, Lion-
only apps could employ an XPC based plugin architecture and entirely avoid
loading code into their address space.

\- Plugins do not need to exist within the app's bundle. Plugins don't even
necessarily need to exist within a sandboxed app's container, if that app
requests an exception to read its plugin directory (e.g. ~/L/Application
Support/MyApp/Plug-ins).

\- Plugins can be signed and distributed independently from their host app.

\- Calling out restricted Thunderbolt access is a misnomer. AFAIK, there is no
public Thunderbolt API now and as Thunderbolt is largely PCI Express +
DisplayPort, any kind of access would have required kexts anyway. As kernel
extensions already aren't allowed on the App Store, this isn't (just) a
sandbox restriction.

\- Bluetooth devices can likely be accessed via
AppleBluetoothUSBHCIController, which provides a USB HCI interface to any
compatible BT devices.

\- You can read/write files in a known location on a network disk (or any
disk) if you simply ask for permission once per launch. In fact, if you opt-in
to auto termination, that user-granted entitlement will persist across most
app relaunches, as long as the app's serialized state is preserved[1]. (And if
you filed a radar requesting such a feature, it's very possible Apple would
find a way to persist that user-granted entitlement across all app
relaunches.)

Regarding other points, it is true that Firewire access is restricted, as is
general filesystem access and frame buffer access. Likewise, a sandboxed app
is prevented from sending Apple Events to arbitrary applications, breaking a
good bit of IPC. It's fair to complain about these restrictions (some of them
affect my apps, and working around them will not be simple and may require
removing popular features), but please don't cloud the issue with
misinformation.

[1]
[http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-...](http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-
and-file-references.html#308916)

~~~
pavlov
_\- Signed and sandboxed applications are not prevented from using plugins. No
code loading restrictions are placed upon such processes._

Really? That's good news if true. Got a reference for that?

In any case, since loading plugins would be subject to the same restrictions
as other file access, the app can't maintain persistently accessible
references to the plugin files. The app would have to ask the user to manually
pick each plugin using a file dialog, each time the app is run. This kind of
"manually-aided binary loading" isn't really a plugin API anymore.

 _Furthermore, Lion-only apps could employ an XPC based plugin architecture
and entirely avoid loading code into their address space._

Please elaborate. I still don't see how XPC can be used to implement a plugin
architecture, assuming the Apple documentation is correct in stating that XPC
services need to be located inside the main application bundle in order to be
loaded.

Re: Thunderbolt -- the problem here is that even if a kernel extension driver
is already installed, a sandboxed app can't access it. (The example case in my
mind would be my own video capture app: it's got direct support for devices by
Blackmagic Design, including their new Thunderbolt-based units. I'm using the
vendor's API for this. If I were to sandbox this app, it would have to lose
this functionality.)

[Edited this reply to add more details.]

~~~
ryannielsen
_> \- Signed and sandboxed applications are not prevented from using plugins.
No code loading restrictions are placed upon such processes._

 _> Really? That's good news if true. Got a reference for that?_

<https://devforums.apple.com/thread/108004> (Apologies to anyone not
registered as an Apple developer.)

 _> Furthermore, Lion-only apps could employ an XPC based plugin architecture
and entirely avoid loading code into their address space._

 _> Please elaborate. I still don't see how XPC can be used to implement a
plugin architecture, assuming the Apple documentation is correct in stating
that XPC services need to be located inside the main application bundle in
order to be loaded._

The app can modify its bundle, so that's not the problem. While I haven't
actually tried this myself, there's nothing theroetically preventing the app
from copying a service into its Contents/XPCServices directory in response to
some user action that makes that service available to the sandboxed app (e.g.
they double clicked a file that's of a type registered by the app, or they
invoked an open panel within the app somehow).

The bigger problems, and ones that I can't find solid docs on are:

1) Does the service's signature need to match the parent app's signature? The
docs actually indicate the service might not even need to be signed.

2) Can the app easily enumerate services, to discover new ones? Presumably,
this should be possible but, again, I've never tried it myself.

In the end, it may well be that XPC isn't an option for 3rd party out-of-
process plugins. In process plugins are, as noted above, not a problem though.

 _> Re: Thunderbolt -- the problem here is that even if a kernel extension
driver is already installed, a sandboxed app can't access it. (The example
case in my mind would be my own video capture app: it's got direct support for
devices by Blackmagic Design, including their new Thunderbolt-based units. I'm
using the vendor's API for this. If I were to sandbox this app, it would have
to lose this functionality.)_

Ah, gotcha. I'm a little surprised to hear about that restriction, as I was
the BT and Firewire restrictions. I'd have expected all of those to work, as
long as your app was only using user-space APIs. Is the mach port lookup
restriction what kills these? Have you contacted WWDR? We've got a WWDR
contact that has been very helpful and proactive.

------
saturdaysaint
This article mostly seems to ignore the fact that you can still distribute
apps outside of the App Store. In fact, considering the falling costs of
hosting and easy access to marketing tools (look at the quality of the website
for any Mac App), it's probably never been easier.

For pro apps with dedicated audiences (see: Adobe, Ableton, Avid, Nuance)
which is just about anything with a plugin architecture, the App Store's
distribution is unnecessary. These are established companies with deep links
into creative communities. As a consumer, when you're looking at spending
hundreds of dollars on, say, music software, you don't care what's in the "Top
25" or on Apple's "Featured" list (if you're smart) - you care about what the
people you're working with are using and the opinions of specialized
professionals.

~~~
nimrody
Apple may eventually disable loading of executables which are not
cryptographically _signed_.

At this point, you'll have to resort to kernel patches to bypass that
mechanism and load non-authorized applications.

Hopefully, Apple will leave a way to disable code verification. At least for
advanced users.

~~~
spc476
I see the following in syslog from my Mac: no system signature for unsigned
/Applications/Firefox.app. I've been seeing this for the past couple of years
now (and it's not restricted to Firefox by the way).

------
lallysingh
I just bought a new laptop. The last 3 were powerbooks/macbook pros. I saw the
app store on os x and decided on a lenovo this time, running linux (xmonad
helped tip that scale).

I'm really glad I went that way. I'm sure that this is a good thing (tm) for
most users, and will help avoid all sorts of problems. But the Mac's becoming
more of an appliance, and while it's safer, easier, and more convenient for
most users, it makes it a substantially less desirable machine for me to hack
on.

There's a tradeoff between making the developer environment and user
environment closer together -- to make the machine more amenable for hacking,
to reduce the wall for development, and to make the platform a good place to
learn how to write code -- vs farther, to make it a simpler, safer environment
for users. So far, the bias has been on the former, but it's changing.

What's interesting is that this may, for the time being, push app development
server-side (to the web) as the client environments become more hack-
inhospitable.

~~~
dextorious
"""But the Mac's becoming more of an appliance, and while it's safer, easier,
and more convenient for most users, it makes it a substantially less desirable
machine for me to hack on."""

You _do_ understand that in Lion, say, nothing, absolutely nothing has been
taken away from you that you could do back in 10.1 or even NeXT.

So, this "the Mac's becoming more of an appliance" is just bullshit, just
blindly following the latest trend in "hacker" circles (and probably a
hacker's desire to buy a new, different system to tinker with).

~~~
fennecfoxen
Dude. We know how the iPhone works. It's easy to see Apple starting to bring
the same sort of model to the MacBook. We're not blind. We can see where this
is going, even if it's not there yet, and make reasonably informed guesses
about what it's going to be like.

~~~
lallysingh
Well, you can also just watch the derivative? When's the last time the OS had
a major feature that was aimed at developers? I remember the early OS X
releases coming out with advance after advance. The rumored ZFS integration
was the peak of this awesomeness... At least dtrace was integrated.

The last thing I've seen is transparently compressed files; not exactly
exciting. I think we hit the peak around the leopard-snow leopard range.

~~~
rayiner
XCode 4.x. Still crappy, but way better than Xcode 3.x. LLVM. Continuous
improvements to the Obj-C 2.0 runtime like tagged pointers and Automatic
Reference Counting. Versions, iCloud, and associated APIs for document
persistence. MacRuby framework.

------
sirn
I thought 1Password 3.9 (the MAS version) was already using App Sandboxing and
I don't feel limited at all. Dropbox syncing works fine like before and
browser extensions works better than before (without all the ugly InputManager
hacks). Basing on this one app I often use, I'm overall happy with sandboxing
so far.

~~~
feralchimp
+1

The article makes some strong assertions about what is/is not allowable under
the currently available set of entitlements. I expected more discussion here
about whether all of those assertions are accurate.

If there's a primary source that I can take a shot at interpreting
independently, can someone point me toward it?

UPDATE: Looks like the best doc is the "App Sandbox Design Guide". Film at 11.
:P

------
statictype
This would worry me if there weren't at least two other major Operating
Systems available to choose from.

The Mac is moving more towards simplicity and safety - targeting normal
consumers.

That's fine. Ironically, now Linux and Windows (and anything else that comes
up down the line) will have to serve as the 'Computer for the rest of us'

~~~
Angostura
This would worry me if the AppStore were the only way to get aplications on to
your Mac.

I can see it being very disapointing for developers who enjoyed the
convenience of the AppStore, but need additional functions. But I guess they
will have to sell ex-Store

I can also see the benefit of Apple being able to say that 'Anything you buy
on the Store is safe(tm)'.

However if Apple every makes teh Appstore a compulsory way to get software
onto the Mac, I will drop Macs. And I speak as someone who has used them for
about 20 years.

~~~
super_mario
Give it a release or two and app store will be the only way to get software on
your locked down appliance owned by Apple.

~~~
marquis
If this happens they will effectively kill off a huge number of professional
services, especially in the media industry. I'm not looking forward to a
future where I have to look to Windows or Unix as my main development
platform.

~~~
statictype
_they will effectively kill off a huge number of professional services,
especially in the media industry._

Apple has already demonstrated several times over that the professional market
isn't really of much interest to them anymore. Witness the disaster of Final
Cut Pro X and the gradual phasing out of the Mac Pro hardware line.

Apple's focus is squarely on the consumer market. Though it may seem unlikely
today that they will permanently ban non AppStore apps, I wouldn't cite the
professional market as a reason for it to not happen.

~~~
LaGrange
I wouldn't expect Apple to care about any single specific professional niche
(maybe except application developers), so keeping any sort of professional
software in-house might be even a distraction.

But Apple still depends on professionals-as-a-whole — once you add up graphic
designers, architects, movie professionals and all others you get quite a lot
of people who probably have enough money to buy fancy computers, tablets and
phones.

As an added benefit, I would sorta-expect the professional market to have
significant impact on consumer market — e.g. people's influence on family
purchases, brand perception, recommendations.

~~~
Daishiman
Except that the very top of the professional high end is not really that
populated by macs.

Most pro 3D designers use 3DStudio MAX (Windows) or Maya (multiplatform with
no advantage for Macs). Most architects use AutoCAD (Windows only). Most
professional studios use a mix of all three, with a predominance of Linux and
Windows at the highest end. Even with audio there isn't much of an advantage
to using a Mac unless you depend on Logic Pro.

~~~
LaGrange
Actually, AutoCAD has a Mac version, though that doesn't change that much. But
the point still stands — it makes sense for Apple to want professional
applications, it doesn't really make sense to try and write own Maya, and
distribution dynamics are for large packages are different enough to make
using Mac App Store for them less attractive.

------
CHsurfer
One possible strategy may be to offer a 'limited' version of your app that is
compatible with the Sandbox constraints for a low price. When a user tries to
do something that is not possible due to the constraints, you can inform them
that the pro-version (not installed through the app-store) can eliminate this
and other inconveniences.

If you are worried about destroying the market value of your app, then just
charge full price on the app store and allow customer's to 'upgrade' to the
unconstrained version.

This is far from ideal as it incurs lot's of overhead by maintaining two
versions and extra work for the customer, but it will probably be worth it to
stay on the App store.

~~~
natesm
Actually, you can't (within the app, at least) - App Store apps can't make
references to the existence of software that is outside the App Store.

~~~
RyanMcGreal
Ugh, it's like the GPL in reverse.

~~~
CamperBob
I can imagine the GPL-inspired first line of the AMI license. "Most software
is designed to let you do various things with your computer. Software licensed
under the terms of the AMI (Apple May I) license is different. It is designed
to make sure you can't do anything useful with your computer at all, at least
not without asking first."

------
heyrhett
I think that it demonstrates that we've passed the era where people want "a
computer" to do things. People want a smartphones, tablets, notebooks, etc.
People are not buying these devices for their raw computing power, and they
don't want the freedom to access all of it. People want these devices to
"work" at their respective tasks.

Apple is becoming the sole gatekeeper of apps to their devices. For example,
after begrudgingly allowing 22 or so "fart" apps into the app store, they
said, "ok, we gave you some fart apps, now you have enough fart apps, we
aren't going to allow any more fart apps into the store". If some developer
comes up with the best fart app ever, there is no practical way for him to
distribute it any more.

I see this as an insane amount of power for one company to have. Imagine if MS
did the same thing with windows. If they did it 10 years ago, they would have
been sued for monopolistic practices, but now that Apple's doing it, and Apple
is a viable competitor to MS, can't MS do the same thing, and now we are stuck
with basically 2 companies deciding all of the software that can be installed
on 99% of the computers that people use?

This is a sad future to me.

~~~
fpgeek
_Imagine if MS did the same thing with windows._

If Microsoft had done the same thing with Windows, Apple as we know it today
wouldn't exist, if they even existed at all.

To me, it is mind-blowing that, nevertheless, (most) Apple fans are perfectly
happy with the shoe on the other foot.

~~~
ZipCordManiac
As a longtime Mac user (since the 80s) , it pains me to think my next purchase
won't be a Macintosh, but I can't ignore the writing on the wall any longer.
Apple used to be about freedom and creativity - now they just want to give the
best user experience while keeping users safe and maximizing profits. Not an
all-together horrible goal, but also not the kind of computer I want to use. I
want a computer, not a toaster or a microwave. People have for years called
mac kid computers, and I never really agreed with them before now. This kind
of development really puts the final nail in the coffin though. These
computers are made for people who simply want a locked down boring experience.
It's a sign of the times, just look at the TSA.

------
feralchimp
"If you choose not to sandbox your app now or to use a temporary exception
entitlement, use Apple’s bug reporting system to let Apple know about the
issue you are encountering. Apple considers feature requests as it develops
the Mac OS X platform."

So everyone with grave concerns about sandboxing is filing Radars, right?

------
guard-of-terra
Don't they distribute xcode via appstore? it obviously dould not fit in the
sandbox. If they make it an exception, can't they be hammered for monopolizing
the development tools in the app store for themself?

~~~
gcv
Apple distributes the Xcode _installer_ through the App Store. Normal App
Store restrictions don't apply.

~~~
guard-of-terra
Can anybody else distribute a foo installer, so normal restrictions would not
apply?

~~~
ryannielsen
Nope. Xcode is special.

------
vasi
While it's possible that Apple could ban non-App Store programs, I don't see
this as the likely threat. More plausible to me is that new APIs in OS X will,
like iCloud, become available only to App Store apps.

Eventually anything that's not in the App Store will feel like the most
ancient Carbon apps feel now. Why prompt an exodus of users over a mass ban of
apps, when you can just slowly and surely take over the market instead?

~~~
fpgeek
Indeed. Apple's become very, very good at boiling frogs slowly. And I believe
there are already at least a few APIs that are only for App Store apps.

------
makira
The problem with the current sandboxing is the missing entitlements, for
simple things like:

\- Using the burning framework (cd & dvd burning)

\- Interfacing with Apple Remotes

\- Having a shared container between a main app and a helper app

Also, many utilities will have to be removed from the App Store because of
sandboxing, and that will likely cut revenues dramatically for those
developers.

~~~
shinratdr
> Using the burning framework (cd & dvd burning)

I wouldn't be surprised if this was intentional. I'm sort of picturing Apple
killing off the 17 inch Pro, 13 inch Pro, Mac Pro, and then slimming down the
iMac and 15 inch Pro by removing the optical drive. They are done with optical
media. It wouldn't shock me at all to see DVD Player removed from 10.8.

> Interfacing with Apple Remotes

Correct me if I'm wrong but I'm pretty sure this ability was removed with
10.6. I can't control anything besides built in Apple apps on my Mac with my
Apple Remote unless I install Remote Buddy + Candleair, which restores 3rd
party access to the Apple Remote by using an alternate driver.

~~~
makira
Regarding the Apple Remote: it works fine using a 3rd party wrapper:
[http://www.martinkahr.com/2007/07/26/remote-control-
wrapper-...](http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/)

However, the needed IOKit functions to talk to the driver are refused to
sandboxed apps.

~~~
shinratdr
Right, but the fact that it requires a 3rd party wrapper is a good indicator
that Apple doesn't want 3rd parties relying on the Apple Remote, so don't
expect to see an exemption granted for it any time soon.

There is also plenty of growing evidence that the Apple Remote & IR sensor
will be removed from future models. It's already gone from the MacBook Airs,
3rd party support was removed with 10.6, Front Row has been killed off, and
now this. I feel like this and the lack of support for optical media are both
deliberate omissions that we won't be corrected, and are good indicators of
future hardware decisions.

------
mevodig
Ultimately, for me, this is about creating a reasonable user experience for
the majority of users.

While it's easy to forget this when spending a lot of time in forums such as
HN, _we_ are not that majority. This constant expectation that platforms used
everyday by millions of people should be tailored to us is untenable.

~~~
jiggy2011
I don't know.. I think allot of people here underestimate the average user. I
see allot of comments on this site of people basically saying "everyone else
just uses the computer for facebook".

That's not really true, although there are users like that. I know allot of
people who are not technical or CS people in the HN sense but who use their
computers for allot of stuff including some pretty sophisticated creative or
business tasks and are actually quite capable of doing technical stuff
assuming it is explained properly to them.

Also people on HN have probably spent more time using computers and seeing
lots of different users use computers that we probably have more of a long
term feel of what would work well and what wouldn't, and if we are all
developing the next generation of apps etc for the masses then our opinions
and requirements are actually pretty important.

If you have an over restrictive platform that does not allow developers to
innovate in ways that they want then whilst end users may appreciate the
simplicity, they will become frustrated if this platform fails to deliver the
flexible applications that they really want. For example I know many non tech
users who use literally hundreds of firefox plugins.

Of course there are a few people I know who are of the opinion that all
hardware & software for everything should just be developed by Apple end of
story.

------
dubya
I'm a bit wary of this, but it really does seem like a decent model for most
things in the App store. It's pretty clear there needs to be some exception
mechanism, since Xcode and Lion won't run in a sandbox, but there were already
restrictions. TextWrangler in particular removed some functionality in its App
store version. And things like TeXLive and the Haskell Platform and most other
developer tools never appeared in the app store.

------
tjogin
We don't know that much about the Mac App Store sandboxing yet, it could be
perfectly benign. This is mostly a bunch of conjuring of ominous fantasies.

~~~
natesm
It's been available since Lion, my app uses it. We know everything about it
_technically_. However, we know nothing about how Apple is going to handle
exceptions and what will get you rejected. An app that I'm sort of working on
right now absolutely needs read access to the entire filesystem, and possible
write access in the future, unless Apple makes technical changes in sandboxing
(unlikely until 10.8, effectively unusable until 10.7 customers are a tiny
minority).

Judging by Apple's actions in the past, we probably never will get any sort of
official information, and when we try to piece it together by community
observation, it'll be inconsistent anyways.

~~~
tjogin
We know nothing of its future capabilities and limitations.

------
andymoe
I understand that people are worried that Apple will abuse their power and be
unreasonable about granting exceptions but honestly after building many apps
on the outside and seeing how things work from the inside for a year (during
Lion dev) I don't think that will necessarily be the case.

Sandboxing will make OS X more secure, and that's a good thing, especially as
the OS X install base pushes towards the 15% range and beyond providing a
juicy target for our friends on the dark side.

Let's hope I'm right and Apple plays fair because I would like the two App
Stores to keep paying my bills while there are still people who are wrong on
the Internet.

------
egsmith
Is that really the complete list of privledges? It says a child process can
inherit the sandbox but not that a child process can be created. I mention it
because I think the plug-in issue could be solved with child processes and
sockets, or something similar.

Also, a typical program now can't access a generic thunderbolt device directly
(it would be done via the file system which is a possible privilege).
Thunderbolt devices are in PCI address space and this needs to be done via the
kernel even now.

But it does raise a question: What about 3rd party device drivers?

All in all, I think most of these sandbox arguments underestimate developer
creativity.

------
iuguy
I'm concerned about this move. As long as you can continue to install things
outside of the sandbox and Mac App Store, I'm happy, but there's a massive
flag going up in my head over this, I'm really not sure Apple would be able to
resist the urge to integrate the locked down nature of iOS into OSX. This
concerns me to the point where I'm now rethinking 3 MBP purchases as I'll be
stuck with them for 4 years at work, and I don't know what OSX will be like in
4 years time.

------
podperson
I don't think he mentions that every app has full access to its own
"container". Plugins, per we, are already not possible via the app store, but
it's early days yet, and I think the author needs to understand that apple
will adapt to user requirements.

Comparing a software security model's trade offs between flexibility, user
safety, and developer convenience with being a sharecropper is just another
example of hysterical Godwinism.

------
neanderdog
Well I've been considering a linux on my macbook pro for sometime as os x has
(e|de)volved. This pretty much clinches it for me.

------
rayiner
People are forgetting that as consumption apps move to the iPad/iPhone, more
of the people left on the Mac will need the extra power of a non-locked-down
environment.

Apple's goal is still to sell hardware. As long as they can create a newbie-
safe experience on the Mac without locking out people who need to tinker, it
buys them nothing to do so.

------
duncanwilcox
The Sandbox makes me sad.

Remove exploits of a single poorly written app spreading to the rest of my Mac
and taking over make me sadder.

~~~
darren_
It's not even 'poorly written', it's nearly every non-trivial C/C++ app, over
a long enough time, turns out to have _something_ exploitable in it.

~~~
dogfu
_sigh_

Does that include the sandbox itself, which was written in C?

~~~
darren_
Yes? But it presents a much smaller attack surface (as compared to the attack
surface presented by the set of applications you might otherwise run under a
sandbox). And it's maintained/secured by one vendor instead of the set of
vendors that distribute the applications you might otherwise run under the
sandbox.

------
Limes102
The only time I'm going to feel concerned about the sandboxing on Mac OS apps
is if it's forced onto all applications.

If that happens, I shall leave Mac just like I did Windows and be forced to
use Linux... I can't say I particularly like the new layout of Ubuntu so maybe
I should just quite computing completely :'(

------
shampoo
Does anyone know what the adoption rate is for the App Store for Mac ? How
many apps in the App Store cannot be downloaded outside of the App Store ? How
many apps converted from being downloaded outside the App Store to inside. My
question is, can Apple put the Genie back in the bottle ?

------
amartya916
It seems that the sandbox may allow for easier iCloud syncing. Since even
Apple's apps like Pages, Keynote etc. cannot sync data to iCloud, it seems
like an obvious feature to implement. I hope they allow App store curated 3rd
party apps iCloud access as well.

------
super_mario
As a die hard Mac user, fuck Apple and the Mac. Honestly. After the rumor they
are killing off Mac Pro, and this insane gestapo shit already under way in
Lion (which I don't use), I really don't want to be associated with Apple in
any way.

~~~
guywithabike
Calm down. You may want to go for a walk outside. Or talk to an anger
management counselor.

------
atwhn
I am altering the deal. Pray I don't alter it any further.

------
nknight
I can think of only two GUI apps I semi-regularly use that can't fit within
those restrictions: VMware Fusion, and Steam.

Plugins are a red herring. Some poorly-designed plugin infrastructures will
not be workable, boo-hoo. Valid use cases can be accommodated with proper
message passing. Maybe we'll finally get applications that don't crash
horribly because of buggy plug-ins?

~~~
pavlov
What kind of plugin architecture do you propose that doesn't use dynamic
loading or standard IPC mechanisms? Your "message passing" is much too vague.

Remember, this needs to be fast enough to accomodate FCP video processing
plugins - hundreds of megabytes of data may need to be passed between the host
and plugin each second.

~~~
cageface
AudioUnit plugins have strict realtime requirements that won't work with
message passing too. If Apple disallows plugins that will be the end of the
Mac as a pro audio platform. Not that a lot of plugin developers would mind so
much after the insane platform churn at Cupertino in this last decade, but
it's hard for me to imagine Apple would go that far.

~~~
super_mario
Apple can't get out of Pro market fast enough. They already killed XServe,
they "deprecated" Java, which means no chance in hell anyone will try to host
their app server on Mac, and now even develop on Mac, they haven't updated
their Pro audio software in almost 5 years, the fiasco with FCP X (complete
rejection from actual pro users), and most recent rumor they will kill off Mac
Pro as well.

Apple wants to be handheld "post-PC" maker and not a computer company. They
don't want anything to do with the pro market, people who actually need to do
work with their computers.

~~~
adsr
They killed XServe because it belonged in a market where Apple was
insignificant, they weren't selling any. Java now has to be installed
separately like on all other platforms. Logic was last updated in August.

