Isn't the real problem that people want a better curated market? Cut down on the spam, apply standards for permissions, make sure apps don't use the 1.4 security model (did that even ship on any phones?).
I understand why Apple likes the App Store model and process, and the huge revenue they get from it. But I have never understood why any developer or consumer would consider it a benefit that outweighs its many negatives (higher costs, slower development, limits on application capabilities, extreme difficulty deploying custom apps, inability to develop applications that compete with Apple products, etc.).
It doesn't require a curated market to kill off 1.4 API features. A new version of the OS can do that, as can standards for permissions. Why would you believe having standards imposed by fallible humans with a limited view of the application could ever do a better job than the OS itself? Assuming the decision was made to correct these security risks, it's obvious, to me anyway, that doing it in software is the only reasonable way to do so.
The objection to the app store, in my mind, was always not that it was highly curated by people, but that it was highly curated by people and there was _no_ other way to install software.
Again, this is something with an obvious software solution. Google is the best in the world at providing good search results...so, why not provide the best search results in the market? (I don't think they currently do a good job, though. I'll be the first to admit that the Apple App Store is still a somewhat better experience than the App Market, despite App Market getting quite a bit better during its life...but it's not because App Store is curated. It's because Google hasn't put the resources into making App Market work really well.)
Generally, I think if you've got people involved in processes that could be handled by software, it's a failure. It's costing consumers more money, costing developers more time, and insuring that it is a fallible process and subject to the whims of sometimes capricious reviewers. Since this article is about security (and not "~~~FREE RINGTONES~~~"), that's clearly something that ought to be handled in software. The fact that Apple doesn't handle it in the OS, and instead relies on human reviewers, is Apple's failure. The fact that Google doesn't handle it in the OS, and relies on vendor trust and user intelligence and a better than average (but still weaker than ideal) security model, is Google's failure.
On the subject of security, you've suggested that Apple have the problem solved by having a curated market. I don't believe that's at all accurate.
It looks like compiled apps on Palm can also read the whole media directory. The neat thing with Palm though is any app can bring in scenes (a screen) from other apps, preserving the state of the application underneath, while passing back data. This way any app can selectively share with another app. On iPhone OS the only system wide widgets available are provided by Apple. I'm betting/hoping Palm will come back and give Apple a run for it's money, if the carriers don't cripple it somehow first.
iPhone apps have been able to access camera roll images by direct file access. I think they are still able to, though I didn't verify that.
It wasn't even difficult at all, a path to the photo directory can be easily figured out either from the simulator's file system or by jailbreaking the phone. (Or nowadays by Googling)
Secure sandboxing is pretty difficult thing to do properly.
If the image picker UI widget has an access to your photos and it is running inside your applications process, then your process has access to those files. It doesn't matter if the actual path is hidden, a clever hacker could still figure out to get access to those files.
To make sandboxing secure, UI widget has to run in a different process and only communicate data of selected image back to your app. This is non-trivial to implement well, given that UI transitions are expected to be smooth and even support animations.
Due to the API design of UIImagePickerController, I think Apple has known this from the beginning and maybe planned to do it securely. But I assume they just haven't got time to implement it yet.
Android already does this using separate processes for distinct Activities and by using Intents for message-passing between those activities. Granted, Android doesn't prevent access to the SD card data, but assuming it did secure that access somehow, the existing Activity/Intents framework would make it trivial to keep that functionality separate. Except for the fact that all the system applications and activities are built on top of the same basic Android SDK/API as 3rd party applications, so anything they can do, your apps can do too if it requests the right permissions.
I am surprised the images aren't accessed through another process that has directory access but enforces limits. Couldn't that process just allocate a buffer or take a pre-allocaed buffer for a UIImage and pass back a pointer to the requesting app? Is there some sort of technical limitation that forces it to send the image back via a slower method like IPC? Sending a message to the managing process to get the image and receiving a pointer back shouldn't have too much overhead should it?
I read on Ars that hardware virtualization support is coming to mobile at some point. The ability to trap the right instructions so an app can't break out should hopefully help secure these kinds data stores without having a curated app library, and without too much of a performance hit.
I thought we were there already there, so this is dissapointing. For some reason I am less comfortable with my phone apps having the sort of file system access than my desktop apps. Restricting internet access for apps in order to control data from leaking out is too far reaching, lots of apps need internet for things besides stealing data.