3 ms·

If by "dig into the fine print of the API docs" you mean "read the summary of the different data storage options available, or alternatively read the documentat

by makomk 8y ago

If by "dig into the fine print of the API docs" you mean "read the summary of the different data storage options available, or alternatively read the documentation for the API function you're using", then sure. https://developer.android.com/guide/topics/data/data-storage#filesInternal%22 https://developer.android.com/guide/topics/data/data-storage... The different APIs for accessing external storage are mainly just there for filesystem tidyness and are documented as such. getExternalStoragePublicDirectory puts media files in locations where other apps and the user can find them easily, whereas the application-specific directory is deleted when the app is uninstalled. There's no real security difference and the documentation makes this quite clear. I think the API for application-specific directories in external storage was probably only added because applications were already using it for their internal files in ad-hoc ways that caused a lot of user visible clutter.

wtallis 8y ago
> There's no real security difference and the documentation makes this quite clear. Only once you've dug deep enough. The page you linked to doesn't mention security at all. It does say: "Except for some types of files on external storage, all these options are intended for app-private data—the data is not naturally accessible to other apps." Elsewhere, it mentions that files on external storage are world-readable, but that's not a problem here. The fact that they're also world-writable is left unsaid. Going another layer deeper into the docs at https://developer.android.com/training/data-storage/files https://developer.android.com/training/data-storage/files we get this: "Private files: Files that rightfully belong to your app and will be deleted when the user uninstalls your app. Although these files are technically accessible by the user and other apps because they are on the external storage, they don't provide value to the user outside of your app." That doesn't clearly warn that "private" files on external storage will be modifiable by other apps while you're still trying to use them. Only by going all the way down to the documentation for getExternalFilesDirs() itself do you get a reasonably sufficient and clear warning: "There is no security enforced with these files. For example, any application holding Manifest.permission.WRITE_EXTERNAL_STORAGE can write to these files." For someone coming to Android programming with the knowledge that it's Linux-based with a fairly strict permissions model, and with so many mentions of "private" storage in the high-level docs, it's a surprise to discover that there are no file permissions enforced on "external" storage.
- throwaway5752 8y ago
  I totally reject your interpretation. If you're writing a crappy app with limited permissions then you get a pass. You don't get to complain about footguns if you are asking people to give you exceptionally dangerous permissions. I don't think this was even hidden or obfuscated, doc-wise (exhibit A: doc exists), but even if it was the onus is on Fortnite. "For someone coming to Android programming with the knowledge that it's Linux-based with a fairly strict permissions model, and with so many mentions of "private" storage in the high-level docs, it's a surprise to discover that there are no file permissions enforced on "external" storage." If you are not an absolute expert on Android across multiple devices and api versions, then you have no damn business releasing something of this nature. You bring up Linux. It is not a flaw that drivers run in a privileged mode. If you make a device driver and don't understand how memory is allocated and cleared or not cleared, then you have no business writing one because you're going to let people root your customer's boxes eventually.
  - throwaway5752 8y ago
    Sorry, "totally reject" is a bit stronger than I meant (and I'm past the edit window). I just feel strongly about developer obligation & responsibility for security code and infrastructure being commensurate with the risk they ask the users of the software to take.

by makomk 8y ago

wtallis 8y ago

> There's no real security difference and the documentation makes this quite clear. Only once you've dug deep enough. The page you linked to doesn't mention security at all. It does say: "Except for some types of files on external storage, all these options are intended for app-private data—the data is not naturally accessible to other apps." Elsewhere, it mentions that files on external storage are world-readable, but that's not a problem here. The fact that they're also world-writable is left unsaid. Going another layer deeper into the docs at https://developer.android.com/training/data-storage/files https://developer.android.com/training/data-storage/files we get this: "Private files: Files that rightfully belong to your app and will be deleted when the user uninstalls your app. Although these files are technically accessible by the user and other apps because they are on the external storage, they don't provide value to the user outside of your app." That doesn't clearly warn that "private" files on external storage will be modifiable by other apps while you're still trying to use them. Only by going all the way down to the documentation for getExternalFilesDirs() itself do you get a reasonably sufficient and clear warning: "There is no security enforced with these files. For example, any application holding Manifest.permission.WRITE_EXTERNAL_STORAGE can write to these files." For someone coming to Android programming with the knowledge that it's Linux-based with a fairly strict permissions model, and with so many mentions of "private" storage in the high-level docs, it's a surprise to discover that there are no file permissions enforced on "external" storage.

throwaway5752 8y ago
I totally reject your interpretation. If you're writing a crappy app with limited permissions then you get a pass. You don't get to complain about footguns if you are asking people to give you exceptionally dangerous permissions. I don't think this was even hidden or obfuscated, doc-wise (exhibit A: doc exists), but even if it was the onus is on Fortnite. "For someone coming to Android programming with the knowledge that it's Linux-based with a fairly strict permissions model, and with so many mentions of "private" storage in the high-level docs, it's a surprise to discover that there are no file permissions enforced on "external" storage." If you are not an absolute expert on Android across multiple devices and api versions, then you have no damn business releasing something of this nature. You bring up Linux. It is not a flaw that drivers run in a privileged mode. If you make a device driver and don't understand how memory is allocated and cleared or not cleared, then you have no business writing one because you're going to let people root your customer's boxes eventually.
- throwaway5752 8y ago
  Sorry, "totally reject" is a bit stronger than I meant (and I'm past the edit window). I just feel strongly about developer obligation & responsibility for security code and infrastructure being commensurate with the risk they ask the users of the software to take.