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).
Linux, Android, BSD, etc.. (most Unix based OSes) all have user and app permissions, sandboxes, etc...
- 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.
Here is a picture of the permissions window from someone's site (not mine) - the very latest version also has iCloud options, but this is pretty close to current:
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.
While I might be taking the role of devil's advocate, I must say you "protest too much".
Quote:
Originally Posted by ascii
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 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?
Quote:
Here is a picture of the permissions window from someone's site (not mine) - the very latest version also has iCloud options, but this is pretty close to current:
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.
[Any hint of sarcastic tone above is meant in good humor.]
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
everything work the way you want? out of the box? no and no
apple has great track record capturing money, but fail in the actual products backing up marketing hype. hope there is a place to go when you want to jump ship.
Quote:
Originally Posted by Mikeb85
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).
Linux, Android, BSD, etc.. (most Unix based OSes) all have user and app permissions, sandboxes, etc...
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.
I've obviously not been clear, so a quick comment:
Quote:
Originally Posted by Hiro
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.
This sounds like Apple is grafting in capability-based security into Mac OS through sandboxing, much like HP Lab's Polaris did for Window some years ago.
I'm going to have to go read the documentation on this...
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.
This sounds like Apple is grafting in capability-based security into Mac OS through sandboxing, much like HP Lab's Polaris did for Window some years ago.
I'm going to have to go read the documentation on this...
After reading through the basic developer documentation on App Sandbox, it's mostly sandbox with fine-grained permissions to reach outside with a few capability-based security style features, notably the Powerbox. Fine-grained permissions systems tend to be a pain for developers which leads to their effective security to be less than their potentially achievable security as developers simply request more permissions than they actually need (though Apple as application auditor will probably provide pressure to reduce unneeded permissions). Also, the permissions are almost all static rather than dynamic, also leading to more permissions than required at any point in time.
The main exceptions are due to the Powerbox (the capability-based security bit), which are nearly transparent to the developer and user and provide the right amount of access required dynamically.
Comments
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).
Linux, Android, BSD, etc.. (most Unix based OSes) all have user and app permissions, sandboxes, etc...
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.
Here is a picture of the permissions window from someone's site (not mine) - the very latest version also has iCloud options, but this is pretty close to current:
http://oleb.net/media/xcode-4-1-sand...screenshot.png
The "file system" drop down just says "Read Access" and "Read/Write Access" (but it is mediated access, by a file dialog)
- 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.
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.
Here is a picture of the permissions window from someone's site (not mine) - the very latest version also has iCloud options, but this is pretty close to current:
http://oleb.net/media/xcode-4-1-sand...screenshot.png
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.
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.
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.
[Any hint of sarcastic tone above is meant in good humor.]
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.
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.
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.
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.
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.
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.
But I'll restrict myself to just a few of your comments.
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.
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".
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.
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.
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
Enough, being the devil's advocate is exhausting.
Look at the track record.
iOS apps 'sandbox' as expected? no
quality of apps gone up? no
better choice of apps? no
everything work the way you want? out of the box? no and no
apple has great track record capturing money, but fail in the actual products backing up marketing hype. hope there is a place to go when you want to jump ship.
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).
Linux, Android, BSD, etc.. (most Unix based OSes) all have user and app permissions, sandboxes, etc...
That is quite ture.
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.
I'm going to have to go read the documentation on this...
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.
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...
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?
Do you happen to play video games on a Pippin?
Does this patent seem to apply to it?
http://patft1.uspto.gov/netacgi/nph-...&RS=PN/7398532
A question for you guys, since it's apparent a few of you are pretty darn knowledgeable about sandboxing.
Does this patent seem to apply to it?
http://patft1.uspto.gov/netacgi/nph-...&RS=PN/7398532
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.
a question for you guys, since it's apparent a few of you are pretty darn knowledgeable about sandboxing.
Does this patent seem to apply to it?
http://patft1.uspto.gov/netacgi/nph-...&rs=pn/7398532
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.
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.
Just go read Shipley and stop being afraid.
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.
Just go read Shipley and stop being afraid.
So in short you agree its not all FUD and the Apple move addresses some, but not all, of the sandbox limitations.
And your point in calling it all FUD was?
This sounds like Apple is grafting in capability-based security into Mac OS through sandboxing, much like HP Lab's Polaris did for Window some years ago.
I'm going to have to go read the documentation on this...
After reading through the basic developer documentation on App Sandbox, it's mostly sandbox with fine-grained permissions to reach outside with a few capability-based security style features, notably the Powerbox. Fine-grained permissions systems tend to be a pain for developers which leads to their effective security to be less than their potentially achievable security as developers simply request more permissions than they actually need (though Apple as application auditor will probably provide pressure to reduce unneeded permissions). Also, the permissions are almost all static rather than dynamic, also leading to more permissions than required at any point in time.
The main exceptions are due to the Powerbox (the capability-based security bit), which are nearly transparent to the developer and user and provide the right amount of access required dynamically.