Apple is approaching its deadline for requiring that all apps sold in the Mac App Store be sandboxed for security, a policy that is drawing complaints from certain developers.

After the Mac App Store appeared in January 2010, Apple first indicated that sandboxing would become mandatory for all apps sold in the store by November. At the point, the deadline was shifted again until the beginning of March, in part because of complaints from developers and in part because of issues with the sandboxing mechanism itself.

Apple's mobile iOS platform has used sandboxing from the beginning, preventing the spread of viruses, malware and other serious security issues that have plagued other mobile devices ranging from Symbian to Palm OS to Android.

Sandboxing for Security

Apple initially began adding security sandbox features in Mac OS X Leopard. A sandbox provides an app with operating system controls that limit what it can do. The main security purpose of a sandbox is to prevent an app from doing anything it has no need to actually do, so that were it ever to be take over by malware, it simply couldn't do anything bad (within the foreseeable).

Apple has included sandbox support in some of its own apps bundled in Mac OS X, including Safari Web Content (something that helps reduce the damage caused by the Adobe Flash plugin when it fails or is compromised).

Preview and TextEdit also operate within a sandbox, with Preview isolating its PDF rendering in a secondary sandbox to negate any exploits hiding within PDFs. QuickTime sandboxes its video decoders, spinning off the task to processes named VTDecoderXPCService.

When Mac OS X Lion appeared, the system's sandbox support had grown sophisticated enough to be used by many common third party apps. Apple first anticipated that all apps sold in the Mac App Store would be sandboxed, but then gave developers a reprieve through November to study certain cases where this might cause more problems than it solved. The deadlined was then moved to March 1, just weeks from now.

Permissions for apps, just like users

Sandboxing works hand in hand with app signatures, serving as an app-centric security model with similarities to the users-centric file system model. When a user signs into a computer, he has account restrictions that might prevent him from deleting certain system files, for example. However, there's no finer grained control that can allow him to listen for network activity using a trusted app while blocking that same ability in a test app that he knows has no business to be accessing the network.

Sandboxes do for apps what file permissions does to files: they only allow access to certain features that have been designated in advance. Sandbox permissions are called "entitlements" (but share little in common with Android permissions model). There are over two dozen entitlements for app sandboxes in Mac OS X Lion, which range from the ability to read local files, to listening for network connections, to accessing the FaceTime camera to take pictures.

Because there's no way for the operating system to decide on its own what an app "should" or "shouldn't" be doing, developers must create apps that outline what they are designed to do, applying for entitlements that allow them to only do those specific, limited tasks.

Damage containment

By hardcoding an app's abilities to fit within an enforced set of entitlements, apps become safer because a flaw in the app that attempts do to something it has not been given permission to do (such as writing over your personal documents) is simply prevented by the sandbox rules. The same protections also prevent an app that might be infected with a virus or other malware from causing damage it was never expressly given the potential to ever cause.

Apple's sandbox technology is based upon the idea of being easy to use, rather than throwing lots of complexity at the user to figure out. So, rather than asking the user to interpret complex security policies, Apple watches for user intent and complies with what the user is doing.

When a user attempts to open a file or drags a file into an app, Mac OS X assumes the user is signaling an intent it should allow. Apple has built a mechanism for Mac OS X called Powerbox that enables sandboxed apps to open or save files at the user's direction, rather than trusting every app itself with full control of the file system.

Sandboxing can also serve as a way to split up a process into a series of tasks, allowing a heavy lifting component to be tightly secured in a separate sandbox with no connection to outside files or network access, greatly reducing any opportunities for finding vulnerable ways to attack the task, spread to infiltrate the entire program, and then subsequently take over the whole system.

Introducing this new structure and perimeters of security take more work, but it results in software that can better withstand crashes or even intentional attacks by malicious hackers, without suffering damage or at the very least, greatly limiting what the attacker can access.

Deadline approaching

While Apple has sought to avoid excessive work by developers, it wants Mac software to rapidly adopt these security features, and will soon (by the beginning of March) add sandboxing to the other minimum requirements of developers who want to sell software through the Mac App Store.

Apple has yet to bring sandboxing to its own iLife and iWorks apps, having focused initially on sandboxing apps and processes that run plugins or access codecs, such as Safari, Quick Look, QuickTime and Preview. That should change rapidly next month once the company's self imposed sandboxing deadline kicks in.

Apple similarly rolled out incremental enhancements its own bundled apps and separately sold app suites to incorporate support for 64-bit, starting with apps that benefitted most from the architectural shift.

It'll be interesting to see how many apps leave the App Store when they fail to comply or simply choose not to. I've already seen a few leave... but the incentive for being in the store is so great that I doubt it'll be a problem in the long run. Still... it'll be interesting to see.

"VTDecoderXPCService" - what a mouthful. I hope they don't push back the deadline again, I really don't understand the issue in apps specifying the access they want and why. I would understand if it was some fine-grained, onerous list of permissions they had to wade through, but it's not, it's just a few high level switches.

