Chris, App source code review is not always an option when it's burdened with proprietary technologies & techniques that you'd like to protect and/ or licensed stuff. Or do we expect that an independent auditor will sign all kinds of NDAs that we had to when deciding on using a license- based library, for example?
Since code review is not an option those independent auditors, let's call them Test Houses, will be able to check if your application runs "as expected" and does nothing malicious. Now. Not in the future, thus it doesn't protect against timed attacks. You can see that it's pretty limited what Test Houses can do actually. You also mentioned "trusted sources". Yeah, this is exactly the problem: how do we know which source can be trusted? Android Market? It is based on crowd-sourcing. Is it good for us? Generally it is, but one must be aware of that there is a latency introduced by this approach: the time it takes while people realize that an app is fake and causes damages. I think Google has chosen a solution that is still bearable, not too cumbersome for developers/users and not too dangerous for operators. Only time will tell if it's going to be better than those used on other platforms. Tote On May 4, 9:28 pm, Chris Rutherford <[email protected]> wrote: > The problem appears to be the delicate balance between security and > convenience (which are diametrically opposed). I can see it is much > more convenient for application developers and Google to allow self > signed certificates. > > Giving users the option to only install apps from trusted sources may > be a simple solution. Here more advanced users could install apps at > their own risk. > > Also rather than have to code review all source code before issuing a > certificate, perhaps a way forwards would be to allow self signed > certificates, but attribute trust to a given developer and associate > that developer to apps through signatures. Here, whist any app can be > installed, installed apps would be registered to a given developer > through irrefutable signatures. > > If malware was found then that developer could be banned and a > security warning associated with all apps produced by that developer. > i.e. Use black lists rather than white lists. This would requre > developers who wish to be considered 'trusted' to register with > google. > > There would be nothing to stop malware writers from registering with > fake details, but steps could be put in place to make this more > difficult. Once a number of apps are attributable to a given > developer without problems, the trust given to that developer > increases (like in ebay). > > Could this be achieved technically and would it solve the problem of > (evil) developers not being accountable for their actions? > > Chris > > On Mon, May 4, 2009 at 6:19 PM, jfr <[email protected]> wrote: > > > Hil Will, > > > Your points are valid that PKI is not a panacea. Code signing has > > limitations -- I agree. > > > Without extensive code review, code signing of any sort is not a > > guarantee that the application isn't doing something malicious - > > agreed. Signing under a CA's certificate, likewise, is not a guarantee > > of any kind of verification that the application isn't misbehaving - > > again, agreed. > > > But that's not ultimately the point. What code signing under someone > > else's umbrella of trust does is give you the _possibility_ of setting > > up a system where trust can be systematically revoked in automated > > fashion when malicious activity is performed under false pretenses > > within an application that has a signature. > > > I think that malicious activity can be clearly and cleanly defined > > (e.g. your information is released without your knowledge, or you are > > subject to monetary costs or other damages that you did not agree to). > > I'm not talking about curtailing "distasteful" content. I'm talking > > about mechanisms for controlling clearly dangerous applications. > > > I also agree with you that this is not just an Android issue, but of > > every general purpose computing system. When it comes to smartphones, > > however, other platforms have come up with some way of mitigating the > > potential impact of rogue applications. We can argue the merits and > > drawbacks of each all day, but the point is that they have something > > that has made a reasonably large number of intelligent people > > comfortable. The fact that Android is operating as a smartphone > > platform but doesn't have an answer to this other than crowdsourcing > > is basically saying to handset manufacturers, network operators and > > end consumers that they're on their own and it's their own damn fault > > if something awful happens to their information, phone bill, or the > > networks on which they run. > > > Signing + CA is not the complete solution, by any stretch of the > > imagination, I agree, but something like it could be a start. On the > > desktop side, relying on end users' knowledge has given us lovely > > things like ILOVEYOU and botnet DDoS attacks on Estonia. Why repeat > > that joy on a promising platform by not coming up with an alternative? > > > -jfr
