3 ms·

You should really read this Usenix paper - https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_wang-updated-8-23-13.pdf https://www.usen

You should really read this Usenix paper - https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_wang-updated-8-23-13.pdf https://www.usenix.org/system/files/conference/usenixsecurit... . What you are not understanding or ignoring is that iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses by reverse engineering the names of the private APIs and using message passing. Android sure has private APIs and you can access those but you're still restricted to the permissions you asked for. For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently where they rely on manual review to ensure you are not calling the Private API - which fails as can be seen in the Chinese AD SDK fiasco I posted. So no Android runtime isn't a security risk as much as iOS private APIs are - your app gets a broad set of permissions on iOS by default and you can do clever trickery to call private APIs to collect personal info and who knows what else without the user knowing. Android needs your app to ask for that permission first (and at runtime on M)- you aren't calling a private method on Android without declaring the necessary permission to get what you want without user interaction.

millstone 11y ago
> You should really read this Usenix paper I have read it. It describes an attack on the app review process, i.e. a trojan. Their apps require the user to grant privileges. For example, their GreetingCard app requests access to the user's address book, and the user has to grant it. > iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses This is not true. Here's the blog: https://sourcedna.com/blog/20151018/ios-apps-using-private-apis.html https://sourcedna.com/blog/20151018/ios-apps-using-private-a... The data they collected was list of installed apps, serial numbers, and some sort of AppleID numeric identifier. In particular, they did not (could not) collect email addresses. It's bad that the SDK was collecting this stuff, but this data is fairly innocuous. Last I checked, Android provides information like the list of installed apps and various serial numbers without requiring elevated permission. If you think it's possible to get the user's email address through an iOS private API, I challenge you to tell me what that private API is. > For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently This is wrong. On iOS, the only way to access the user's email is through the Address Book framework, which prompts the user at the time of access. > your app gets a broad set of permissions on iOS by default This is completely false. iOS has a comprehensive on-demand permissions model, which is widely recognized as better than the install-time permission model on Android. This is why Android is switching to iOS style on-demand permissions in Marshmallow. > you aren't calling a private method on Android without declaring the necessary permission Please stop confusing private methods with elevated permissions. You CAN call private methods without elevated permissions, as my code above demonstrates.
- blinkingled 11y ago
  >The data they collected was list of installed apps, serial numbers, and some sort of AppleID numeric identifier. In particular, they did not (could not) collect email addresses. [Edited for unnecessary stuff] Oh the article you linked has Apple response that is quoted verbatim below - it references user email addresses. Specifically. “We’ve identified a group of apps that are using a third-party advertising SDK, developed by Youmi, a mobile advertising provider, that uses private APIs to gather private information, such as user email addresses.." > Please stop confusing private methods with elevated permissions. You CAN call private methods without elevated permissions, as my code above demonstrates. What I wrote was you are not going to be able to call an Android API via private invocation and succeed if the API requires a specific permission and your app hasn't declared it. All of this only goes to prove that Apple's security in iOS is not extraordinary as you claim - it is fallible like every other platform except with the exception of fingerprints which are currently believed to be secure - but that's now the case with Android as well - in M they are using ARM Trust Zone with no app access.
  - millstone 11y ago
    Maybe there's a private API on iOS that leaks the user's email addresses without the proper permissions. Maybe there's one on Android too. Neither OS has a runtime that will prevent malicious apps from exploiting such an API. > What I wrote was you are not going to be able to call an Android API via private invocation and succeed if the API requires a specific permission and your app hasn't declared it Just like on iOS, with the difference that it happens at call time and not installation time. > All of this only goes to prove that Apple's security in iOS is not extraordinary as you claim It shows the exact opposite! Notice how ridiculously weak these results are. On one of the most high-profile targets today, an app may (unconfirmed) be able to determine the user's email address and send it to a server. On a trojan app that the user deliberately installed, and then deliberately granted access to Twitter, it can post a tweet without the user's confirmation, if the user has not updated the OS. Fetch the smelling salts! Meanwhile, millions of Android phones are part of botnets, like NotCompatible.C, at one point reaching 1.5% of mobile devices in the USA. A Chrome 0-day came out last week, allowing full control remotely of fully-patched Android phones. These aren't research papers showing theoretical attacks, this is real life. Yes, iOS has extraordinary security, and its competition only makes it look better.