I'm sure there are a few good programs that can't meet the requirements. That is not a problem as long as external installs are supported. Simply put I want to know that Mac App Store apps maintain a certain level of safety.

Personally I don't think we are talking a lot of apps anyways. There will be loud complainers, however I suspect the count will be low.

Quote:

Originally Posted by 2oh1

The Mac App Store opened in January 2011, not 2010.

It'll be interesting to see how many apps leave the App Store when they fail to comply or simply choose not to. I've already seen a few leave... but the incentive for being in the store is so great that I doubt it'll be a problem in the long run. Still... it'll be interesting to see.

Apple's mobile iOS platform has used sandboxing from the beginning, preventing the spread of viruses, malware and other serious security issues that have plagued other mobile devices ranging from Symbian to Palm OS to Android.

If the inference is that Android doesn't use sandboxing, you would be incorrect. It too has "used sandboxing from the beginning", as does Chrome.

...I really don't understand the issue in apps specifying the access they want and why. I would understand if it was some fine-grained, onerous list of permissions they had to wade through, but it's not, it's just a few high level switches.

I think you said it best when you said you "really don't understand" or you would not have made such a sweeping statement.

I think if you were more familiar with the all the models involved you wouldn't so that it is so easy.

Take the case where you want to install a faceless menubar applet. Without the sandbox you can do this in a scripting language -- lets say a plain shell script and then put it in a pkg along with a tool that runs some engine that you or someone else supplies that run from the command line (via the terminal) i.e., a Unix application. Your script then calls this tool to do the real work. So now you have something you want to run that you may not have control over. This is one example that doesn't fit in your simple little world. There are others.

BTW: This sort of thing already caused problems for some stuff that ran as I described -- Apple required that this be all rolled into one "real" application before it be sold through the Mac App Store.

I believe what was being said was that the two concepts are different. Java uses a sandbox for everything (in theory). Since Android is written in Java it uses that model. The Mac OS X is a GUI running on top of BSD Unix and Apple's extensions to that create these sand boxes. They are similar in what they try to accomplish but go about it in different ways.

One more good reason to avoid the app store. Adding sandbox support to an app costs time and money in development and testing, in addition to boxing in capabilities. Pay more for apps that do less? No, thanks. The threat that sandboxing 'solves' is non-existant anyway. Looking down the road, Apple will eventually have app approvals like on the iPhone/iPad.

Dilger fails to address why many developers (and their customers) are unhappy about the restrictions. The article makes it appear that developers are upset only because the new restrictions mean more work for them, and not because it destroys the key functionality of the app.

Unfortunately, every time I see the byline, I know the story will be very one-sided.

The article is listed as a "Feature" and in the very first line says "a policy that is drawing complaints from certain developers". Great, here comes a frank analysis of those concerns, whether they're valid, or FUD; and a conclusion about whether the result in the end will be good for existing Mac users.

I was to be disappointed. Where is the coverage of those concerns?

Having access to the internet and some developer-only resources both of which AI must surely have, I can say they are many and varied.

An example for the non-developer. Would the average user expect an application like Safari to be able to display a HTML file loaded from the local disc? Surely yes; you get an Open Dialog, select the HTML file, and voila! Yet it is claimed that this will not be reasonably possible under the App Sandbox!!! Is that a valid concern or FUD?

Why is it claimed this fails? Well an application in the sandbox apparently only gets access to those files a user selects in an open dialog - the user in this example selects the HTML file, but they don't select any CSS styles sheets, images etc. the HTML file refers to, so the application cannot access them and has no straightforward and user friendly way to do so. Bizarre or FUD?

The above is a simple case of what might be termed the included or associated file problem. It has been pointed out that Keynote can contain references to resources it displays on slides, so that would fail under the sandbox. Want to share some large videos between presentations, sorry you must make multiple copies to fit the sandbox. True or FUD?

The article sadly reads as a PR piece from Apple after that first line, so of course it's great! Maybe it is really great and those developers of top-selling apps expecting to leave the App Store or severely reduce the functionality of their apps are just spreading FUD.

AI, could you not at least include some of the concerns you referred to and allowed the reader to make their own mind up on whether it is FUD?

One more good reason to avoid the app store. Adding sandbox support to an app costs time and money in development and testing, in addition to boxing in capabilities. Pay more for apps that do less? No, thanks. The threat that sandboxing 'solves' is non-existant anyway. Looking down the road, Apple will eventually have app approvals like on the iPhone/iPad.

If I avoid the Mac App Store it means I lose the ability to sync content via my Mac apps to my iOS devices via iCloud.

Sandboxing is really only going to affect a small subset of my apps...a few utilities like Keyboard Maestro, Moom and perhaps some transfer programs that I can purchase outside of the store.

For the rest of the 80% of apps Sandboxing is more code for developers but more security in the end. iOS has far less malware than Android and I expect Mac OS X to have far less than Windows.

He's a mod so he has a few extra vBulletin privileges. That doesn't mean he should stop posting or should start acting like Digital Jesus.- SolipsismX

