AppId is over the quota
First, I'm amused that several people think Apple's going too far by ordering sandboxing of MacOS X apps, especially since so many folks (mainly Android/Linux and Windows folks) often criticize Apple for being too lax about security. Damned if you don't, damned if you do, I guess.
That said, I'm all for security, but I don't really see the proposed method of "sandboxing" as being particularly effective.
First, Mac apps don't need to be installed through the App Store, as with iOS -- folks can just download any old app. And I think that's a good thing -- freedom of choice and all that -- despite the potential downside. But since apps can come in from "anywhere", those non-approved apps can do things any which way they like and potentially nuke your system, even if the Mac App Store apps can't.
Which brings me to point #2: this is done on the honor system (though enforced by Apple for apps going through the App Store). Anyone remember the old Mac OS days when it was up to app developers to code their apps to play nice with other apps, since the app (not the OS) had full control of the processor and direct access to hardware when it was the active app? Despite good intentions, things didn't always work out well. And some folks just didn't know how to play nice. And there are those that don't want to ... or at least won't bother.
Third, this will inevitably lead to painful changes for end users in how they use their systems. At the very least, they'll have to relearn how to use their systems. Or they may find that certain things will no longer be possible. Without access to files outside the app, how would one open a PDF in Preview, for instance, if it's ID'd as an Adobe Reader doc? Or how about opening a random JPG image into PhotoShop if you can't go into PhotoShop, choose "Open..." and browse to the file that's stored in some other app? This will cause huge workflow headaches that people wrestle with in iOS when they start to try to push the boundaries by trying to replace their desktop/laptop with, say, an iPad. The iOS "files in the app" model works partly because those devices have some practical limitations (in part because of these sorts of issues, but also because of screen size, input devices, etc.). But the Mac OS does more and has more complex apps. And we have decades of history of doing things certain ways -- ways that people like working and which fit well with certain workflows.
To me, it seems like Apple needs to spend a little more time thinking outside the box on this. They've done all these incredibly complex migrations in the past -- stuff no one had ever done before, like migrating from the 680x0 to the PPC without a hitch ... and then to Intel ... and from MacOS to Rhapsody to OSX ... and other stuff. They're smart people. They know how to make things seamless and effective. But the proposed approach doesn't seem like either.
I'd love to "hear" others' thoughts on this. I'm sure I'm missing something, but to me, it seems like Apple needs to make the OS more restrictive and force developers to call upon it to open, save and execute files so that executable files can only be installed to and launched from certain directories, and so that data files are always written to directories from which nothing can ever be executed ... only read or saved. Separate the operational files from the data files and have the OS prevent the two from intermingling. Sorta like how cookies are only accessible by the server/domain that set them. And any non-Apple apps should be installed in such a way that they run in a more restricted manner -- limited calls or better validation or something -- that prevents them from doing things that they shouldn't be allowed to do, to prevent buffer overflows and whatnot. (I'm reminded -- of all things -- of NASCAR's change to its rules system a few years ago when it switched from specifying what's against the rules to specifying only what is allowed and clarifying that anything else is specifically disallowed. It's a sucky system for racing, but perhaps a good model for app security?)
Apple might even be able to implement changes solely within the OS itself, eliminating any work for developers -- just change how the OS handles calls to open, save or execute files, and change installation processes to do more validation, better error trapping and be more restrictive. Then, if someone tries to write an app that would inappropriately access stored data other than its own or to gain escalated privileges, it wouldn't matter: the hardened OS could refuse the call or could at the very least present a warning dialog (or two) in an attempt to even head off social engineering attacks. Perhaps it could/should be couple with encryption so that only the OS can de-crypt files so that they can be read or executed? That way, even if an app somehow tricked the OS and gained access to data, it'd be virtually useless. (I can imagine scenarios that might complicate this -- data shared through a server with Windows or Linux boxes, for example ... that would have to be decrypted data ... and what about files coming from those machines? But again, those could be forcibly stored to restrictive directories ....?)
So (and I'm asking this honestly) why wouldn't something like what I've described work? I must be missing something -- it just seems too easy.
No comments:
Post a Comment