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...
"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.
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.
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.
Yes, and add to that the fact that typing on a mobile device is painful, and you have a strong usability argument for doing away with the URL bar entirely.
"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."
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.
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.
I just watched the Apple developer videos about App Sandboxing and have to agree that it in most cases it's a good thing.
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).
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.
This brings up an important issue. If an app uses an embedded webview and the user can navigate down links would the developer have to check off every entitlement that the webview might in the future need to access?
Navigating links shouldn't be an issue assuming that the app hosting the web view is allowed to connect to the network.
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.
That's actually what I meant by navigating links. Each page would load fresh content that might have plugins that require services not authorized in the main 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.
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.
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.
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.
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'm certainly no expert here, so take my thoughts with a large, large block of salt. By way of example, I do know that the typical action of dragging a file on to the application's icon in the dock will allow an app to open that file, just as would the open file dialog. Not allowing this would be, obviously, unworkable. Similarly, I believe (although I don't know) that a key-combo associated with that app (as is usually used to invoke screenshots) would signal that the user is acting on the application and, hence, authorizing the action. Although, I'm not sure screenshots would be inhibited by the sandboxing to begin with...
Sandboxing is great since less and less control is in the hands of the app. I am sure apple will keep rolling out features expanding sandboxing, this is just the default impl. This also means that basically it will be harder and harder for apps to be malware in an already hostile system.
I wish android had this. Android needs this much more than iOS.
Android does have sandboxing and its much better in than iOS. Each app runs in its own VM instance and requests for permissions. Additionally each app can also call other apps via intents. This allows for great sandboxing and reutilization.
Because all Android apps are sandboxed and have to request explicit permissions for connecting to the Internet, reading or writing the user's contacts, accessing the user's pictures and so on and so forth.
What is foregone about that conclusion? My impression is that Android's sandboxing is quite nice, thank you. In fact, I think the biggest failing is that there need to be stronger ways to ESCAPE the sandbox (eg: to build a virus-checker or a backup program).
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.
> 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.
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.
This isn't so much a problem if there's a way to break out of the sandbox. If you can give permission to just mess with anything, you can still do all these things.
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.
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.
- 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.)
> 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.
It also appears that screenshots in in fact allowed. According to Gus Mueller, author of Acorn, the app linked to in the article when screenshots are mentioned: https://twitter.com/ccgus/status/132182964766375937
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.
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).
Nope. The gadget-oriented press misses it completely, but Apple's history of catering to creative professionals and media industries goes just as deep as any of their control freak tendencies. Coming straight from Jobs, the purpose of these computers was to serve the arts. They're deeply attuned to the technical requirements (eg plugins) for creative software as well as to what creative pros of all stripes are using. Another example: part of the reason that iOS has had a lot of cool audio apps from the beginning is that low-latency audio performance is practically a core feature of OSX.
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.
Question. What percentage of their sales in this quarter or the last were to support Pro Tools or Illustrator installs?
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?
I think Apple likes that their computers are used to make the content that people use their computers to consume. I think it will take them a while to give that up. I also think that, eventually, they WILL give that up -- it just won't be for a while yet -- and that's probably about when I'll stop using Apple products.
I don't know if that's true. There are a lot of professionals in the visual arts who need monstrous, component-driven, customizable workhorse computers to do what they do, and that won't change any time soon because their job depends on working on or near the cutting edge of what hardware can output.
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.
For simple utility apps that cost less then $5 you really can't do your own distribution model, the amount of money you would make is paltry compared to the dollars the MAS brings in. Trust me, I know http://itunes.apple.com/us/app/space-gremlin/id414515628?mt=...
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.
>"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."
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.
The economics for pro apps are completely different than anything an app store customer can reference. A lot of the market leaders (Pro Tools, Adobe Suite, Avid) have succeeded despite being orders of magnitude more expensive than competitors and erecting barriers for the average user accessing them (byzantine copyright protection, proprietary hardware requirements). There are always lots of cheap and even reputable alternatives, but the leaders usually capitalize by being early to market and basically owning the leaders in the field. Once you have a community of the best and brightest using/evangelizing your software, distribution is a pretty secondary concern.
>This article mostly seems to ignore the fact that you can still distribute apps outside of the App Store.
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.
I cannot see how this is bad for competition. Within the App Store, the apps are subject to the same restrictions and it is fair competition. Outside of the App Store, you are not subject to the restrictions, and hopefully you can - and you should - build something that is impossible to achieve under the App Store restrictions, and you get your competitive advantages.
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.
Except of course, the App Store gets dropped into the dock of every Mac bought.
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?
Every version of Windows back to 95 has included a link to the Microsoft Marketplace in the Start menu. I've never heard Valve or any other competitor complain about it.
The problem is visibility and the appearance of security. A significant number of users won't search beyond the app store and just assume that such apps do not exist if they can't find it on the App store. They are conditioned to do that from their iOS experience, so indeed this is a new bigger hurdle for the non-sandboxed apps and for some(not all) it could mean going out of business inspite of having a good product right now. Also, some people will be conditioned to thinking(rightly or wrongly) App Store = safe, Web programs = unsafe.
> 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.
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.
"""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).
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.
A phone and a laptop are two different things, and it makes sense to lock down one in a way that it doesn't make sense to lock down the other. There is no indication that Apple doesn't understand that.
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.
A phone and a tablet are two different things, and it makes sense to lock down one in a way that it doesn't make sense to lock down the other. There is no indication that Apple doesn't understand that...
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.
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.
If the App store becomes the only way to install applications, then its back to linux for me. I don't really see that as a horrible dystopian future. Even if Windows 8 hardware gets locked down, there will always be a market for linux boxes. Unless the government mandates otherwise, in which case we've got bigger problems.
"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."
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.
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.
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
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.
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.
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.
> Apple has already demonstrated several times over that the professional market isn't really of much interest to them anymore.
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.
I have different expectations from my iOS device and from my Mac. My main work machine must give me the freedom to install whatever I want, since limiting this freedom would be crippling. But I don't require this of my phone, since I don't see the added benefit. This is a practical point of view, and I bet it is common among developers.
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.
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.
Exactly. Anecdotally, probably everybody i know, who adopted Apple products, at some point mentioned audio engineering or graphic design or something similar as being a driving force to the adoption, as if they were going to be the next Vangelis/head of Pixar. People go where the cool people go, i can't imagine Apple giving that up too readily...
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.
While a lot of people moved to Windows due to Avid Media Composer issues with Macs in the mid-2000s they've been moving back since hardware support renewed. In the audio post industry it's at least 80% Mac-based in the US.
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.
Knowing Apple's achievements in pwn2own, this most likely won't increase the real security... Whatever you do, security always boils down to aware user, thus it is in fundamental contradiction to this company philosophy.
> How can you possibly claim that this wont increase security?
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.
Because it is like X-raying people coming through front door to check if they are hiding anything metal having opened and unsupervised kitchen door. Plumbers are banned, yet you can still be killed with a ceramic knife by a polite assassin or with metal pipe by a brutal crook.
The main problem is that it comes with a obvious loss of functionality which I doubt that can be leveraged with security gain -- the other thing is that it gives a faux sense of security to the user (i.e. yes, I have agreed for full file system access, but it was sandboxed, right?). Finally, the system is as weak as the weakest elements, and those seemingly lay in their own code (and can be fixed without hurting the functionality).
So if Google decided to remove the sandboxing functionality in the next version of Android and just run every app under the same user id, that wouldn't reduce the security of Android devices?
Again, I'm not against adding seemingly redundant additional security layers, I'm against calling sandbox an universal cure for everything and using it to constrain the user in morally ambiguous way. Android system is also damaged because it makes users to root the device to do things which might be done without such elevation of privileges and, what's worse, violating warranty.
I think if that ever happens, we will basically have iOS X on our hands. Unless they want to completely merge the two operating systems, I don't see that happening anytime soon.
> 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).
> I'm expecting Windows to move towards a more sandboxed experience as well
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.
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.
Actually, Windows 8 apps are sandboxed too. Take a look at the Microsoft requirements to distribute a new Metro-Style app through their own app store. Same sandboxed requirements. Microsoft must approve and developers must justify any access to resources outside the standard sandbox set.
Yes, but the desktop experience and apps will still be a big part of Windows 8 unless you're running it on an ARM tablet. Microsoft will happily link to your native non-sandboxed app from their App Store.
Sandboxing in general is great. It only becomes a problem if there's no mechanism for users to adjust permissions for apps in cases where they are overly strict.
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.
Ironically, you got it backwards. You're "us". Whereas "the rest of us" = non-computer experts, anyone who prefers simplicity and safety. That crowd has always been the Mac's bread and butter.
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.
Soon to be 1.5 major operating systems (since Windows 8 Metro apps are going to be locked down in exactly the way people fear is coming from Apple evolving the Mac App Store).
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.
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."
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?
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.
"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?
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?
Cool! Does this mean I will be allowed to distribute App Install scripts through the AppStore? The best of both worlds: free distribution & full control!
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?
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.
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.
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.
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.
Yep, looks like whatever version of my app (DubPlate) that's up on the store in March '12 is the version that's going to be there in perpetuity, because it can't be updated for the sandbox on account of its using the CD burner pretty much as a core feature.
Seems like the current implementation can not take care of a lot of common scenario. It is not as ready. It is hard to be safe in an open world. I guess that's the reason why Apple postpone the requirement for sandboxing to March next year.
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.
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.
That can be a really dangerous way of thinking if you apply it to everything else. It reminds me of when people define democracy as the will of the majority when in reality it should be the voice of the minority. Sure, we should aim to simplify everything but whenever someone makes a call to silence the minority it's not going to be a good thing.
You know what, you are a user too. The platform should perform well for everybody, not just the majority. This is what makes me feel Unity and Gnome Shell aren't the best way to go, not just simplifying, but totally removing configurability. There is a central ground, where an interface can be learn-able by a normal user, and not inhibit power users.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :'(
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 ?
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.
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.
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?
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.
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.
Exactly... AudioUnits and VST plugins literally must be loaded in-process of the host to be useful at all. As long as vendors aren't forced to use the App store for distribution I don't think anyone in that scene will care much about Apple's changes. In the digital music / VST / DAW scene I think the app store's initial launch amounted to a single "oh well, guess not" blog post on CDM and then everyone moved on. (I'm exaggerating a bit of course).
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.
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.
"strict realtime requirements" and Mac OS X (and most other off-the-shelf operating systems) do not mix and never have. Either these applications don't belong on the platform in the first place, or you are misunderstanding their requirements.
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?
Realtime in this sense means an interrupt-driven thread that must respond in fixed time to prevent audio dropouts which are death in pro audio. Previously Apple has assiduously courted this market with their implementations of CoreAudio and AudioUnits and the purchase of Logic. OS X provides by far the best native support for pro audio apps of any operating system.
Lately all this seems to have fallen pretty far down on their list of priorities though.
Plugins can exist anywhere. They can be placed into the app's bundle without necessarily breaking its signing seal, they can exist within the app's container if the app has a way of copying them in (e.g. it advertises a file type, like Aperture's ".ApertureExport" bundle, so the user can double click to load the plugin, or it provides an "Install Plugin" feature somewhere), and they can exist anywhere in the user's home dir or system volume (if the app requests an exception to read files from those known locations).
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.
Signed and sandboxed applications have no code loading restrictions. They're free to map anything into their memory space, though that code will of course be bound by the same entitlement restrictions as the loading process.
XPC services must be located within the host app's bundle [1]. They must be appropriately code-signed. How do you propose to use this mechanism for 3rd party plugins?
As I've pointed out elsewhere in these comments, XPC isn't required for supporting plugins in a sandboxed application, and it's possible for plugins to exist within a signed and sandboxed app's bundle:
Xcode, Firefox, Safari, Google Chrome, VLC Player, Dropbox, BBEdit, TextMate, StuffIt, UnRarX. These are all well-known OS X applications, all of them having important features that require being able to open an arbitrary file without user interaction.
The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players. I'm not certain why the browsers are listed, but they're in the same boat for local files (perhaps opening a file:/// url typed in the address field would be broken, but double clicking a local html file or using their Open… features would still work).
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...
I listed the editors due of their project handling and "search in folder" features. I listed the browsers, of course, due to their abilities to browse local files, more specifically, be able to open other referenced local files (images, scripts, links); this is very important for web designers. Archives split into volumes (e.g a sequence of .rar, .r01, .r02 etc. files) are still common in some areas, tipically the user only had to open the first file in the sequence and then the archived opened the rest. Not to mention the obvious case of unextracting all files from an archive.
> The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players.
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.
Xcode and Safari will get special exemptions, of course.
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.
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...