Take the case where you want to install a faceless menubar applet. Without the sandbox you can do this in a scripting language -- lets say a plain shell script and then put it in a pkg along with a tool that runs some engine that you or someone else supplies that run from the command line (via the terminal) i.e., a Unix application. Your script then calls this tool to do the real work. So now you have something you want to run that you may not have control over. This is one example that doesn't fit in your simple little world. There are others.

Making apps by scripting command line tools together is the Unix way of doing things. It is great for prototyping/ad-hoc apps, e.g. a quick program to explore an idea, such as in an education institution or research lab where this OS was invented. But the Mac (even though it is now based on Unix) has the same monolithic app tradition that Microsoft has, and if you try to break out of that of course you will encounter difficulties. I think that by working in this space you implicitly accept that model, so complaining that your shell script won't work any more is a bit incongruous.

An example for the non-developer. Would the average user expect an application like Safari to be able to display a HTML file loaded from the local disc? Surely yes; you get an Open Dialog, select the HTML file, and voila! Yet it is claimed that this will not be reasonably possible under the App Sandbox!!! Is that a valid concern or FUD?

Well where did they get that HTML from in the first place? If they saved it from Safari it will be a .webarchive, in which case all the sub-resources will be included in the bundle and will be accessible. If they got raw HTML from somewhere else, are they really the average user you are talking about?

Quote:

The above is a simple case of what might be termed the included or associated file problem. It has been pointed out that Keynote can contain references to resources it displays on slides, so that would fail under the sandbox. Want to share some large videos between presentations, sorry you must make multiple copies to fit the sandbox. True or FUD?

Well that one is definitely FUD, because an app can ask for permission to access a user's media libraries (music, pictures, movies). So provided the user is keeping their stuff in the standard places in their home dir, they will be fine. If they are keeping them in non-standard places, well they are bringing it upon themselves.

Sandboxing is really only going to affect a small subset of my apps...a few utilities like Keyboard Maestro, Moom and perhaps some transfer programs that I can purchase outside of the store.

For the rest of the 80% of apps Sandboxing is more code for developers but more security in the end. iOS has far less malware than Android and I expect Mac OS X to have far less than Windows.

Does not iOS have less malware as it is a closed garden and every app has to come from a registered developer (requires some sort of proof of identity etc.) and is reviewed by Apple prior to going in the store?

The same is of course true for the Mac App Store, so what does sandboxing really gain you the user? Unless of course you think Apple is going to make 10.8 only run sandboxed apps (and you believe sandboxing will improve security, probably not a trivial given)? If so then bye-bye to that 20% of apps you'll be purchasing out of the store...

Indeed that is surely a valid question: Does sandboxing actually makes any sense unless Apple is planning a sandboxed-only restriction for 10.8? It avoids any need for a walled garden... (there are somethings no sandboxed app can do regardless of entitlements - scripting for one - leaving such features to Apple-only apps to provide). Food for thought.

Well where did they get that HTML from in the first place? If they saved it from Safari it will be a .webarchive, in which case all the sub-resources will be included in the bundle and will be accessible. If they got raw HTML from somewhere else, are they really the average user you are talking about?

Well some "average" users do actually edit HTML, but you miss the point - it is an example of a kind of whole class of applications.

Quote:

Well that one is definitely FUD, because an app can ask for permission to access a user's media libraries (music, pictures, movies). So provided the user is keeping their stuff in the standard places in their home dir, they will be fine. If they are keeping them in non-standard places, well they are bringing it upon themselves.

So when a group of people are working on a collection of presentations and they pass copies of those presentations and common resources between themselves (by USB stick, network share, etc.) they are "bringing it upon themselves" for not immediately installing those common resources into each user's media libraries? Fine if you really think that, I wonder whether they will. FUD?

BTW iTunes supports not copying music into the media libraries... I wonder if anybody has used that feature to share music from a network volume? (Answer yes.) If iTunes is sandboxed will that be effected?

Some more examples:

