Why the Mac App Sandbox makes me sad
lacquer.fi
lacquer.fi
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...
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.
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.
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.
The "seemingly" part confuses me. Why seemingly? Either consumers will like the experience (as they seem to do in iOS and could care less about a few apps non allowed to the iOS App Store) or they won't and they will leave the platform.
Apple cannot "foul" the consumers into liking a more locked down system. Either they will, or they wont. And I guess they will. The average consumer is not the average HN reader.
Short term: less malware, better UX. Long term: software distribution carefully controlled by a cartel.
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.
I wish android had this. Android needs this much more than iOS.
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.
How would that work? How does the system determine that the user intended for this particular action to take screenshots of other applications' windows?
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.
(Perhaps there is some other sandbox-friendly way to get calendar info ... I don't know.)
With that new enthusiasm I went ahead and tried the AppSandboxQuickStart code sample that loads a webpage in a WebKit WebView.
Enabled sandboxing, app failed because of missing network.client entitlement. Enabled that as the tutorial said to get it to work: app still fails.
Turns out that the WebView, or rather the Flash plugin is trying to load the AIR apps that are installed (why, I have no clue, I was loading apple.com).
>WebProcess(1319) deny file-read-data /Users/me/Library/Application Support/Adobe/AIR/ELS/com.prezi.PreziDesktop/PrivateEncryptedDatak
The app didn't start at all. Only hint were errors in the Console. As a developer I'm afraid that those "perceived crashes", that's what they will look like to users, will become a common theme.
But how about plugins loaded by the web view? I assume that's what's happening in my case. The web view is loading the Flash plugin, which in turn tries to access the file system.
That's not allowed, because the plugin inherits the entitlements of the parent app. The Flash plugin really can't believe that access to it's Library folder doesn't work so it tries and tries and tries sending the main thread into an endless loop blocking the complete app.
For example, any typical RSS reader, alternative email clients, specialized browsers, or any dev tool that shows page previews using a webview. These all have to max out the entitlements so they don't break down the line.
It seems like it would be much more useful to make entitlements be a dynamic system instead, so apps can request extra privileges at runtime and asking the user to confirm instead of statically baking it into the app envelope. Same goes for the iPhone.
If you are on Windows, Sandboxie is excellent for this. Just right-click the untrusted .exe and select "Run sandboxed".
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.
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.
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.
Of course, in Apple-world, you can't do this. I can definitely imagine a fully-sandboxed OS that lets you allow a particular app to inject code into other apps.
- 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-...
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.]
> 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.
And confirmed by another Mac dev: https://twitter.com/gte/status/132183576841175041
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.
It is true that inn terms of dedicated (aka existing) audiences or customers, access to is probably still unnecessary, however it is clearly a disadvantage when it comes to generating new users or providing upgrades to existing users.
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.
I think "still" is the important word here.
Mark my words: Apple will never make a change to OSX that will keep Illustrator, Pro Tools, or Avid off of the platform for a second.
Are you sure they won't trade that away to Windows for a chance to improve their lockdown? You still seem to be working under the mental model that was created for Apple's actions when those apps were basically the only thing keeping Apple a going concern at all. That is not their current status anymore, and I think the model may need updating to reflect that.
The counterpoint that these people are thought leaders is still valid, but even then... thought leaders for what percentage of their market now?
that's probably about when I'll stop using
Apple products
Apple has served that market (or at least the front-end focused part of it) pretty well in graphic design and video for a long time, but even if that market becomes too small or too complicated for Apple, those people will still need their machines and their systems, and their business will be big enough for someone.
At least until UEFI Secure Boot becomes mandatory.
Sure, but when Apple starts claiming and advertising that all Mac Store apps are secure(indirectly implying that external apps are not or may not be), external apps will have a much harder time appealing to the casual crowd, and for some apps living on thin margins, might be a death knell as more and more Macs get into the hands of casual users. The mid level apps between the big pro apps and the iOS-like apps will get really squeezed with this if they need non-sandboxed functionality and will be forced to conform or stop development in order to eke out a profit.
If you just hate the App Store idea, and you don't really have anything that cannot be done with the sandbox restrictions, well, if your customers like the App Store, I guess you should be out of business anyway. This is pure Darwinism.
> if your customers like the App Store,
Of course they will like it, it's front and center and easy to operate. How is that the dev's fault?
>This is pure Darwinism.
This is nothing like Darwinism. Perhaps it would be, if you assume that the sunlight, forest cover, predators and water supply were able to be controlled by a company.
If you include advanced features in your app and thus are pushed out to an external distribution but your competitor releases with only limited features, who is going to make more money? And forget about a Lite version linking to the Pro one, that's prohibited too. The only "evolution" that will happen is that this will lead many small and mid developers to cut out features and operate only within a sandbox so as to get traction.
So if I operate another marketplace/platform for delivering computer programs, say Steam, I should be out of business?
How is destroying the competitive marketplace good for competition?
I wonder (and just thinking out loud here) if there might end up being an 'app store' anti-trust suite, with Apple and Microsoft being forced to give things like Steam prominence?
I'm sad to see that this move by apple will kill off a lot of utility apps that are bringing in decent income for people.
Do you really think that they will not try to use the app store as a tollgate for everything? 30% of Adobe sales == big number.
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.
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).
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.
What I see with App Store sandboxing is a way to allow people to more easily try and buy apps without worrying what those apps are doing to their computer. I'm very careful about downloading and trying apps on my Mac because I don't know what files they're going to leave around on my computer or worse. Sandboxing in the App Store is a great way to make that situation better.
What does that have to do with my point? He said Mac is already becoming more restricted "like a appliance". I said that that hasn't been the case for the last 10 years of OS X and is not the case even now. The only counter-example that comes to mind is the removal of the Input Manager haxie capability (a GOOD thing).
TL;DR: You argue about what "might happen in the future", while I replied to someone complaining about something that happened already.
P.S Who uses "dude"? A 15-year old?
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
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'
I'm expecting Windows to move towards a more sandboxed experience as well, at least for Metro/WinRT. I know Miguel de Icaza also hopes for broad sandboxing support by default.
Regarding TFA, he does not make much of a case against sandboxing (applications not being able to write wherever the hell they want without warning the user counts as a positive in my book), and his final quote (of Tim Bray) is relevant to appstores, but it has no relevance whatsoever to sandboxing. Not impressed. Even the plugins stuff has limited relevance in the grand scheme of things, it will affect some applications for non-technical users (more technically oriented ones will likely be able to put their plugins where they know they should be).
It already does to some extent.
Internet Explorer was the first to introduce it (to my now out of date understanding), and it's since expanded to other products including shipped Windows apps, Office, etc.
It happens invisibly for the developer, if you think the registry that you access is THE registry then you're wrong. It's a proxy that you access, and the proxy has a view on what you will see or not.
An example mention of this is here (one of the first Google hits): http://office.microsoft.com/en-us/access-help/enable-or-disa...
Basically, you the user get the choice, but by default your apps, the things they open, are all sandboxed and protected. For compatibility reasons you can currently choose to override this, but as you might expect group policy can be used to disable someone's ability to lower their security.
http://www.engadget.com/2011/09/13/windows-8-store-to-sell-b...
Screenshot http://farm7.static.flickr.com/6209/6144024273_4b505de2fc_o....
I guess a big reason for locking down Metro apps is battery life concerns.
I love how sandboxing on smartphones have gotten users to ask more questions of why a certain app needs the permissions they request, for example.
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.
These changes improve security. Just because they don't improve the security to 100%, that doesn't make them worthless.
I've honestly never heard of a third-party Mac application which contains spyware or steals personal information. It just does not seem like a huge problem which needs to be solved.
(Of course there have been security issues with things like Adobe Acrobat and MS Office. But big ISV software is the least likely to be affected by app store restrictions.)
On the Windows side, there's things like file-sharing software which is packaged with toolbars and malware. That kind of thing is unheard of in the Mac world, especially in the app store.
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.
But they responded to that by putting Final Cut Pro 7 back on the market. Sounds like they care a lot...
Hanlon Razor makes sense here.
There is one group of professionals Apple cannot do without: developers. One of the main appeals of both iOS and the Mac is the availability of exclusive, high-quality apps. I expect that limiting all app distribution to the Mac App Store will send developers running to other platforms. A platform without developers is an empty shell, and Apple knows this.
Just like it did for iOS?
Perhaps in the future most development will take place in SSH sessions on a remote machine, and then closing down the Mac will not longer be a problem, but I don't see how that would work today.
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.
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.
When we see signs that Apple will block software installation outside the App Store, then I'll grab a pitchfork. Until then, I think this is good for most users.
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.
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.
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.
So everyone with grave concerns about sandboxing is filing Radars, right?
Also, does this mean I'm free to distribute my malware installer through the AppStore? After all, it's just an installer.
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?
- 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.
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.
The OS itself handles 99% of what users use their optical drive for. 3rd party/external readers and burners will still work, just not with 3rd party apps or MAS apps.
I'm not trying to brand this as a great thing or anything, but it does seem very likely to me. If you develop an app that requires access to the optical drive, I wouldn't hold your breath for MAS support. The way I see it going down is Apple grants companies like Roxio temporary exceptions until they kill off products like Toast once and for all, and then Mac OS X drops support for optical media just like they did with floppies.
However, the needed IOKit functions to talk to the driver are refused to sandboxed apps.
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.
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.
The thing with OSX appstore sandbox isn't that it hurts power users, it hurts the majority. It limits what developers can make applications do, preventing many types of applications that users would expect to be possible. Sandboxing itself isn't bad, it is just this implementation that is bad.
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.
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.
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.
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.
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.
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.
Remove exploits of a single poorly written app spreading to the rest of my Mac and taking over make me sadder.
Does that include the sandbox itself, which was written in C?
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 :'(
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?
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.
Not that loading code is allowed on the App Store anyways, unless you're Apple, of course.
No code loading restrictions are placed on signed and sandboxed apps. Any signed and sandboxed process is free to map in any code, though that code is bound by the parent process's sandbox restrictions.
2.16 Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected
So I guess that you can have a plugin system as long as you don't provide an in-app way to download and install them, like Adium does?
It doesn't matter anyway. What is it Apple has done recently to give you the impression that they place great importance on niche markets?
Lately all this seems to have fallen pretty far down on their list of priorities though.
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.
http://blogs.computerworld.com/19195/apple_kills_the_mac_pro...
As with all Apple rumors, take it with a bucket of salt, they might announce a new line tomorrow for all you know.
[1] http://developer.apple.com/library/mac/#documentation/MacOSX...
http://news.ycombinator.com/item?id=3193354
User interaction must happen at some point, otherwise the apps have no clue what files to open.
Xcode (and BBEdit's and TextMate's project features) and Dropbox are interesting cases. Dropbox can presumably ask for permission once for each directory the user wants to sync. It does, after all, already use a NSOpenPanel when the user asks to change the sync location. It remains an open question whether it can permanently persist that user-granted exception indefinitely. [1]
Xcode is special because opening a project will be a user-specific action, but then each referenced file will somehow need to be opened. There is no solution I'm aware of for that use case. If you're a developer in a similar boat, I strongly suggest filing a radar explaining how your app is broken by the lack of such a solution. I bet the BareBones crew is already working their WWDR contacts, making their needs clear...
[1] http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-...
You open a playlist of files or a video file with linked subtitles, then you need to be able to open another file, that can be arbitrary located.
Opening a playlist or a file with linked subtitles needs to open an extra file after the first one.
Screen grabbing is nowhere to be found, not to mention CD/DVD access, or advanced networking, hardware decoding...
But putting aside short-run user backlash, do you really think Apple gives a damn whether Firefox, Chrome or VLC run on OS X? Judging by iOS, they might actually prefer it if they didn't.
After that you're left with archiving, text editors and Dropbox (which Apple might well want to replace with iCloud in the long run), which doesn't sound like that much to me.