24 ms·

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 securit

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?).

_emice 16y ago
On the Apple devices each app lives sand boxed in it's own directory, but apps can still access photos taken with the camera or saved from other apps. They don't ask for permission, but go through a standard image picker user interface provided by the system. I don't think apps can grab photos unless the user picks them through this widget. This way you know exactly what you are handing over. Direct access to the SD card is dicey at best. 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.
- evilmushroom 16y ago
  http://developer.android.com/guide/topics/data/data-storage.html#filesInternal http://developer.android.com/guide/topics/data/data-storage.... Context.MODE_PRIVATE bam
  - dguido 16y ago
    As the docs say, that's a property of internal phone storage (which is very limited). External storage doesn't have permissions. How could it? It's all FAT32!
    - sswam 16y ago
      apps without permission to access it could be run in a chroot, for example.
- dirtyaura 16y ago
  I don't think apps can grab photos (on iPhone) unless the user picks them through this widget. 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.
  - nuclear_eclipse 16y ago
    > To make sandboxing secure, UI widget has to run in a different process and only communicate data of selected image back to your app. 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.
  - _emice 16y ago
    After doing some reading it looks like you can get a path to the image by poking around undocumented methods in the UIImagePicker class, but Apple does not allow those private API method calls past it's approval process. Just like you said, it is possible, but Apple curates it out. 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.
SwellJoe 16y ago
No. 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.
- krakensden 16y ago
  Developers like it because if their software sits next to a bunch of other professional, polished looking apps their software looks better by comparison. If it's surrounded by "~~~FREE RINGTONES~~~", it doesn't look so great. 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.
  - SwellJoe 16y ago
    I've never seen ~~~FREE RINGTONES~~~ in the Android market. 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.
nitrogen 16y ago
I just want a better market search. This is Google, for crying out loud! I want to be able to sort and filter by rating, date updated, price, alphabetically, permissions required, etc. Also, I'd prefer to display all prices in my local currency, so I don't have to look up how much a .99euro app costs based on today's exchange rate.

_emice 16y ago

On the Apple devices each app lives sand boxed in it's own directory, but apps can still access photos taken with the camera or saved from other apps. They don't ask for permission, but go through a standard image picker user interface provided by the system. I don't think apps can grab photos unless the user picks them through this widget. This way you know exactly what you are handing over. Direct access to the SD card is dicey at best. 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.

evilmushroom 16y ago
http://developer.android.com/guide/topics/data/data-storage.html#filesInternal http://developer.android.com/guide/topics/data/data-storage.... Context.MODE_PRIVATE bam
- dguido 16y ago
  As the docs say, that's a property of internal phone storage (which is very limited). External storage doesn't have permissions. How could it? It's all FAT32!
  - sswam 16y ago
    apps without permission to access it could be run in a chroot, for example.
dirtyaura 16y ago
I don't think apps can grab photos (on iPhone) unless the user picks them through this widget. 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.
- nuclear_eclipse 16y ago
  > To make sandboxing secure, UI widget has to run in a different process and only communicate data of selected image back to your app. 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.
- _emice 16y ago
  After doing some reading it looks like you can get a path to the image by poking around undocumented methods in the UIImagePicker class, but Apple does not allow those private API method calls past it's approval process. Just like you said, it is possible, but Apple curates it out. 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.

SwellJoe 16y ago

No. 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.

krakensden 16y ago
Developers like it because if their software sits next to a bunch of other professional, polished looking apps their software looks better by comparison. If it's surrounded by "~~~FREE RINGTONES~~~", it doesn't look so great. 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.
- SwellJoe 16y ago
  I've never seen ~~~FREE RINGTONES~~~ in the Android market. 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.

nitrogen 16y ago

I just want a better market search. This is Google, for crying out loud! I want to be able to sort and filter by rating, date updated, price, alphabetically, permissions required, etc. Also, I'd prefer to display all prices in my local currency, so I don't have to look up how much a .99euro app costs based on today's exchange rate.