- Ever received a compressed file in multiple parts? You need to give permission for each part somehow... (this might have an easy answer which doesn't apply to

- Ever received some C (or other language) program code (think lots of students for a start, not just professional programmers). Such code often includes references to other files... What to analyze it for conformance to security standards - sorry the security sandbox makes that hard...

- Then there are the industry standard file formats used in various fields which apparently fall foul of these restrictions...

The question isn't whether these examples exist, they are very real. The question is whether it is FUD that removing them from the Mac (App Store), or modifying them to fit, will be a big impact on existing users? Currently we hear stories of big production houses abandoning Apple over the uncertainly generated by Final Cut X, is Apple lining up another "wait 2 years and you'll get all your apps back" scenario? Or is all the developers concern FUD?

I'd hoped AI would at least cover this in a "feature" for more than half the first sentence.

Does not iOS have less malware as it is a closed garden and every app has to come from a registered developer (requires some sort of proof of identity etc.) and is reviewed by Apple prior to going in the store?

The same is of course true for the Mac App Store, so what does sandboxing really gain you the user? Unless of course you think Apple is going to make 10.8 only run sandboxed apps (and you believe sandboxing will improve security, probably not a trivial given)? If so then bye-bye to that 20% of apps you'll be purchasing out of the store...

Indeed that is surely a valid question: Does sandboxing actually makes any sense unless Apple is planning a sandboxed-only restriction for 10.8? It avoids any need for a walled garden... (there are somethings no sandboxed app can do regardless of entitlements - scripting for one - leaving such features to Apple-only apps to provide). Food for thought.

Breaches can come from cracks external to the store and so Sandboxing is there as built in quarantine system should an attack come from outside the store.

I'm interested in seeing if scripting can be fortified and thus have the ability to punch through sandboxes. We'll see what's in store. In the long term there has to be a secure way of letting apps communicate and even control other apps to a point.

He's a mod so he has a few extra vBulletin privileges. That doesn't mean he should stop posting or should start acting like Digital Jesus.- SolipsismX

Breaches can come from cracks external to the store and so Sandboxing is there as built in quarantine system should an attack come from outside the store.

Let's see: applications are digitally signed, surely any frameworks they use are (or can be) digitally signed. Will iOS even run an application which fails signature verification (or should it)?

There is an article somewhere on the web which makes this argument - sign everything (and as every developer is registered you can easily give them a unique signing certificate) and either refuse to execute non-signed code or at user option allow it (so, say, students can write and execute their own code). If you do that on top of the existing registration/review you've sown the system up as tight as the App Sandbox does but without removing features. Is this valid?

Some have probably realised I'm playing the devil's advocate on this thread with all these examples - but the article led with promise and singularly failed to fulfill. It is a debate that needs to be had, not blind acceptance that somehow Apple will figure it out without detriment to existing customers (and developers). Yet Apple don't have a good recent track record in this area [Final Cut X, Rosetta, the Rosetta killing "security update", maybe even the Lion update (which was really a sandbox update, not that that was advertised widely) that caused every app to crash for some...) - there seems to a bit of "losing the plot" about all this, oops back into devil's advocate mode! ;-)]

My point is simply, AI could and should have done better - or simply reported "it is coming". A puff piece with a half-line nod to developer concerns surely doesn't meet the bar of "feature". Maybe I expect too much...

I believe what was being said was that the two concepts are different. Java uses a sandbox for everything (in theory). Since Android is written in Java it uses that model. The Mac OS X is a GUI running on top of BSD Unix and Apple's extensions to that create these sand boxes. They are similar in what they try to accomplish but go about it in different ways.

Android is Linux, with a Java VM (Dalvik), and various other tools. Linux uses a permission system much like BSD (and Linux is very secure).

Some more examples:
- Ever received a compressed file in multiple parts? You need to give permission for each part somehow... (this might have an easy answer which doesn't apply to

- Ever received some C (or other language) program code (think lots of students for a start, not just professional programmers). Such code often includes references to other files... What to analyze it for conformance to security standards - sorry the security sandbox makes that hard...

Once again it's a case of using the standard folders. There is a permission "Allow downloads folder access" so as long as people "receive" stuff in here they will be fine.

The "file system" drop down just says "Read Access" and "Read/Write Access" (but it is mediated access, by a file dialog)

Quote:

- Then there are the industry standard file formats used in various fields which apparently fall foul of these restrictions...

The question isn't whether these examples exist, they are very real. The question is whether it is FUD that removing them from the Mac (App Store), or modifying them to fit, will be a big impact on existing users? Currently we hear stories of big production houses abandoning Apple over the uncertainly generated by Final Cut X, is Apple lining up another "wait 2 years and you'll get all your apps back" scenario? Or is all the developers concern FUD?

Well a document on the Mac is either a single file with an extension (.pdf, .zip, .jpg) or a single dir with an extension (.pages, .webarchive).

If other platforms have documents which consist of loose collections of files that belong together, but are not kept is a single dir or archive-type file, that is poor design on their part, and we should not weaken our security model to cater for others' bad design decisions.

Yes, there is a question of inconveniencing people. But there is also a question of how inconvenient it would be for them to lose their files due to malware infection. And the question of how much you let what already exists prevent you from moving to a better place.

The "file system" drop down just says "Read Access" and "Read/Write Access" (but it is mediated access, by a file dialog)

Sorry, I'm lost. Why are you showing the Xcode 4 entitlements setting screen for? I thought the discussion was the impact of sandbox entitlements, not how a developer sets them when creating an application.

Quote:

Well a document on the Mac is either a single file with an extension (.pdf, .zip, .jpg) or a single dir with an extension (.pages, .webarchive).

If other platforms have documents which consist of loose collections of files that belong together, but are not kept is a single dir or archive-type file, that is poor design on their part, and we should not weaken our security model to cater for others' bad design decisions.

I didn't know that an Objective-C project was a package. Or a Dreamweaver project. More sandbox changes I haven't heard about I guess.

Quote:

Yes, there is a question of inconveniencing people. But there is also a question of how inconvenient it would be for them to lose their files due to malware infection. And the question of how much you let what already exists prevent you from moving to a better place.

I'm sorry, this isn't an argument. You need to argue why it is a "better place", and why other ways of achieving the same goals without the same restrictions are not suitable. Or at least try. The simple existence of a potential threat does not make any proposed solution to it a good one by default (unless you're a politician - they often argue that their solution is good simply because the previous one was bad )

Here is an idea: double-click a ZIP archive in the Finder. What happens? Well the Mac's unarchive application (it's not the Finder) opens, unpacks the archive and places it into a folder in the same place the archive is. You've guessed, disallowed by the sandbox... There is no "create a folder in the same folder as my source" entitlement. So under the sandbox the the unarchive application will have to put up a Save Dialog first. Is that good or bad? Sure its less convenient, but that doesn't make it bad, maybe the "extra security" it gives is good. But will the average Mac user (who has never heard of Xcode like you) understand and appreciate the reason for the lack of convenience? Or will they just ask why has everything got harder when Mac's are meant to be easy?

I'm not saying the sandbox is good or bad (I've presented some of the developers' concerns I've read about as the article did not - being the devil's advocate isn't a position, just suggests I'm undecided and was looking for a well reasoned argument. As before I saw an article which started by mentioning the concerns of developers but then didn't cover them and even better give a reasoned opinion on them. Maybe I expect too much of a "feature" article.

Well I think that's enough devil's advocacy, at least in this thread. It's nice to know there is at least one developer (you know Xcode, I'm guessing) who is over the moon about the sandbox.

