> > The difficult part is pleasing the customer with lots of easy to make > apps. Java is not good for security but it helps prevent buffer > overflows etc.. > > Android's "Java" is not a security measure by any means. Ok, it is a well-defined type-safe language; no pointers, nu buffer overflows, no memory leaks, etc. However, "Java apps" are handled the exact same way as native apps (those developed with the NDK and written in C). Android's security boils down to the system-level isolation (sandboxing) and the permission scheme; nothing to do with "Java security" at all.
> Only if all apps are open source can you possibly have a good idea of > what an app is doing. The only real difference with Apple checking these > apps is likely to make is for the apps to be more devious about hiding > their true functionality. > > Proactive is better than reactive. > I think that there exit some interesting approaches to those problems. I mean, just look at the research propers from Enck et al (TaintDroid, Kirin tool, ...), Shabtai et al (hardening Android by Linux measures), Davi (the transitive permission thing), etc. However, it's not up to me nor up to you to get that going. It's in the hands of the platform engineers. Cheers, David -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To view this discussion on the web visit https://groups.google.com/d/msg/android-security-discuss/-/RmsO_l2HIJEJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