millstone 11y ago

> You should really read this Usenix paper I have read it. It describes an attack on the app review process, i.e. a trojan. Their apps require the user to grant privileges. For example, their GreetingCard app requests access to the user's address book, and the user has to grant it. > iOS apps (over 250) that were App Store approved were able to retrieve personal user data including email addresses This is not true. Here's the blog: https://sourcedna.com/blog/20151018/ios-apps-using-private-apis.html https://sourcedna.com/blog/20151018/ios-apps-using-private-a... The data they collected was list of installed apps, serial numbers, and some sort of AppleID numeric identifier. In particular, they did not (could not) collect email addresses. It's bad that the SDK was collecting this stuff, but this data is fairly innocuous. Last I checked, Android provides information like the list of installed apps and various serial numbers without requiring elevated permission. If you think it's possible to get the user's email address through an iOS private API, I challenge you to tell me what that private API is. > For example you need to declare android.permission.GET_ACCOUNTS permission to get the user's primary email. Not on iOS apparently This is wrong. On iOS, the only way to access the user's email is through the Address Book framework, which prompts the user at the time of access. > your app gets a broad set of permissions on iOS by default This is completely false. iOS has a comprehensive on-demand permissions model, which is widely recognized as better than the install-time permission model on Android. This is why Android is switching to iOS style on-demand permissions in Marshmallow. > you aren't calling a private method on Android without declaring the necessary permission Please stop confusing private methods with elevated permissions. You CAN call private methods without elevated permissions, as my code above demonstrates.

blinkingled 11y ago
>The data they collected was list of installed apps, serial numbers, and some sort of AppleID numeric identifier. In particular, they did not (could not) collect email addresses. [Edited for unnecessary stuff] Oh the article you linked has Apple response that is quoted verbatim below - it references user email addresses. Specifically. “We’ve identified a group of apps that are using a third-party advertising SDK, developed by Youmi, a mobile advertising provider, that uses private APIs to gather private information, such as user email addresses.." > Please stop confusing private methods with elevated permissions. You CAN call private methods without elevated permissions, as my code above demonstrates. What I wrote was you are not going to be able to call an Android API via private invocation and succeed if the API requires a specific permission and your app hasn't declared it. All of this only goes to prove that Apple's security in iOS is not extraordinary as you claim - it is fallible like every other platform except with the exception of fingerprints which are currently believed to be secure - but that's now the case with Android as well - in M they are using ARM Trust Zone with no app access.
- millstone 11y ago
  Maybe there's a private API on iOS that leaks the user's email addresses without the proper permissions. Maybe there's one on Android too. Neither OS has a runtime that will prevent malicious apps from exploiting such an API. > What I wrote was you are not going to be able to call an Android API via private invocation and succeed if the API requires a specific permission and your app hasn't declared it Just like on iOS, with the difference that it happens at call time and not installation time. > All of this only goes to prove that Apple's security in iOS is not extraordinary as you claim It shows the exact opposite! Notice how ridiculously weak these results are. On one of the most high-profile targets today, an app may (unconfirmed) be able to determine the user's email address and send it to a server. On a trojan app that the user deliberately installed, and then deliberately granted access to Twitter, it can post a tweet without the user's confirmation, if the user has not updated the OS. Fetch the smelling salts! Meanwhile, millions of Android phones are part of botnets, like NotCompatible.C, at one point reaching 1.5% of mobile devices in the USA. A Chrome 0-day came out last week, allowing full control remotely of fully-patched Android phones. These aren't research papers showing theoretical attacks, this is real life. Yes, iOS has extraordinary security, and its competition only makes it look better.