The last time I was given a USB Stick with files on it when I plugged it in all the files didn't appear in my Downloads folder. Or is that a new sandbox feature I missed?

But typically one doesn't work directly off a USB key, you move files to the local disk, edit them, and move them back. The ability for all apps to access the Downloads folder answers most of your "receiving" use cases in my opinion, because files created by the Mac will presumably follow the Mac convention of using a file package, it is only data from foreign systems that will be more than one file per document. So you need one centralised "foreign imports" folder (in this case "Downloads") to handle these.

Quote:

Sorry, I'm lost. Why are you showing the Xcode 4 entitlements setting screen for? I thought the discussion was the impact of sandbox entitlements, not how a developer sets them when creating an application.

Well you didn't know (from what I could tell) that media library permissions could be granted. And then you did not know about universal access to the downloads folder. So I thought I would save you a third embarrassment by showing you the list of available permissions.

Quote:

I didn't know that an Objective-C project was a package. Or a Dreamweaver project. More sandbox changes I haven't heard about I guess.

I know not every developer has followed the OS conventions, but if they had they would be fine right now. Just like developers who followed the Objective-C method naming conventions can now get Automatic Reference Counting for free. I think the lesson here is to take Apple's conventions seriously, because they're not arbitrary, and they may build features on them in future.

Quote:

I'm sorry, this isn't an argument. You need to argue why it is a "better place", and why other ways of achieving the same goals without the same restrictions are not suitable. Or at least try. The simple existence of a potential threat does not make any proposed solution to it a good one by default (unless you're a politician - they often argue that their solution is good simply because the previous one was bad )

If you have a better solution I'm sure we'd all love to hear it, and see it implemented. I am not wedded to this solution, but I recognise that something has to be done, before we end up like MS Windows, where most people have to run a virus checker just to avoid have their machine become part of a botnet. I do not want that for my computer. This is not a politician's FUD because we have seen it happen on Windows. I don't think it's too much, in this age where every computer is Internet connected, to ask developers to harden their apps.

Quote:

Here is an idea: double-click a ZIP archive in the Finder. What happens? Well the Mac's unarchive application (it's not the Finder) opens, unpacks the archive and places it into a folder in the same place the archive is. You've guessed, disallowed by the sandbox... There is no "create a folder in the same folder as my source" entitlement. So under the sandbox the the unarchive application will have to put up a Save Dialog first. Is that good or bad? Sure its less convenient, but that doesn't make it bad, maybe the "extra security" it gives is good. But will the average Mac user (who has never heard of Xcode like you) understand and appreciate the reason for the lack of convenience? Or will they just ask why has everything got harder when Mac's are meant to be easy?

Well *most* zip files come from the Internet, and this problem does not exist in Downloads folder. And over time, more and more data will come across the network, as networks become ubiquitous and optical drives and USB sticks gradually fade in to disuse.

Quote:

I'm not saying the sandbox is good or bad (I've presented some of the developers' concerns I've read about as the article did not - being the devil's advocate isn't a position, just suggests I'm undecided and was looking for a well reasoned argument. As before I saw an article which started by mentioning the concerns of developers but then didn't cover them and even better give a reasoned opinion on them. Maybe I expect too much of a "feature" article.

Well I think that's enough devil's advocacy, at least in this thread. It's nice to know there is at least one developer (you know Xcode, I'm guessing) who is over the moon about the sandbox.

[Any hint of sarcastic tone above is meant in good humor.]

I personally believe in an iterative software development philosophy where you start with a minimalist set of features, release it, and then make observations. Observe what people really need and really don't, in the wild.

