[millstone]

Java's access controls are trivial to bypass on Android. Neither the Android or iOS runtimes are there to enforce a security policy.

You should read Apple's iOS Security Whitepaper: http://www.apple.com/business/docs/iOS_Security_Guide.pdf See for example the data protection classes: a very thoughtful design, with no analog in Android, and that certainly could not have come about by "happenstance."

Heck, Android doesn't even encrypt your data by default! That alone makes iOS "fundamentally more secure."

[blinkingled]

> Java's access controls are trivial to bypass on Android.

You keep repeating that but I am certain you don't understand what you are talking about. Go download the Android SDK, emulator and write an app that does that and post it on Github We will talk about it then.

Also - I'll leave this here - http://www.macrumors.com/2015/10/19/apple-to-remove-hundreds...

[millstone]

> write an app that does that

Here's a sample of how to invoke `Activity.savedDialogKeyFor`, which is private:

    Method privateMethod =
        Activity.class.getDeclaredMethod("savedDialogKeyFor", int.class);
    privateMethod.setAccessible(true);
    String result = (String)privateMethod.invoke(this, 42);
    System.out.println("Got result: " + result);

Worked perfectly on Android Marshmallow emulator. As I said, it's trivial.

> Also - I'll leave this here

What's your point? There was no security exploit here, and no security policy can realistically prevent networked apps from sharing data like your email address. That falls to the review process.

What's remarkable here is how little data this malware was actually able to capture. Certainly less than on Android, where users routinely grant excessive permissions, like giving Netflix access to your phone.

[blinkingled]

You're confusing accessing private methods with violating the Android permissions model. Two totally separate things.

Edit: Also my larger point was the iOS security is not fundamentally better than anything else. The closed nature, restrictive policies etc. help but fundamentally it's nothing outstanding. It was a response to tptacek claiming opposite.

[millstone]

I am not confused. Please reread the thread.

You asserted that iOS is "unfixable" because the ObjC runtime cannot prevent apps from using "private/internal calls that your app is not supposed to use," whereas "Android gets code access control for free with Java."

But as I showed, Java access controls are easily bypassed, so they do not provide any security. This is by design: security is enforced at the process boundary, not by the runtime.

My hope is that you now appreciate that neither the ObjC nor Android Java runtimes are a security risk, because they are not responsible for enforcing any security policy.

> Also my larger point was the iOS security is not fundamentally better than anything else

iOS security is fundamentally better. You can read the whitepaper to understand the ways: data protection classes, the Secure Enclave, and lots more.

But here's a damning fact: iOS encrypts your data by default, Android does not. That by itself makes iOS fundamentally more secure.

[blinkingled]

You should really read this Usenix paper - 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]

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