4 ms·

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'

by _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.

by _emice 16y ago

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.