A virus, by definition, spreads. How do you expect an android virus to spread?
Also, what can it damage? (Leaving aside gaping holes like 'su' in 1.0/1.1 dev phones and full access to sd card data) "Oh no, the virus hidden in TwitterFooler deleted all the data from .. um.. twitterfooler. Ha, take that.. me..." On Mon, May 4, 2009 at 8:54 AM, guillaume leterrier (Teleca Germany) < [email protected]> wrote: > > > Unfortunatly, that is also my understanding of the current Android > security model. > > There is no certificate authority scheme that check application > content and ID/rights of the developer. > > All developers and all applications are treated as equal by the > android security model. > > The end-user is mainly in charge of assessing the trustworthiness of > an application and its installation consequences, based on its > requested permission. ( an exception to be noticed is the shared ID. > see related discussion thread....) > > It is also assumed that the end-user is responsible enough to get > application from a known market place and not from any unknown web- > site source. > > The end-user could still un-install the application if not satisfied, > it could also rate the application on the market place. Ok, this is a > reactive approach, after damages could be done. > > Next end-users could use the application rating to assess the quality > of the application provided by previous user, before taking any > installation decision. > > However, the malicious developer could still regenerate the same > malware with a different key, and potentially continue the damages > under an other identity. > > The market place could implement an automatic scheme that scan > applications to limit such cloning behavior by comparing binary signed > with different keys and reject black listed malware application. > > Moreover, if there is a virus embedded in the application source code, > and such virus could still become active after a sleeping period. An > anti-virus could also scan ( at installation time ) the application > binary and compare it against an updated list of unknown malware. The > anti-virus check could also be performed by the market place itself. > > > > Android wrote: > > The silence in the thread scares me. Does anyone knowledgeable have an > > answer to Tote's question? > > > > Is the totality of Android API protection based solely on the idea that > > self-signing out of self-generated certificates is trustworthy? No chain > of > > trust? No identity escrow? No skin in the game of any sort whatsoever to > be > > able to track down the originator of a rogue app? No validation that > someone > > with bad intentions isn't self-signing an innocuous-looking application > that > > gets on marketplace but that triggers bad behavior after it's been widely > > installed? > > > > Please tell me that the effectiveness of Android's API security model > isn't > > purely based on crowdsourcing and user-generated feedback... > > > > -jfr > > > > > > Dave, > > Thanks for the exhaustive answer and I naturally appreciate Google's > > decision on working out this security model. Nevertheless, you seemed > > not to answer one of the important questions I also asked: > > > > "Another question is that if any developers can sign their apps > > freely > > without any consequences (I mean there's no accountability on self- > > signed certificates) what will really prevent malware from spreading? > > " > > > > That is, if I were a malware author it wouldn't give me too much head- > > ache to change my self-signed certificates frequently - and I don't > > want to update my previous app, either. What is Google's approach to > > this problem? > > > > Thanks, > > > > Tote > > > > On Feb 5, 3:02 am, Dave Bort <[email protected]> wrote: > > > > ________________________________________________ > > Message sent using UebiMiau 2.7.10 >