It's not scientific to use your imagination and try to guess up-front what will and will not cause problems. I think Apple has a similar philosophy (observe how spartan most of there 1st gen products are), and if a "create folder in same place" or other permission turns out to be necessary they will add it.

I know I said I'd add no more to this thread, but you tempt me too well

But I'll restrict myself to just a few of your comments.

Quote:

Originally Posted by ascii

I know not every developer has followed the OS conventions, but if they had they would be fine right now. Just like developers who followed the Objective-C method naming conventions can now get Automatic Reference Counting for free. I think the lesson here is to take Apple's conventions seriously, because they're not arbitrary, and they may build features on them in future.

Er, Xcode is written by Apple and doesn't use packages for projects. Naughty, naughty Apple you should have listened to Apple and used them. If you don't listen to yourself Apple why do you demand it of others?

Oh and of course Objective-C files can include files from outside the project, how naughty was it to support that Apple? You should have copied the SDK into the project, especially the third-party ones installed by users you don;t know about, and that project should have been a package!

Apple, sin bin yourself now!

Sorry, I just couldn't resist. As I said "one does protest too much".

Quote:

If you have a better solution I'm sure we'd all love to hear it, and see it implemented.

I thought I'd mentioned other solutions exist/have been proposed for this problem. Are they better? Worse? It's a debate. I was just hoping AI would at least present some of this debate.

Quote:

Well *most* zip files come from the Internet, and this problem does not exist in Downloads folder. And over time, more and more data will come across the network, as networks become ubiquitous and optical drives and USB sticks gradually fade in to disuse.

Naughty me, I use the naughty Finder by naughty Apple to naughtily create and unpack zips in folders other than Downloads.

I'll go join Apple in the sin bin.

Quote:

It's not scientific to use your imagination and try to guess up-front what will and will not cause problems. I think Apple has a similar philosophy (observe how spartan most of there 1st gen products are), and if a "create folder in same place" or other permission turns out to be necessary they will add it.

Surely it's not "scientific" to ignore the huge class of existing real use cases, you seem to be arguing you ignore history and just start again. Sure you're not a politician?

While sometimes you do need to start from scratch, I suspect if Apple ship a Mac OS with lots of features/apps removed with a vague promise "they'll mostly be back in 2 years" - as they did with Final Cut - then I don't expect to see existing Mac users dancing in the streets. Of course they won't actually do that, if developers exit the Mac App Store, and maybe the Mac, it will be a process - and some are clearly planning such exit strategies. Will they go, or is it FUD? Will they be missed? By their customers probably, but by someone looking for a 27" iPad - maybe not.

Apple have been testing this sandbox with developers since last July and those developers have raised quite a few concerns. Nobody is guessing "up-front" here - Apple has a lot of feedback already from people actually using the sandbox. And there seems to be a lot of "I went, I tried, I adapted, I still failed". As a developer you've apparently (from your stance here) listened to all these, decided they are all invalid/unimportant/the developers simply aren't up to the task/or something - and determined all those concerns are FUD.

As I said from the start the AI article held the promise of at least reporting this debate, and maybe even giving an opinion. That has been my point. And that debate has still not been reported, I've sketched a small sample of the concerns, and am I'm sorry but your counters to those sketched concerns don't have the ring of solidity to them - you've even called out Apple (or was it programming language designers?) for not doing things right

Wow. This thread is full of FUD. Maybe a read of the dev guidelines and sandbox operations, not blind contrivances might be in order?

A sandbox disallowing a non-user requested action for a program which has stated in it's development policy that it doesn't need that action without user intervention is not going to put a user at a disadvantage or preclude effective use of the machine.

Editing HTML or C files is not a sandbox precluded action. They are just text, nothing more nothing less. If a user asks to open them for editing, the sandbox won't prevent that. A user requesting to open files on a USB stick or other non-standard location won't be kept from doing those actions -- that's why the file opening dialogs exist in the OS -- they are arbiters of user intent that cannot be easily faked unseen by the user by malicious code.

You have to try really hard to find non-driver level code problems with sandboxes. I'm sure there are a few apps that will genuinely have some hard choices to make, but for the VAST majority of apps this is not a restriction that will compromise what they need to do, even if in more than just a few cases it causes them to do it in a less short-cutty way.

Editing HTML or C files is not a sandbox precluded action. They are just text, nothing more nothing less. If a user asks to open them for editing, the sandbox won't prevent that.

It is not about simply editing such files, or HTML/C in particular - they are just examples. When the user selects one of these files the sandbox of course allows it. However both these kinds of files are examples of those which contain embedded references to other files - the sandbox denies the application access to any of those files.

So as a simple example if you sandboxed Safari and opened a HTML file from the disk (not the network) you'd get no styles & no images as Safari wouldn't have permission form the sandbox to access those files unless it throws up standard open dialogs and access the user to locate them.

