story
Now, say a game or web browser that runs potentially malicious content, sure, sandbox it. But other things like code interpreters, low level Unix tools, or inter process tools like AppleScript, they're still open to (mis)use by anyone.
I'm going to guess that most malware for OS X will soon become non-compiled scripts. Sure, the interpreter would be signed, but what it runs is totally arbitrary.
I'm a user of one of Apple's "pro" applications, Logic Pro 9, a top music recording software (or DAW). I started using it long before it was put in the appstore, and was surprised when they moved it there, as it was a 5 DVD install.
Anyways ... the tool interacts with plugins written in a Logic Pro independent standard, VST. It burns CDs. It manipulates midi through wifi, usb, and firewire. It reads third party provided sound samples and loops. It manipulates analog instrument interfaces through firewire ...
Is Apple going to cripple Logic Studio? Or will they also have to take their "pro" software out of the appstore?
Unfortunately, it appears this may be a "do as I say, not as I do" situation.
The whole point of sandboxing is to reduce the damage a badly written or mal-intended application can do to a system.
Surely Apple TRUSTS their own apps.
The answer is simple, Apple's apps will have special access that will make them better than 3rd party apps which have to jump through all these hoops.
Actually, Logic Pro does not interact with VST plugins at all. It interacts with AU (Audio Unit) plugins. Plugins like Native Instrument's etc that come as VST plugins also come in AU versions.
Is Apple going to cripple Logic Studio?
No, Apple is not going to cripple Logic Studio. They even said so, a few months ago.
Or will they also have to take their "pro" software out of the appstore?
They can also do whatever they want with THEIR apps in the appstore, like have them there despite not implementing sanboxing, or giving them arbitrary sanboxing rights (after all, Apple TRUSTS their own apps not to be malware).
In theory, all the games and apps have to sign/encrypt/check everything they load. But I can't believe they will all implement this correctly or that Apple will find all the subtle bugs when reviewing.
The only way to parlay that into control of the system would be to break the sandbox. And then, because OS X default security is fairly sane, the only way to do real lasting damage is to use a further exploit to escalate your permissions.
Also, I guess it depends on what the app does and what you mean by "real lasting damage".
http://events.ccc.de/congress/2008/Fahrplan/events/2799.en.h...
Splinter Cell and MechAssault where famous for this. The bug is actually in the XBox Dashboard code itself, so the Host system was buggy.
--------------------------------
Starting in Mac OS X v10.6, the NSURL class and the CFURLRef opaque type each provide a facility for creating and using bookmark objects. A bookmark provides a persistent reference to a file-system resource. When you resolve a bookmark, you obtain a URL to the resource’s current location. A bookmark’s association with a file-system resource (typically a file or folder) usually continues to work if the user moves or renames the resource, or if the user relaunches your app or restarts the system.
In an app that adopts App Sandbox, you must use a security-scoped bookmark to gain persistent access to a file-system resource.
Security-scoped bookmarks, available starting in Mac OS X v10.7.3, support two use cases:
• An app-scoped bookmark provides a specific sandboxed app with persistent access to a user-specified file or folder.
For example, if your app employs a download or processing folder, present an NSOpenPanel dialog to obtain the user’s intent to use a specific folder. Then, by creating a security-scoped bookmark for that folder and storing it as part of the app’s configuration (perhaps in a property list file or using the NSUserDefaults class), your app acquires a means to obtain future access to the folder.
• A document-scoped bookmark provides a specific document with persistent access to a file.
For example, a code editor typically supports the notion of a project document that refers to other files and needs persistent access to those files. Other examples are an image browser or editor that maintains an image library, in which the library file needs persistent access to the images it owns; or a word processor that supports embedded images, multimedia, or font files in its document format. In these cases, you configure the document format (of the project file, library file, word processing document, and so on) to store security-scoped bookmarks to the files a document refers to. (A document-scoped bookmark can point only to a file, not a folder.)
A document-scoped bookmark can be resolved by any app that has access to the bookmark data itself and to the document that owns the bookmark. The document can be a flat file, or a document distributed as a bundle.
--------------------------------
"Click the button below, locate file xyz and 'Open' it to proceed"
I would be perfectly ok with a system "Grant permission to xyz" dialog, but the open file dialog is a terrible way of requiring access to a file or folder.
Rather than presenting it as some pointless mechanical chore in which you direct a user to a specific file in a known place, wouldn't "Choose where you would like Foo.app to save your XYZ (project/file/whatever)" make a lot more sense?
Imagine for instance an application that helps you clean up your downloads folder, but wouldn't be appropriate to use on other folders on your system. It's not the best example, but it illustrates how much of a usability mess it is to ask the user to locate the folder for you through an open file dialog, and then have to reject it if they select the wrong thing.
For the duration of the company's existence, one of their biggest customer segments has been the creative industry. I can't think of a single pro audio/video/graphic/etc app that doesn't make extensive use of plug-ins, another Mac App Store disqualifier.
Do the developers of these apps necessarily have a "right" to iCloud APIs, delta updates, and other benefits of playing in Apple's sandbox? Of course not.
But is Apple harming themselves and their customers by excluding the creators of these apps from the party and potentially causing them to focus their development efforts elsewhere? I think they may be.
I would have thought the Final Cut Pro X debacle (http://pogue.blogs.nytimes.com/2011/06/23/professional-video...) would have served adequate notice to those folks that Apple doesn't consider them an important market segment anymore...
I don't know if you have used/use Final Cut 6/7, but it is a phenomenally ugly, often poor performing, generally unintuitive piece of software. I can see where the motivation for a full reboot would stem from.
Now, a reboot that involves consolidating formerly modular panes into a single window when the target market typically works on two, three or more displays is just dumb. A reboot that was, as a practical matter, 0% backwards-compatible may have been necessary, but if it could have been avoided, it should have been. But buried under all the mistakes, I think there was some genuine good intent (yes, I know I'm grasping at straws).
I primarily work with music, and you don't need to be as involved as I am or attend as many shows as I do to know that for any artist/band that uses a laptop on stage, the MacBook Pro is the de facto standard. The same applies to Mac Pros in studios (although those boxes may be going the way of the Dodo as well).
None of this necessarily makes a difference to Apple; the new features in Mountain Lion which focus on Chinese web portals and social networks serve as a reminder that the emerging Chinese middle class is likely as important a segment to Apple as any, and the number of potential customers in that group already dwarfs the ranks of every DJ, producer, sound engineer, and electronic musician on earth.
Still, it would be a great disappointment to me and many others if Apple were to abandon such a loyal group of customers who helped them reach this point.
[1] http://www.tuaw.com/2012/01/31/apple-updates-final-cut-pro-x... [2] http://itunes.apple.com/us/app/final-cut-pro/id424389933?mt=...
Unlike, say, Adobe, that merely piles incremental bloat upon incremental bloat, and calls it a "new version of the suite".
The complains are from people that:
1) see a black interface as some kind of iMovie-fication (iMovie is black, so they have dumded down FCP).
2) Think professional software means convoluted GUI (they made things simpler, so they have dumbed it down)
3) Expect a rewrite of a 10+ year old codebase to have feature parity with the old version from day one.
4) Expect a rewrite of a 10+ year old codebase, with the intention to support modern movie making practices, to also cater for obsolete practices that the old version covered (like tape editing).
Having said that, I've had far too many conversations with far too many professional filmmakers and editors (I'm talking "multiple all-nighters every week editing multicam RED; invitations to Cannes; contracts to produce music videos for multi-platinum selling artists and promos for Fortune 100 companies" professional) about the weaknesses of Final Cut X to have much regard for the opinion you've shared here.
Ultimately, if the intended users are dissatisfied, then Apple missed the mark, any rationalizations from armchair analysts notwithstanding.
By the way, you left a complaint off your list: Zero compatibility with project files from previous Final Cut versions. Hope you've got some free time to recapture everything you've ever shot.
I guess I should step back a bit and make my argument more clear. I'm not opposed to the concept of sandboxing, I recognize the benefits of these policies as Apple's user base grows and malware becomes a greater concern.
My contention is that the imposition this places on users and developers alike will most likely dissuade pro media software developers from participating in the Mac App Store to begin with, thereby depriving Apple of potential income, depriving developers access to useful features like iCloud file sharing/mirroring, and exposing users to the very risks this policy is intended to shield them from.
I also disagree that extensibility is in conflict with sandboxing. As for pro media software developers, I'm pretty sure it's just a matter of time and polishing of the platform. AutoCad LT is already in.
Yes. Is that hard to grasp? Sanboxing is safer than the old distribution practice. You won't find any security expert to disagree with this.
Thus, every pro media application distributed without sandboxing was LESS safely distributed than a sandboxed one.
They're just disallowed from supporting plugins in the manner that they have been on every platform for 20 or 30 years.
Wholesale changes in OS or environment runtime? Changes in underlying processor architecture? Forced update to full 64-bit support? Customers wanting to operate on files that are an order of magnitude larger?
If these apps have any claim to being worth hundreds or thousands of dollars per seat, and charging hundreds of dollars for basic compatibility updates, their developers should Pro-up and deal with this change like they've dealt with others.
And given the motivation for the change, I think they should skip the complaining step and lean into the work.
Um, no. If there's one thing that's more private than my address book, it's my ssh keys. The fact that they aren't available to your application by default is a feature. If you need a key, ask me for it. If I want to give you the access, I'll do that.
There are other tools that do similar in other OS's, for example the "keychain" script in Debian. This isn't something weird IMO.
That part is done. The application shouldn't be asking for SSH keys, it is completed already. Just use `ssh` as you would before.
Very very popular apps like:
Chrome
Photoshop/Adobe CS
Fusion/Parallels
Microsoft Office
Text Editors
FTP Clients
Dropbox
The Mac App Store loses a bit of its allure when you get your new MacBook Air [even as a non developer] and can't find basics like Chrome or Dropbox or Microsoft Office in there.
I can testify about that. I just bought MBA recently and opened up App Store out of curiosity, however almost all of software I needed I bought at writer's store (apparently there is final draft now in app store, but I bought directly from Final Draft). Same goes for Office, Chrome, Dropbox, etc...
> Chrome
"Safari."
> Photoshop/Adobe CS
"Creatives? Did you see what we did to Final Cut? Have you noticed how little we talk about the Mac Pro anymore?"
> Fusion/Parallels
> Text Editors
> FTP Clients
"We're in the consumer products business, not the 'tools for nerds' business. Ask an XServe customer if you want more information."
> Microsoft Office
"We could care less if we sell boring-ass business software into enterprises."
> Dropbox
"iCloud."
As someone who has lived through a protracted antitrust review (Google acquiring ITA Software, a company I co-founded), I can tell you that there are dozens of hard-working people at the DOJ and FTC ready to make their careers on taking Apple down should Apple give them the tools to do so. A "some animals are more equal than others" app store policy -- whether intended or unintended -- is definitely fodder for a juicy DOJ/FTC lawsuit.
That gives a photo editor, a movie editor, spreadsheet, and word processor.
iWork is a much better and more user-friendly set of software than MS Office (unless you're an Excel power-user, in which case the OS X version of Excel probably isn't cutting it for you either), but it's tough to recommend it for non-technical people who need to work with Windows folk.
What DID they do to Final Cut? They spend tons of money and engineering time to rewrite the app from scratch with a modern codebase and added new innovative features. The got it to 64bit, they added the magnetic timeline (HUGE timesaver), the improved tons of workflow stuff, they made it take advantage of multiple cores, and they made it work with files in whatever format they are in to begin with.
In the process, as with any version 1.0 app, FPCX lost a few of the features that the old, bloated, version of FCP had. Some because you just cannot just scratch from scratch and replicate absolutely everything at once, and others because they don't make much sense moving forward. Some of those features, like multicam editing, they delivered in subsequent minor versions (of which there have been 3 already).
That is much more than what Adobe does, which is incrementally adding a few features, without ever rethinking their apps, and keeps adding bloat upon bloat (Flash based custom panels, anyone?) to the same 10 or 20 year old codebase. Apple betted on the future, Adobe plays it safe.
So, I beg to differ in respect to FCP X.
Have you noticed how little we talk about the Mac Pro anymore?"
And why should they? A quad core iMac is just as capable for the needs of 90% of creatives, and in fact, if you looked at any design studio in the past 2-3 years you were more likely to find one of those than a Mac Pro or a G5.
They also know that they sell a very small amount of those Pro machines, and it's not like Intel is making new chips for them all the time.
Besides, Thunderbird, the Apple/Intel interconnect perfectly suited for professionals and creatives that no other PC vendor took the time and effort to create, solves most of the connectivity issues that an iMac (or even a MacBook Pro laptop) had related to a Mac Pro.
2. As of iOS 5, the platform has native Audio Unit support. I haven't seen much use of it, more commonly devs have been porting their work to JUCE (as in the case of the Auria iPad DAW, which features some popular third party plug-ins as in-app purchases).
I don't understand: What prevents an app from having an "Add Plugin..." dialog that uses the sandboxed file browser to locate a plugin library in whatever sensible format?
As a practical matter, it would require anything up to and including a full rewrite of every pro media creation app on the market. The standard to date has been that there is a specified folder for plug-ins, and the host scans the folder for installed plug-ins on startup.
One benefit of this arrangement is that the user must install the plug-in only once to have access to it in any application that supports its plug-in format. Let's use pro audio apps as an example. I use Ableton Live and Native Instruments Maschine as my primary compositional tools, but I prefer to mix/master in Reaper. Given your alternative method, when I purchased Madrona Labs' Aalto, one of my favorite virtual instruments released in recent memory, I would have needed to endure three separate installation processes to have access to the plug-in in each app where I might want to use it.
Additionally, Maschine happens to have the ability to run both as a standalone application and as a VST plug-in. Let's say I sketched out a beat in Maschine standalone, using Aalto to produce some cool Buchla bongo sounds. Later, in Live, I insert an instance of the Maschine VST and open my project file for further processing. Do I now have nested sandboxes? Will it work at all?
Things get even more complicated when one considers the plug-in developers who require iLoks (license verification USB dongles). These seem even less likely to be compatible with Apple's new processes. Don't get me wrong, I hate and refuse to use iLoks, and by extension any software which requires them. But many Pro Tools/Waves/Soundtoys/etc users are just used to the inconvenience of a hardware dongle at this point, and the companies I mentioned have many satisfied customers.
It seems to me more likely that rather than rewriting their apps or fundamentally adjusting their license verification practices, many of these developers will simply avoid the App Store altogether. As a consequence, users suffer.
Sorry I can't point to individual forum threads at the moment.
I wonder if Apple might give some companies of just distributing the installer via the app store as well.
1: future anti-trust cases or congressional testimonies nonwithstanding
Sure, iDevice developers have no choice. But for desktop software there's this handy thing called the Internet. Why kick up revenue to apple, subject myself to submission rules and arbitrary rejection, absurd technical limitations and switcheroos like the one described in this article, and all the rest?
Right, there are no success stories.
"Why kick up revenue to apple"
People keep saying this like Apple doesn't deliver buying customers and revenue. The app store making a profit on sales is exactly how every other store in the world works. Why does Apple 'kick up revenue' to Amazon when they could just sell all their iPads online through Apple.com? The answer is because lots of people shop at Amazon and Apple will sell way more iPads with Amazon then without them.
"If the app store can truly compete with an open marketplace"
As it turns out there is an open market for iOS apps and an open alternative to iOS and Apple's walled garden is competitive with both.
"why won't apple let me install arbitrary software on my iDevice?"
Aren't the reasons obvious? Simplicity, profit, security?
You might as well be asking why your Macy's card doesn't work at Sears or why you can't make a copy of your building key at Sears or why.. hey just what does Sears have against freedom anyway?
Example: The Keychain application from Apple (used to store certificates, private keys and passwords) is using a encryption algorithm that is too weak for what it is used - namely: DES. You can break it with a reasonable amount of money.
Wouldn't it make more sense to improve these kind of things first? We would gain so much more security with a minimal effort.
"All the password data in the keychain is protected using the
Triple Digital Encryption Standard (3DES)."
"NIST considers keying option 1 to be appropriate through 2030."
Source? This is relevant to my interests. Namely, I'm trying to figure out if using something like 1password or other services would be worth it. Thanks!
I don't know what the best solution is. Possibly allowing non-sandboxed apps in the app store, which go under extra review (possibly with a premium charge to defray the cost of extra review), or requiring the user to select a 'do not sandbox this' option when installing the app.
However, Apple can't give this app what it wants while keeping the integrity of their sandbox.
The goal is to create the most secure running environment that is possible. Allowing random apps to access/modify different files on the system (without user explicitly allowing that) kinda defeats the purpose of sandboxing (from user's point of view - from developers POV, sandboxing makes his app more secure and stable).
All I see is people ranting about sandboxing's limitations, without coming up with actual plans to improve it.
Is that a bad thing? I'm not saying it will happen soon, or that those of us long in the tooth will go easily, but I honestly think it's the future.
Think about young teenagers who will soon be "in charge". They snap a pic on their phone and send it to someone else. Nobody cares where it is in the filesystem, or even what the filename is. I used to meticulously name, tag and organize my mp3 collection into folders and sub-folders. Now I don't even know where they are on my hard drive - because I just don't care.
Those are old concepts we used to rely on to find and use information stored inside the computer, but I honestly don't see the need for the in the future. We can stop focusing on the "how" of the computer, and focus on the doing.
I will add that "power" users like developers will require these kind of concepts for a lot longer than your average Joe, but I still see it becoming less and less important.
Files are more popular and profitable than ever. You have companies like Dropbox and Box.net making serious money. Yes, I can see that we may one day not need to expose the concept of filesystems to an end user but I think it will be a very very long time (like generations) unless there is some revolutionary new computing concept besides the ones we have today.
[1] http://googlesystem.blogspot.com.au/2011/05/how-google-docs-... [2] http://www.telegraph.co.uk/technology/google/9071936/Google-...
If tags are a way that you can definitely find and specify a given file, then tags will form part of a new, distributed file system. If tags wind-up just being half-assed, uncertain hints to where files might be, then they will form part of a new, disfunctional distributed file system. And the later case seems to be where things are going. This "hints but no certainty" approach to file location indeed works great most of the time and fails frustratingly significant percent of the time.
But even here, this is a file system even when it is often dysfunctional.
I saw that iCloud file storage will support folders like the iPhone home screen, but I have no idea if they will support nested folders. This isn't only the case with nerds and geeks. My mother, about as computer phobic as they come, is a minister, and she saves all her sermons for future reuse. They are categorized by specific topic using folders. Also related documents from different applications can use folders to be organized together.
There are a lot of features of filesystems that we take for granted, abstracting it away without providing a usable alternative is problematic.
It is a very bad thing. I agree that it looks like this is where the industry is going, and I really, really, really dislike this direction.
Files are an incredibly useful abstraction. Sure, there are programs that work with photos and songs, but thee's a whole class of applications that works with "data" no matter what this data is. Think of stuff like backups, synchronization, compression, encryption, etc. If somebody comes up with a new encryption algorithm, filesystem lets me instantly use it for all my data regardless of which application I used to create it. But we're heading towards the world where we need one program to backup photos and another one to backup songs, and only OS manufacturers are allowed to create utilities that work with all my data in general. This is not good for innovation.
If you find it so objectionable, go build your own hardware and OS platform. This isn't a matter of human rights because no one is telling you that you can't make your own.
The RDF is on full effect there, I see. You might want to look at systems like the Xerox Alto & Star, both released before the Lisa. The implementation was certainly excellent - and I have a lot of respect for the Lisa and Macintosh engineers - but many of the concepts were invented elsewhere.
So... Apple generally gets kudos for 'giving users what they want', but users are not allowed to say what they want?
Nice work.
You're comparing Apple's ecosystem to Earth's.
Apple is a private company that makes products that are sold on the commercial markets. The Earth is something entirely different. If Apple made planets, then yes – they could decide how to manage the atmosphere. That's how business works.
It's very similar to their support for "multitasking" on iOS. Handle the common cases well, most others will find some way to make it work, and the rest are out of luck.
It's also important to note that the point of black hat hackers is to get around limitations. Without putting serious teeth into the sandboxing, it's largely pointless and security theater.
I think now might be the time for a rival App Store to set up shop before Apple locks developers into only releasing through their approval process.
Maybe I'm over reacting, but an ounce of prevention is worth a pound of cure.
So basically, it's notable that some applications are having difficulty with the first iteration of these new restrictions, but it's not surprising and I'm confident the issues will be resolved in time. Meanwhile, we've all survived without the App Store for a long time. I think these applications can survive. This is not the time for outrage.
http://techcrunch.com/2012/02/16/os-x-mountain-lion/ (scroll down to Gatekeeper)
Here's hoping that 10.9 doesn't disallow such installations at all (or void your warranty instead?).
So while you can abandon the App Store without penalty, you shouldn't stop paying Apple the $99 a year you need to do so to get the app signed, even if you aren't going to sandbox it or distribute it through the MAS. They just want the option of pulling a cert for a dev found to be distributing malware, not to personally review and reject every application that runs in OS X.