6 ms·

That isn't how Android works. An app with permission to install things can do so. Play store by default has this permission. It is VERY careful to avoid substit

That isn't how Android works. An app with permission to install things can do so. Play store by default has this permission. It is VERY careful to avoid substitution of downloaded data. For a good reason. Users granted same permission to the Epic installer. Clearly prematurely. Why the downvotes? It is true.

wtallis 8y ago
Why should something like the Fortnite installer have to make any effort to ensure that other apps aren't tampering with what it downloads? This definitely sounds like poor platform design more than a flaw in the installer.
- throwaway5752 8y ago
  "Using a private internal storage directory rather than external storage would help avoid this vulnerability: https://developer.android.com/guide/topics/data/data-storage#filesInternal" https://developer.android.com/guide/topics/data/data-storage... The system offers it and they didn't use it. "Why should something like the Fortnite installer have to make any effort to ensure that other apps aren't tampering with what it downloads?" Because it's running with exceptionally dangerous permissions that Google does its level best to prevent users from granting to 3rd party apps in the first place.
  - wtallis 8y ago
    > The system offers it and they didn't use it. The bug report doesn't seem to be clear on whether the Fortnite installer is downloading the game to a public external storage directory or a private external storage directory. But the existence of the latter API means you can't just say "they should have used internal storage". If the Fortnite installer used the getExternalStoragePublicDirectory() API, then this is a really embarrasing bug for Epic. Otherwise, it's an Android problem, not an Epic problem.
    - UncleMeat 8y ago
      Yes they literally used the external storage.
      - wtallis 8y ago
        > Yes they literally used the external storage. That doesn't answer the key question. There are APIs to get public or private directories on external storage. Unless Epic used the public version, then they had no reason to expect other apps to be able to tamper with their working files. You have to dig into the fine print of the API docs to find a clear statement that private directories on external storage don't have any security, which is a surprising difference from how the internal storage works. Google calls the directories private, but they're really not. There's no obvious reason why they couldn't be secured against modification by non-root apps.
        dmitrygr 8y ago
        Digging through API docs is literally what developers get paid for.
        wtallis 8y ago
        Searching for potential hidden footguns is not a good use of application developer time; they're paid primarily to create new functionality. This is simply a bad API/platform design aspect that the docs don't do enough to warn about.
        UncleMeat 8y ago
        Potentially hidden footguns? The public/private storage mechanism has been the primary way of protecting files in Android literally since release. This is like saying it is Android's fault that you can put exported=true on a ContentProvider and be surprised when other apps access the underlying tables.
        makomk 8y ago
cma 8y ago
https://android-developers.googleblog.com/2017/08/making-it-safer-to-get-apps-on-android-o.html https://android-developers.googleblog.com/2017/08/making-it-... I don't know how up to date that is, but it says once unknown sources are turned back off, the app using REQUEST_INSTALL_PACKAGES can no longer install unsigned packages. My point was it should be possible to add a key for a store, so that unknown sources doesn't have to be turned back on after installing it. But then this seems to say you can: https://developer.android.com/reference/android/content/Intent.html#EXTRA_NOT_UNKNOWN_SOURCE https://developer.android.com/reference/android/content/Inte...

wtallis 8y ago

Why should something like the Fortnite installer have to make any effort to ensure that other apps aren't tampering with what it downloads? This definitely sounds like poor platform design more than a flaw in the installer.

throwaway5752 8y ago
"Using a private internal storage directory rather than external storage would help avoid this vulnerability: https://developer.android.com/guide/topics/data/data-storage#filesInternal" https://developer.android.com/guide/topics/data/data-storage... The system offers it and they didn't use it. "Why should something like the Fortnite installer have to make any effort to ensure that other apps aren't tampering with what it downloads?" Because it's running with exceptionally dangerous permissions that Google does its level best to prevent users from granting to 3rd party apps in the first place.
- wtallis 8y ago
  > The system offers it and they didn't use it. The bug report doesn't seem to be clear on whether the Fortnite installer is downloading the game to a public external storage directory or a private external storage directory. But the existence of the latter API means you can't just say "they should have used internal storage". If the Fortnite installer used the getExternalStoragePublicDirectory() API, then this is a really embarrasing bug for Epic. Otherwise, it's an Android problem, not an Epic problem.
  - UncleMeat 8y ago
    Yes they literally used the external storage.
    - wtallis 8y ago
      > Yes they literally used the external storage. That doesn't answer the key question. There are APIs to get public or private directories on external storage. Unless Epic used the public version, then they had no reason to expect other apps to be able to tamper with their working files. You have to dig into the fine print of the API docs to find a clear statement that private directories on external storage don't have any security, which is a surprising difference from how the internal storage works. Google calls the directories private, but they're really not. There's no obvious reason why they couldn't be secured against modification by non-root apps.
      - dmitrygr 8y ago
        Digging through API docs is literally what developers get paid for.
        wtallis 8y ago
        Searching for potential hidden footguns is not a good use of application developer time; they're paid primarily to create new functionality. This is simply a bad API/platform design aspect that the docs don't do enough to warn about.
        UncleMeat 8y ago
        Potentially hidden footguns? The public/private storage mechanism has been the primary way of protecting files in Android literally since release. This is like saying it is Android's fault that you can put exported=true on a ContentProvider and be surprised when other apps access the underlying tables.
      - makomk 8y ago

cma 8y ago

https://android-developers.googleblog.com/2017/08/making-it-safer-to-get-apps-on-android-o.html https://android-developers.googleblog.com/2017/08/making-it-... I don't know how up to date that is, but it says once unknown sources are turned back off, the app using REQUEST_INSTALL_PACKAGES can no longer install unsigned packages. My point was it should be possible to add a key for a store, so that unknown sources doesn't have to be turned back on after installing it. But then this seems to say you can: https://developer.android.com/reference/android/content/Intent.html#EXTRA_NOT_UNKNOWN_SOURCE https://developer.android.com/reference/android/content/Inte...