It is an issue raised by many developers in many different fields. Are all these developers wrong, have they all failed to adapt, is it all FUD? Personally I expect its a mix, sometimes there will be news ways to do things, sometimes not. I've not heard a simple user-friendly solution to the issue the Safari example demonstrates, the "use a package" certainly doesn't address it in general (developers have argued why it does not).

The announced Apple policy is that after March 1st no new application or *update/bug fix* to an existing application in the Mac App Store will be accepted unless it is sandboxed. So if you are a current customer of a Mac App Store application, a bug comes up, the developer can't sandbox, where do you stand? Developers apparently worry about that, they want to support their customers. As a customer, should I be concerned?

The examples I've posted on this thread are a sample of those I've gleaned from the net, not issues I've made up, I've just been playing devil's advocate. My point was, and remains, that the AI article held promise that it was going to discuss these issues and I was disappointed. @ascii is obviously persuaded that all the developer concerns are FUD, but I was not convinced either way by his/her arguments - I'm afraid I personally saw a hint of "blind faith" in Apple seeping through, so I remain undecided.

Maybe AI will get around to doing an article which fulfills the unfulfilled promise of this one, we can but hope.

Wow. This thread is full of FUD. Maybe a read of the dev guidelines and sandbox operations, not blind contrivances might be in order?

You have to try really hard to find non-driver level code problems with sandboxes. I'm sure there are a few apps that will genuinely have some hard choices to make, but for the VAST majority of apps this is not a restriction that will compromise what they need to do, even if in more than just a few cases it causes them to do it in a less short-cutty way.

And then Apple announces GateKeeper, apparently a way for developers to avoid having to hob-nobble their apps into the sandbox using the techniques previously suggested on the internet as alternatives to Apple's sandbox model... Macworld article

So there will be Mac App Store/Sandbox and Mac Developer/Signed, so maybe, just maybe, all those concerns developers raised weren't FUD and Apple has acknowledged this - (the current) sandbox only would cripple the Mac.

And then Apple announces GateKeeper, apparently a way for developers to avoid having to hob-nobble their apps into the sandbox using the techniques previously suggested on the internet as alternatives to Apple's sandbox model... Macworld article

So there will be Mac App Store/Sandbox and Mac Developer/Signed, so maybe, just maybe, all those concerns developers raised weren't FUD and Apple has acknowledged this - (the current) sandbox only would cripple the Mac.

No, you are reading it inside out. The Mac Developer/Signed is how developers can distribute applications outside the App Store that users can trust more easily because they aren't either from fly-by-nght shops or hacker repackaged with trojans wedged into the .app package.

This doesn't replace anything with regards to the App store at all. This just gives those that can't or don't want to use the App Store a formal way to signify credibility. The choice to stay off store is the same as it always was. We all knew the App Store restrictions weren't workable for all apps or driver makers, so for them they can now get a shiny Apple stickler even though they aren't in the Store. Probably something that will have a financial benefit when all is said and done.

So yeah, you were still focused on FUD before, because this didn't change anything material to how the store works or what the devs choices would be in regards to whether or not they should sandbox their app. Maybe if you, or the whinghing devs spent an hour or two here reading up on the sandboxing and discovering it's granularity you wouldn't persist in making unfounded speculation on what sandboxing actually does and does not restrict.

I just knew I shouldn't have posted, devil's advocacy is hard work here, but really...

Quote:

Originally Posted by Hiro

No, you are reading it inside out.

Sorry no. Sure there have always been apps that couldn't go into the MAS, and sandboxing increases that number - the issue is whether that increase is significant.

The timing of Apple's move to enable non-MAS, and former MAS, apps to be signed with an Apple certificate is probably not coincidental.

I'm a cynic and this move could easily have been well planned. The original sandbox deadline was Nov and it was cancelled with days to spare. When some devs asked why it was left so late I recall one response "do you think we'd have all tested so hard if the announcement was sooner" - you know that has a ring of truth to it, Apple is a business after all...

Quote:

Maybe if you, or the whinghing devs spent an hour or two here reading up on the sandboxing and discovering it's granularity you wouldn't persist in making unfounded speculation on what sandboxing actually does and does not restrict.

Those "whinging" developers have been working on sandboxing since last July. They've been hard at it, they've been discussing (between themselves and Apple engineers) how to do things in the sandbox, what will work, what won't, filing bug and enhancement requests with Apple. Heck for many this is how they put bread on the table, they're not going to sit back and do nothing! To suggest they haven't read the documentation is insulting.

Are all their concerns valid? Probably not. Are some of them? Probably.

Some apps/developers will probably leave the MAS - not because they are whingers but because their apps are no longer welcome. I doubt any developer will shift an app which has no customers, so will not some of those customers ask why the apps they bought and use are no longer acceptable to Apple? Will that create some FUD?

Ask HP, or better yet their lawyers. Heck, I don't even understand the patents with my name on them

Just assume that HP, Apple, and the myriad of other sandbox implementors out there know about this patent. They are currently not fighting over it, so they have either licensed it or don't think it applies to current sandboxes.

