Apple In Trouble With Developers 343
geek writes "According to Marco Arment, the creator of Instapaper, Apple may be in trouble with developers. According to Arment, the new sandboxing guidelines from Apple are pushing developers away in droves. 'I've lost all confidence that the apps I buy in the App Store today will still be there next month or next year. The advantages of buying from the App Store are mostly gone now. My confidence in the App Store, as a customer, has evaporated. Next time I buy an app that’s available both in and out of the Store, I’ll probably choose to buy it directly from the vendor. And nearly everyone who’s been burned by sandboxing exclusions — not just the affected apps’ developers, but all of their customers — will make the same choice with their future purchases. To most of these customers, the App Store is no longer a reliable place to buy software.' Arment also comments on the 'our way or the highway' attitude Apple often takes in these situations and how it may be backfiring this time around."
He's talking about the new MAC app store (Score:4, Informative)
not the App Store most people are thinking of (the iphone/ipad one). TF summary is misleading.
The mobile App store's always been restrictive, and it seems to have done okay... nothing to see here.
Like Walmart..... (Score:5, Informative)
Apple probably doesn't care. When one merchandiser leaves, another one will gladly take its place.
The problem is... (Score:4, Informative)
Developers think "Great, I can release an App Store version... I just need to remove x and y." So they do that, and people buy the App Store version. Then the developer realizes his App Store version now can't do Z, which makes it much harder to keep making in parallel with his native version. So he stops updating the App Store version. App Store customer sees non-App Store version getting updates and gets angry.
New sand boxing guidelines? (Score:5, Informative)
Re:Pray I don't change them further.... (Score:4, Informative)
Remember, that line didn't even work out for Vader and he had Star Destroyers and millions of clone troopers at his command.
No he didn't. By "A New Hope", all of the clone troopers were dead or in retirement homes (they had their aging accelerated). The Storm Troopers were standard grunts hired from a thousand colony planets. Kenobi thinks they're the super precise shooting clones he remembers, but he's wrong. The only surviving clone is Boba Fett.
Re:As an Apple hater, I disagree. (Score:3, Informative)
Apple will not reach Microsoft's level of evil until they have a monopoly. They don't. Not even close. I don't like Apple all that much, but the level of Microsoft's evilness in the 90's cannot be underestimated.
NOT ABOUT iOS (Score:3, Informative)
The summary is misleading. The article is about the MAC app store for desktop applications. Was anyone else left scratching their heads about how the heck they would deploy iPhone apps to the public without the app store?
Re:As an Apple hater, I disagree. (Score:5, Informative)
That's not true at all. The standard com.apple.security.files.user-selected.read-write entitlements can handle that very easily. All you have to do is use a standard open dialog to let the user choose a folder, and then write arbitrary crap into that folder or any subfolder within it. Then, save a security-scoped bookmark to that folder if you need to retain access to that folder on future launches. Where things get awkward with that arrangement is when the user copies those files to another machine or restores from a backup. At that point, you'll have to ask the user to open the folder containing the file "foo.wav" or whatever. Then, you can scour the files in there, create security-scoped bookmarks for all of them, and repeat for any other folders full of files.
A much better solution for that problem is to store each project in a self-contained bundle (a folder with an extension, e.g. a .rtfd file, as supported by TextEdit). If you do that, everything just magically works, because instead of opening a project file, the user is opening a folder that contains everything related to a given project. For obvious reasons, that approach is strongly recommended unless you absolutely have to reference files outside of the project for some reason.
That isn't allowed because you aren't allowed to see other apps' windows. It would be a fairly serious security violation if an app could take pictures of other apps that are running and then mail them to the app developer. The same goes for log files that contain data from other applications, preferences files written by other applications, etc. However, there is no reason you can't capture an image of each of your own windows, store a copy of your own log messages in your own file, or send your own preferences file.
Re:Will Apple's own "apps" run in their sandbox? (Score:5, Informative)
A lot of those do. Mail does, the mothership process of Safari does not, but it's "Web Content" processes, the ones that present URLs, do. Quicktime Player does. Facetime and the Reminders app do, the Calendar does not, TextEdit does, the productivity apps don't -- it's pretty much hit or miss, I don't think there's any agenda to it, they just update the apps when they get around to it. I know they'd rather have most of their user-facing apps in a sandbox, so they can't be used as an exploitable surface to their underlying services (the camera API, the filesystem, the sloppy blob that is Quicktime...). Several OS processes run in a sandbox as well, like the metadata indexer and the pasteboard daemon, because they have to crunch through gobs of roudy and arbitrary data and are rather intimate with the underlying system.
But the sandbox and entitlements are about maintaining a chain of trust. If you don't trust the developer, in this case the organization known as Apple Inc, you shouldn't be running anything they make, starting with their OS and hardware, so the question is sorta mute.
The big deal about sandboxing (Score:5, Informative)
I suspect people reading here dont' have a clue about sandboxing or what a BFD it is. Sandboxing is massively overdue. It's been available for years and years in OSX but there has been a zero adoption rate. I came across it in Xgrid, an apple application which relied heavily on it.
Xgrid is a job server that lets other people run jobs on your computer---safely. How the heck do you do that safely and still have left an environment that can do anything at all. You can't do this with linux permissions or firewalls. But you can with sandboxing. in sandboxing you specify in detail what resources every application has access to. What parts of the file system it can't see even if it has unix permissions. What parts of a network it can access. How much memory it can use. etc... It's a universal wrapper that can be created for every program.
Since firefox can be wrapped it's insane to use any browser without wrapping. If some roque plug in contains the ability to do something nasty you dont' care because it can't. it can't access resources it needs. You are essentially shutting down bad behaviour not bad apps.
So why is it not default?
Cause it's annoying to set up. If you take shortcuts in your application based on giving it more privledges than it needs you get punished by the sandbox.
lazy developers hate it.
time to force the issue. it's good for consumers.
It doesn't do anything for apple, other than make the OS better.
Re:As an Apple hater, I disagree. (Score:5, Informative)
It's actually pretty straightforward. The UNIX security model sucks. It assumes that attacks come from the outside, and is designed to protect the user from other users on the same system. In the UNIX model, everything run by a particular user has the same rights as the user. In practice, that just isn't a viable security model anymore.
Consider this scenario: you have a web browser. When everything is working, you trust that the browser is not malicious, so you run it as yourself. Later, you go to a web page and, because of a bug in that browser, somebody is able to execute arbitrary code. Under the UNIX model, that browser can send all your files to a server in Croatia, encrypt them, and extort money from you in exchange for getting your data back.
The only way to prevent such a scenario in a traditional UNIX permission system is to run each application as a separate user. That might be practical for a power user, but it would be insane for most folks. And if you ever wanted to open that JPEG file that you saved with the web browser, you'd have to go in and either change the owner (Finder running as root is a terrifying thought) or set really scary ACLs. No matter how you cut it, that's not user-friendly.
A modern security model must be fundamentally built on the principle of distrust. Distrust everything. Any app could potentially become malicious at any time, whether because the app developer put in a backdoor or because somebody exploited a buffer overflow. It is, therefore, the responsibility of the operating system to not only protect the user from other users on the system, but also from flaws in other applications being run by the same user.
The result is a sandboxing model, in which applications are allowed to open only files that the user has explicitly authorized them to open. Although the user sees a standard file open dialog, when running in a sandbox, the application is not in charge of displaying that dialog. Instead, a system daemon called pboxd (the "powerbox daemon") displays the dialog. When the user chooses to allow that application access to a resource, that daemon then extends the application's sandbox to allow access to that file. In this way, the application has access to exactly the files or folders to which the user has granted it access. No more, no less.
Such a security model is really the only sane security model you can come up with. By using user intent rather than an arcane set of permissions, the user is able to open files in whatever application the user chooses, trusting the operating system to ensure that those applications do not have access to files that the user has not allowed those applications to open. This significantly reduces the benefits gained from attacking security holes in an application.
That's not to say that some apps don't need broader access (e.g. Finder), but it is a worthwhile goal to minimize the number of apps with that level of access, as they are the juiciest targets for attack.
Re:Pray I don't change them further.... (Score:4, Informative)
Bollocks. All kinds of apps are simply impossible to produce within the constraints imposed by the App Store. Like menubar icons that let you plug into iTunes for example (and before you point out that tools like these already exist, I will point out that those are all using temporary entitlements.
I strongly suspect cool apps like TotalFinder also violate no end of App Store policies as well.
Or how about an app that simply goes through a folder and renames/deletes some files according to user parameters (like A Better Finder Rename for example)? Impossible - permission must be obtained by means of a file open dialog for every single file the app wants to manipulate.
Sandboxing is bullshit. Or rather, Apple's implementation of it is bullshit.
Re:App Store (Score:3, Informative)
And it missed a line:
"Disclaimer: Marco Arment, the creator of Instapaper, is likely more than a bit disgruntled with Apple, now that the functionality of Instapaper has been rolled into Safari."
Apple has a history of driving away developers by incorporating their ideas into the bundled apps. Not many developers though... only those of really well thought out OS enhancements.
What you really mean is that Apple has a history of outlawing functionality of a popular app, then promptly rolling the feature they outlawed into their own software. They make Microsoft's history of steamrolling ISVs look positively friendly. In fact, Apple does exactly what everyone here complains about Microsoft doing - except they do it much more frequently.
Re:Pray I don't change them further.... (Score:3, Informative)
That is not correct. Apple is sandboxing Mac OS X and Mac OS apps will have to be sandboxed to be accepted into the Mac OS app store very soon.
When you load up Mountain Lion, you will discover that by default the system will not run unsigned apps, including the ones you bought from them and other notable vendors.
Note that "signed" does not imply "sandboxed". The default Gatekeeper setting means that, unless you do Special Stuff, applications downloaded from the Intertubes (by programs that set the "quarantined" extended attribute, at least; dunno if any applications that set it do so only if they were downloaded from an "external" site, for some definition of "external") can't be launched with a double-click (or, presumably, automatically through some code paths) unless they're from the Mac App Store or signed by a "registered developer", even if they're not sandboxed. There are ways (involving a context menu, i.e. Control+click, I think) to override that without changing the default setting.
I have been resisting learning objective C, hoping to continue writing portable C++ applications against the Unix API's and other well known interfaces like X and python. I don't know yet if the sandboxing system only works for objective C Cocoa programs.
As far as I know, at least some of the sandboxing is ultimately implemented with Mandatory Access Control hooks in the kernel (see the security [apple.com] top-level directory in the XNU source, and stuff it calls and that calls it), which means it applies to anything that makes system calls, either directly or through libraries or frameworks, regardless of whether it's written in C or C++ or Objective-C or Objective-C++ or FORTRAN or..., as long as it's a statically-compiled language (if it's interpreted, the calls are made by the interpreter, which isn't sandboxed, and if it's compiled on the fly, the code that's running the generated code would need to be sandboxed; I don't know whether software of either type is allowed in the Mac App Store). Some of it might be implemented at the Mach messaging level, which means that part applies to anything that sends Mach messages to the services to which access is controlled, either directly or through libraries or frameworks, regardless of whether it's written in C or C++ or Objective-C or Objective-C++ or FORTRAN or... (same comments apply as in the previous sentence).
However, if you want to sell or give away your app via some mechanism other than the Mac App Store, you don't need to sandbox it. To have it launchable with the default settings on Mountain Lion, you'd have to join the Mac Developer Program and get a Developer ID [apple.com] and corresponding certificate with which to sign your code.
(And if you just want to build your own code and run it on your own machine, you don't, as far as I know, even need that, as the code hasn't been downloaded from the Intertubes and thus hasn't had a quarantine label slapped on it. And if you've downloaded the code with, say, curl, that might not slap a quarantine label on it, either.)