Seriously, if you need to know the answer (say because you are designing a sandbox rather than are just curious), ask a professional who specializes in this stuff. A casual scan of that patent would suggest that a lawyer could argue it did, but then lawyers argue red is blue and win.

Ask HP, or better yet their lawyers. Heck, I don't even understand the patents with my name on them

Just assume that HP, Apple, and the myriad of other sandbox implementors out there know about this patent. They are currently not fighting over it, so they have either licensed it or don't think it applies to current sandboxes.

Seriously, if you need to know the answer (say because you are designing a sandbox rather than are just curious), ask a professional who specializes in this stuff. A casual scan of that patent would suggest that a lawyer could argue it did, but then lawyers argue red is blue and win.

i was just curious. Google wanted that particular patent for some reason and HP transferred it to them a few months ago.

ask hp, or better yet their lawyers. Heck, i don't even understand the patents with my name on them

just assume that hp, apple, and the myriad of other sandbox implementors out there know about this patent. They are currently not fighting over it, so they have either licensed it or don't think it applies to current sandboxes.

Seriously, if you need to know the answer (say because you are designing a sandbox rather than are just curious), ask a professional who specializes in this stuff. A casual scan of that patent would suggest that a lawyer could argue it did, but then lawyers argue red is blue and win.

Quote:

Originally Posted by gatorguy

i was just curious. Google wanted that particular patent for some reason and hp transferred it to them a few months ago.

I could see a case being made that this could be a component of sandboxing. But that doesn't mean much with how much of a rubber stamp house the USPTO has been the past few years software-wise. It is as likely as not that someone else already has prior art, maybe even patents, that could be considered to invalidate this.

I also would't expect any other companies have paid this patent the least bit of attention yet. Intentionally. Why? Because if you do a patent search and then get sued later for something you should have understood better in the search you can be hit for the triple willful damages. But if you never do a search and just happen to duplicate functionality in a "clean room" development at worst you can be held for regular damages and if you have good documentation of your clean room efforts you might even be able to claim unfiled prior art and invalidate the other guys patent. Opening Pandora's box is just too risky.

A lot of these patents are more useful defensively for after you are sued because the plaintiff often purposely doesn't know what you have beforehand.

I could see a case being made that this could be a component of sandboxing. But that doesn't mean much with how much of a rubber stamp house the USPTO has been the past few years software-wise. It is as likely as not that someone else already has prior art, maybe even patents, that could be considered to invalidate this.

I also would't expect any other companies have paid this patent the least bit of attention yet. Intentionally. Why? Because if you do a patent search and then get sued later for something you should have understood better in the search you can be hit for the triple willful damages. But if you never do a search and just happen to duplicate functionality in a "clean room" development at worst you can be held for regular damages and if you have good documentation of your clean room efforts you might even be able to claim unfiled prior art and invalidate the other guys patent. Opening Pandora's box is just too risky.

A lot of these patents are more useful defensively for after you are sued because the plaintiff often purposely doesn't know what you have beforehand.

My thoughts hadn't even gone that far, at least yet. I was more just trying to understand what the patent referenced, and whether my reading was anywhere close.

Those "whinging" developers have been working on sandboxing since last July. They've been hard at it, they've been discussing (between themselves and Apple engineers) how to do things in the sandbox, what will work, what won't, filing bug and enhancement requests with Apple. Heck for many this is how they put bread on the table, they're not going to sit back and do nothing! To suggest they haven't read the documentation is insulting.

Well then a huge number of them can consider themselves insulted, rightfully so. For all the professionalism the world of software construction claims, it is one of the poorest run "engineering" areas out there. And the willfulness to NOT read documentation is legend in the software industry.

For every two that will read it, a half dozen won't read anything until they are explicitly told to by their boss/lead. You think independent devs are any better than the rest of the industry? No they are just part of the same cross section.

The guys not complaining are making money. Those who are complaining loudest are usually making the least. Of course there are the occasional exception to the generality, but they will be relatively rare.

Well then a huge number of them can consider themselves insulted, rightfully so. For all the professionalism the world of software construction claims, it is one of the poorest run "engineering" areas out there. And the willfulness to NOT read documentation is legend in the software industry.

For every two that will read it, a half dozen won't read anything until they are explicitly told to by their boss/lead. You think independent devs are any better than the rest of the industry? No they are just part of the same cross section.

The guys not complaining are making money. Those who are complaining loudest are usually making the least. Of course there are the occasional exception to the generality, but they will be relatively rare.

after arguing that those developers concerns are all FUD you point us to a web item (which strangely, I'd already read, remember my referring to concerns expressed on the internet?) from a developer who express concerns over the sandbox, recommends that Apple should "make an exception" in the MAS for legitimate code that doesn't run under it (Apple have not done so in any general sense, some apps are apparently being forced to reduce functionality due to sandbox bugs if they wish to stay in the MAS - exactly what Shipley talks about), and concludes that Apple should make certificates available to developers so they can sign apps (including non-sandboxed) outside the MAS - and that is what Apple has just done.

So in short you agree its not all FUD and the Apple move addresses some, but not all, of the sandbox limitations.