Are third-party security apps still necessary with Android 4.2?

Latest version of Android offers several built-in security features.

While Android 4.2 Jelly Bean was only an incremental update for the mobile operating system, it introduced a ton of much-needed security improvements. As we touched upon in our exhaustive review, Google stepped up its game by implementing native security features that perform functions like scanning side-loaded apps before they're installed to run them against other known cases of malware, and offering SMS confirmation to notify the user if an application wants to send out a text message.

The addition of these features is a step in the right direction, but there were already a wealth of third-party security applications available in Google Play. Companies like Lookout, AVG, and Avast all base their livelihood on protecting Android users (and some iOS users, too) from break-ins. The plethora of third-party apps got us wondering: will Google's inclusion of its own security features render those third-party applications obsolete?

Third-party apps

Let's start with Lookout, a mobile security app with a majority of its customers using the Android platform. This app contains most of the features that Google offers natively in Android 4.2, as well as a basket full of other features that aren't available in the Android OS. There's a free and premium version of the security suite: the free version protects against malicious software, provides data backup and restoration, and helps locate the phone if it's misplaced. The premium version requires a $2.99 monthly subscription and gives you access to several other features, like the ability to remotely lock a phone from a website. But where Lookout really hopes to keep its edge against Google's native security implementations is with its Mobile Threat Network, which the company says constantly analyzes apps from Google Play and third-party markets and scans for new mobile threats that arise globally.

Enlarge/ Lookout offers a wealth of security features, including the ability to scan files and apps before anything is installed on the device.

Lookout is confident that its Mobile Threat Network will help the company maintain its relevance even as Google increases Android's security offerings. "The effectiveness of [this] type of product is fundamentally dependent on how complete that data set is," Senior Security Project Manager Derek Halliday told Ars. "We've been looking at the apps across Google Play and alternate markets for more than a few years now and we're pretty confident that our data set is the most comprehensive out there."

The company's app checker works a lot like Android's in that it scans a database of known, harmful apps, but it also runs threats against its own curated library of blacklisted apps and sources that it has been compiling since its inception. Lookout acquires this data by "decomposing" apps and utilizing pattern matching to find other apps that might match that malicious code. "That's something we're going to be continually growing," adds Halliday. "There's a lot more that the data set can power."

Abheek Gupta, senior project manager at Lookout, elaborated on this, adding that with this source of information, the company can work faster against rising threats. "As a company with the expertise, we can actually respond to many things faster than bigger companies and platforms can," he said. "We're able to provide that quick turnaround time for features, for capabilities, for protection."

AVG, which started out by protecting desktop PCs, also offers a suite of security products for Android handsets, including a free version, a pro version priced at $9.99, and a tablet-specific edition. The company's goal has been to take its core technology from the PC side and bring it to mobile handsets. Its Android apps perform real-time scans against previously known malicious data, just like on the PC. AVG also offers a file scanner that can actually look at files stored on SD cards or that have been downloaded to the phone via e-mail or other means, and a settings scanner that looks at the user's security settings to help them choose the best options for their individual usage. Additionally, the pro version offers the ability to locate a lost or stolen device, back up and restore data, and eliminate tasks that slow down the phone.

Enlarge/ Just a sampling of the features that the AVG security app offers.

Tony Anscombe, senior security evangelist at AVG, explained that antivirus companies have an advantage with their link scanner technologies because, although Google has its own list of malicious apps it works to actively combat, the antivirus companies actually scan things in real time. "We're not looking at blacklisting, but behavioral characteristics," Anscombe told Ars. "Google will have that blacklist of known issues and bad apps, whereas the security companies will be doing that in real time and looking at the behavior of the apps in real time."

Regardless, both companies do agree that Google's inclusion of native security features is ultimately the best thing for the consumer. "All signs point to the fact that they're actively engaged in understanding what the actual issues are in the Android ecosystem," said Halliday. "Android is a huge moving target and [Google is] doing a lot to move that platform forward. From a security standpoint, it looks like [Google is] being very attentive and reactive to the issues that are affecting most users."

It has. Back in February, Google announced its bouncer-like, server-side app scanner for the Google Play store that would attempt to stop harmful applications from making it past the approval process. The company took this same philosophy it was applying to the applications asking for entrance into the marketplace and implemented it natively into the Android code for side-loaded applications. "We want to make sure that this awesome security feature extended to all sources of applications on the device," said Hiroshi Lockheimer, vice president of engineering for Android, during a phone call with Ars. "We felt that security is a universal thing—it shouldn't be a Play-store-only feature. We wanted to protect our users across the board."

Like Lookout and AVG, Google has been accumulating background knowledge on a variety of malicious applications. "We know what sort of APKs exist and we can apply those same techniques to applications from the Web," Lockheimer explained. When an app is then side-loaded—apps like Amazon Marketplace or Swype, for instance—Google sends up the signature information to the server to determine if it's safe to install or not. And like all of the other apps featured in the Google Play store, Lockheimer mentions that the user "can decide whether they want to participate in this service or not, and it's freely available to them as long as they run 4.2."

Enlarge/ This warning pops up when the user downloads a side-loaded application.

So while third-party virus scanners offer a multitude of features that Android doesn't yet natively offer—like the ability to locate a device—is there any reason to use those apps for their virus and malware scanning abilities? Windows users, for example, don't necessarily need to install any third-party applications because Microsoft's native Security Essentials is lightweight and super easy to use. It was also, at one point, detecting 30 percent more malware than third-party companies, according to Jon Oberheide, CTO of Duo Security, which offers two-factor authentication for iOS and Android.

Oberheide believes that, as in the example of Windows, there really is no reason for Android owners to invest in a third-party mobile virus scanner, because the manufacturer—Google, in this case—is the only one that can actually hit malware where it hurts. "Lookout can only do very limited things because it doesn't have root access to super-user privileges," Oberheide told Ars. "It can only sort of hook in where it's allowed it to, whereas Google can do whatever they want. They control the platform and they can do much more comprehensive protection."

Oberheide added that although Google has had a lot of bad press for malware apps infiltrating Android handsets, the company has obviously been working on building infrastructure to prevent this from happening. Google's bouncer-like system, for instance, works well as a gatekeeper, and though it's only in its beginning stages, Google is going to actively continue to improve it to ensure that its Android users are protected from harm. Lockheimer echoed this point earlier, when he said, "We work on features that we believe are generally useful to the general public, and things that we think should belong in the platform. It was important for people to feel secure when they use their devices and feel safe when they're downloading and installing applications."

Keep in mind that any mobile operating system has its vulnerabilities; Android's have just been among the most widely publicized. Any user who is utilizing an Android handset should be aware of the perils that they can come across, but they shouldn't run scared. Google's security features are enough to protect them from common threats. On the plus side, if they're looking for a few added features that aren't yet available natively in Android—like the ability to locate the handset should it get lost or the ability to scan files downloaded via e-mail—there are certainly apps for that. Also, users who haven't yet been able to upgrade to Android 4.2 Jelly Bean can use a third-party security app in the interim and carry it over to their updated handsets in the future with all of those extra features.

In the end, just being aware of potential threats can do wonders. "Some very simple education of users can go a long way," concluded Oberheide.

36 Reader Comments

Q: Were they ever necessary?A: No, unless you were really into pirating APKs. Even then, you were still pretty safe by desktop standards.

Q: What about the time I download that one app and my phone started randomly crashing and got really slow, that's classic virus behavior, right?A: No, that's just lousy programming by the OEM. AOSP isn't 100% rock stable, and those OEM amateurs still pile poorly tested garbage code on top of that, never mind the carriers.

I never used any to be honest. I just followed the same process I do on any computer: only install software from trusted sources and don't run random executables. Yes, people can get tricked into installing something that does shady stuff and that's the same risk you run on a desktop OS. It's just not a problem I've run into on Windows or OSX or Android.

Edit: the device location/ remote wipe stuff is nice to see included. That's one thing I did use third party software for.

The real problem isn't viruses or legitimate insecurity, but apps being granted privileges the user wouldn't really choose to grant them. Instead of presenting a Hobson's choice on app install, let users pick and choose from the permissions an app requests.

I agree, but can see problems with that. If an app really does use a particular function requiring permission, but the user decided against it during installation, what does the app do when a denied permission is encountered? Hang? Force close? Lock up the device? Prompt the user? Can we rely on the developers for graceful handling of denied individual permissions, with app functionality maintained? I don't know. It's a roll of the dice, IMO.

I don't always agree to the list of permissions, particularly access to phone calls and the like in a simple, single-player game. But I understand that the function may be used, whether I like or not, so I often bail out of installations for that reason.

The real problem isn't viruses or legitimate insecurity, but apps being granted privileges the user wouldn't really choose to grant them. Instead of presenting a Hobson's choice on app install, let users pick and choose from the permissions an app requests.

I cannot possibly see that working. Imagine Joe Blow, who 1-star rages against some app he bought because it doesn't work...because he denied ALL permissions (because he don't want the gubmint or carperashuns stealing his privacy).

MAYBE, bury an option deep in the application management settings, someplace a power user could get to, but it should never pop up in a place where everyone can see it. Because a large chunk of said everyone is goddamned stupid.

I have found software like Lookout and McAfee to slow down my Android devices too much to be useful. My tablet came with McAfee and I had Lookout on my Galaxy S3. I have no urge to ever install those apps now days.

I never used any to be honest. I just followed the same process I do on any computer: only install software from trusted sources and don't run random executables. Yes, people can get tricked into installing something that does shady stuff and that's the same risk you run on a desktop OS. It's just not a problem I've run into on Windows or OSX or Android.

Edit: the device location/ remote wipe stuff is nice to see included. That's one thing I did use third party software for.

So you have absolutely no security software of any kind on your Windows PC? Not even the 100% free Microsoft Security Essentials?

Of course, unlike Lookout and, I assume, the other 3rd party tools, I don't think there's a way to push a "where you at?" sort of message to the phone, to force it to check its location at a given moment. But, you can still get a fair idea of where the phone has been.

1) it does works, iOS does it and it works retroactively on apps never meant to work with that functionality (all the app before iOS 6 never heard of permissions for contacts and such!). You just give an empty list of contacts, a 0°; 0° coordinates, an inexistent phone device, and so on. Not difficult.

2) the novice-John that gives 1 star to apps not working after revoking permissions: c'mon, you first give the app all the permissions it requires, but Android should not launch it automatically. The pro-Bob that knows about permission will then go to the prefs (or, better, to the app infos) and will reduce them manually. Novice users: happy; pro users: happy.If John decreases anyway the permissions without knowing what he does, he will have issues and he may even give some 1-star rankings but a) you cannot protect a system from extreme stupidityb) he will realize soon that too many apps are not working and either will abandon Android or will understand the mistake.

The real problem isn't viruses or legitimate insecurity, but apps being granted privileges the user wouldn't really choose to grant them. Instead of presenting a Hobson's choice on app install, let users pick and choose from the permissions an app requests.

I cannot possibly see that working. Imagine Joe Blow, who 1-star rages against some app he bought because it doesn't work...because he denied ALL permissions (because he don't want the gubmint or carperashuns stealing his privacy).

MAYBE, bury an option deep in the application management settings, someplace a power user could get to, but it should never pop up in a place where everyone can see it. Because a large chunk of said everyone is goddamned stupid.

Not those scary 1-star reviews! If you have a mindset that everyone not you (or in your clique) is 'goddamned stupid', you must have some really poor interactions with the rest of the world.

As for the useful part of your post, Cyanogen 9 already has a permissions management piece built in. If you enable it, it lets you revoke permissions that have been granted to applications, and works very well. If an application tries to use a permission you've revoked, it crashes and gives you an option to re-enable those permissions. I'm pretty certain anyone who revokes permissions is going to know that if they remove access to the contact list from something, and then try to access their contacts through that application and it crashes, they need to re-enable contact access.

I'm still trying to wrap my head around your belief that someone could intentionally disable something and then wonder why it's disabled, but I think it goes back to your early comment that the entire world that isn't you is goddamned stupid. Which is a pretty stupid statement in itself, but I don't think you see the comedy in it.

The real problem isn't viruses or legitimate insecurity, but apps being granted privileges the user wouldn't really choose to grant them. Instead of presenting a Hobson's choice on app install, let users pick and choose from the permissions an app requests.

I cannot possibly see that working. Imagine Joe Blow, who 1-star rages against some app he bought because it doesn't work...because he denied ALL permissions (because he don't want the gubmint or carperashuns stealing his privacy).

MAYBE, bury an option deep in the application management settings, someplace a power user could get to, but it should never pop up in a place where everyone can see it. Because a large chunk of said everyone is goddamned stupid.

Not those scary 1-star reviews! If you have a mindset that everyone not you (or in your clique) is 'goddamned stupid', you must have some really poor interactions with the rest of the world.

As for the useful part of your post, Cyanogen 9 already has a permissions management piece built in. If you enable it, it lets you revoke permissions that have been granted to applications, and works very well. If an application tries to use a permission you've revoked, it crashes and gives you an option to re-enable those permissions. I'm pretty certain anyone who revokes permissions is going to know that if they remove access to the contact list from something, and then try to access their contacts through that application and it crashes, they need to re-enable contact access.

I'm still trying to wrap my head around your belief that someone could intentionally disable something and then wonder why it's disabled, but I think it goes back to your early comment that the entire world that isn't you is goddamned stupid. Which is a pretty stupid statement in itself, but I don't think you see the comedy in it.

You have too much faith in people. I am with the OP. I could see this scenario play out quite often.

Not those scary 1-star reviews! If you have a mindset that everyone not you (or in your clique) is 'goddamned stupid', you must have some really poor interactions with the rest of the world.

Clique? I have no clique. I don't even use the word. I do, however, work in IT for a living, and I'm thinking of 90% of my user base. Good people, mind you (largely, so not really deserving of my denigration...most of the time), but not the kind of people able to troubleshoot problems caused by denying permissions they didn't really understand in the first place.

Quote:

As for the useful part of your post, Cyanogen 9

Stopped reading right there. People who flash CM onto his/her phone, are not the kind of people who are:

1) Relevant to the discussion. They already have CM and can adjust permissions as they like and deal with the consequences.

2) Remotely close to a majority of users. Not even a minority. It is a subset of a subset, barely a tenth of a percent of the Android install base. CM has a install base of between 2 and 3 million, out of an Android user space that's rapidly approaching 1 billion.

Android should make possible to disable permission individually. If you check the permission list you see many can be negated returning nothing and the app already accept that. Even if an app has permission for sending an sms or for location data, it's coded for exceptions in the case the SIM isn't inside or GPS is disabled. Almost every permission can be disabled without problem. If an app crash for a removed permission is usually badly programmed.

Android should make possible to disable permission individually. If you check the permission list you see many can be negated returning nothing and the app already accept that. Even if an app has permission for sending an sms or for location data, it's coded for exceptions in the case the SIM isn't inside or GPS is disabled. Almost every permission can be disabled without problem. If an app crash for a removed permission is usually badly programmed.

This is a bad idea for reasons already stated, and also because usually apps require most of the permissions that they request (I say "most", not "all") in order to perform their most basic of operating requirements. If you disallow an app to store data that it needs to cache on your internal storage, for example, if this renders the app entirely useless, then what was the point of you even trying it out if you're going to be denying it what it needs to run? I think the "all or nothing" approach to permissions they have going on right now is good. If you don't want any aspect of the app to be able to function correctly and do it's thing, you don't install the entirety of the app. It makes the decision simple, and developers don't have to worry about coding for each and every possible combination of granted permissions for their app, and they can focus on what's important.

Not all of us wear tin-foil hats. Instead, many of us just exercise common sense. Is this app from a trusted company you've heard of before? Is the app open source? Have many, many people installed and tried it before you and not reported any malicious behaviour? These are all easy questions to ask yourself that take seconds.

The onus should be on the user to decide if the app is safe to install and give permissions for whatever it requests. The onus should NOT be on the developer to protect you from yourself.

Lastly, it's worth mentioning that permissions requests are listed in the manifest file of the compiled apk, and don't necessarily mean that these are all permanently granted once the app is installed. It's just the possible permissions that the app *might* need. For example, it might say that the app requires use of your GPS, but usually (more often than not), apps that request such permissions have an option in their settings menu to disable this functionality as part of the design of the app. "WiFi-Only" is something a lot of apps incorporate into their settings, revoking manually the permission of the app by the user to use their data connection. The app has permission, but the setting ensures that it will only use WiFi.

Remember: Just because it asks permissions doesn't mean it will use all of them, as many times PRESENTLY, there are adjustable settings within the app to turn these things off or on at your whim.

If in doubt, download an app, try it out, check out what settings are available, and if you don't like it, uninstall it. Simple.

Q: Were they ever necessary?A: No, unless you were really into pirating APKs. Even then, you were still pretty safe by desktop standards.

Q: What about the time I download that one app and my phone started randomly crashing and got really slow, that's classic virus behavior, right?A: No, that's just lousy programming by the OEM. AOSP isn't 100% rock stable, and those OEM amateurs still pile poorly tested garbage code on top of that, never mind the carriers.

This.

I've been using Android since the G1. There hasn't been a time where task managers or security apps have been necessary.

Android should make possible to disable permission individually. If you check the permission list you see many can be negated returning nothing and the app already accept that. Even if an app has permission for sending an sms or for location data, it's coded for exceptions in the case the SIM isn't inside or GPS is disabled. Almost every permission can be disabled without problem. If an app crash for a removed permission is usually badly programmed.

This is a bad idea for reasons already stated, and also because usually apps require most of the permissions that they request (I say "most", not "all") in order to perform their most basic of operating requirements. If you disallow an app to store data that it needs to cache on your internal storage, for example, if this renders the app entirely useless, then what was the point of you even trying it out if you're going to be denying it what it needs to run? I think the "all or nothing" approach to permissions they have going on right now is good. If you don't want any aspect of the app to be able to function correctly and do it's thing, you don't install the entirety of the app. It makes the decision simple, and developers don't have to worry about coding for each and every possible combination of granted permissions for their app, and they can focus on what's important.

Not all of us wear tin-foil hats. Instead, many of us just exercise common sense. Is this app from a trusted company you've heard of before? Is the app open source? Have many, many people installed and tried it before you and not reported any malicious behaviour? These are all easy questions to ask yourself that take seconds.

The onus should be on the user to decide if the app is safe to install and give permissions for whatever it requests. The onus should NOT be on the developer to protect you from yourself.

Lastly, it's worth mentioning that permissions requests are listed in the manifest file of the compiled apk, and don't necessarily mean that these are all permanently granted once the app is installed. It's just the possible permissions that the app *might* need. For example, it might say that the app requires use of your GPS, but usually (more often than not), apps that request such permissions have an option in their settings menu to disable this functionality as part of the design of the app. "WiFi-Only" is something a lot of apps incorporate into their settings, revoking manually the permission of the app by the user to use their data connection. The app has permission, but the setting ensures that it will only use WiFi.

Remember: Just because it asks permissions doesn't mean it will use all of them, as many times PRESENTLY, there are adjustable settings within the app to turn these things off or on at your whim.

If in doubt, download an app, try it out, check out what settings are available, and if you don't like it, uninstall it. Simple.

Your post goes way too far in the other direction. I say this as a long time Android user: Apple doesn't have permissions right in general (and obviously side loading is still a no-go there), but they absolutely got permissions right for the things they deemed "personal data" in iOS 6.

There are some permissions that aren't a big deal to grant at installation time (like being able to store data), but there are several permissions that *are* a big deal. A reasonable-looking app might need access to your contacts and the internet, and you agree because you want the app. You've now given them enough permission to pull a Path and copy your entire contacts list to their server for further use on their part. You really don't see how a binary decision there is not adequate?

To repeat a line from your post:

Quote:

The onus should be on the user to decide if the app is safe to install and give permissions for whatever it requests. The onus should NOT be on the developer to protect you from yourself.

Exactly. I should not have to rely on a button the developer provides to disable GPS *when it's my freaking phone*. I need the tools to protect myself. It should then be up to the developer to decide if they can function with an empty contacts list or an unresponsive GPS, and, if not, to put up a message saying "this app can't function without GPS". Fortunately for backwards compatibility, these are situations they already have to account for (no network access, new phone with no contacts, no user account set up yet, etc), so Google can make this change as easily as Apple did with the latest iOS.

I've been using Android since the G1. There hasn't been a time where task managers or security apps have been necessary.

Ehh...Task managers were needed to manually force close troublesome apps up until...what...2.2? Or maybe it was just a PITA to do it before then. Either way, no one needed an auto-app killer, or the "kill all" button which is added to some handsets by OEMs.

I've been using Android since the G1. There hasn't been a time where task managers or security apps have been necessary.

Ehh...Task managers were needed to manually force close troublesome apps up until...what...2.2? Or maybe it was just a PITA to do it before then. Either way, no one needed an auto-app killer, or the "kill all" button which is added to some handsets by OEMs.

Android should make possible to disable permission individually. If you check the permission list you see many can be negated returning nothing and the app already accept that. Even if an app has permission for sending an sms or for location data, it's coded for exceptions in the case the SIM isn't inside or GPS is disabled. Almost every permission can be disabled without problem. If an app crash for a removed permission is usually badly programmed.

This is a bad idea for reasons already stated, and also because usually apps require most of the permissions that they request (I say "most", not "all") in order to perform their most basic of operating requirements. If you disallow an app to store data that it needs to cache on your internal storage, for example, if this renders the app entirely useless, then what was the point of you even trying it out if you're going to be denying it what it needs to run? I think the "all or nothing" approach to permissions they have going on right now is good. If you don't want any aspect of the app to be able to function correctly and do it's thing, you don't install the entirety of the app. It makes the decision simple, and developers don't have to worry about coding for each and every possible combination of granted permissions for their app, and they can focus on what's important...................................The onus should be on the user to decide if the app is safe to install and give permissions for whatever it requests. The onus should NOT be on the developer to protect you from yourself..................................Remember: Just because it asks permissions doesn't mean it will use all of them, as many times PRESENTLY, there are adjustable settings within the app to turn these things off or on at your whim.

My point is almost any permission can be denied for compatibility, because the developer has already implemented exceptions for the worst case so denying manually should make no difference from the app standpoint. This are examples of what the OS can return to the app when you deny a permission:SMS: not availableInternet: wifi and data disabledSD card: return IO exception or say it's full and can't be writtenGPS: unavailableContact: emptymessages:emptyaccounts: nonelist of process: return a list of common components.....

I don't say normal users have to check permission but an "hidden" settings should be available by the system IMO. Also I don't want to rely on the app if it says it doesn't use my data when Wifi isn't available.

And apps need permission if they have to store on the SD, not if they store in their folder.

I would like to know more about the next vector for viruses on mobiles: Web browsing. Once people finally start to realise that installing dodgy apps might not be the best idea in the world (and side-loading apk's is less common then the other issues I mention); I find it strange that there is so little acknowledgment of this fundamental issue. I see no mention of how Google intends to contend with this.

Also, IMO vendors like Comodo have superseded Avast et al a long time ago.

For anyone still wanting phone tracking without anit-malware, I suggest getting an app called "Prey".

Wait a sec... the last time I recall hearing the name Gupta was Henry Gupta from Tomorrow Never Dies. He was one of the bad guys (tecno-terrorist apparently), and we're suppose to trust THIS Gupta? I think not!

1) it does works, iOS does it and it works retroactively on apps never meant to work with that functionality (all the app before iOS 6 never heard of permissions for contacts and such!). You just give an empty list of contacts, a 0°; 0° coordinates, an inexistent phone device, and so on. Not difficult.

2) the novice-John that gives 1 star to apps not working after revoking permissions: c'mon, you first give the app all the permissions it requires, but Android should not launch it automatically. The pro-Bob that knows about permission will then go to the prefs (or, better, to the app infos) and will reduce them manually. Novice users: happy; pro users: happy.If John decreases anyway the permissions without knowing what he does, he will have issues and he may even give some 1-star rankings but a) you cannot protect a system from extreme stupidityb) he will realize soon that too many apps are not working and either will abandon Android or will understand the mistake.

There is an app that does pretty fine grained permission control on ROOTED/UNLOCKED ONLY devices. Called LBE PRIVACY GUARD. works like a charm on my HTC ONE X (tegra3) which has a lot of shovelware preinstalled in its stock rom. If I recall right htc's calculator app had some odd permission requirements (making phone calls??? Really???)

The real problem isn't viruses or legitimate insecurity, but apps being granted privileges the user wouldn't really choose to grant them. Instead of presenting a Hobson's choice on app install, let users pick and choose from the permissions an app requests.

This makes building an application much more difficult. It will lead to buggier applications, longer development and update waits, higher prices for apps, a more confusing user experience. A one shot on install permissions screen is a simple and elegant solution to all of these problems and I hope as a developer that they never change this. If you don't like the permissions, don't install the app.

I use avast and lbe security master (the full fat chinese one, google translated on xda rather than the cut down version in the play store). Lbe feeds apps junk random data or blocks permissions entirely. Its great because to all intents and purposes the app sees a different phone with a different imei at a different location every time it runs, making any in-app tracking useless.Avast is superb, the sms commands let you control the phone remotely, even secretly answering the phone so you can listen in on the thief.it can also forward all sms sent to the thief, send his contacts to you, securely wipe the phone or completely brick the device by killing the bootloader. There`s also a web interface that tracks the phone on a map and allows remote control. It also survives a factory reset unscathed if your rooted.

A smooth read article even though it was quite detailed and took different perspectives while still remaining objective - the kind of quality I expect on on this site.

I like this author, her attractive smile helps as well please don't lose her, Ars!

If anyone's still reading this then I'm probably going to get slammed for this, but it must be said:

With a pseudonym like that, I really wanted to like this author as soon as she appeared. However her writing has at best been somewhat... uneven. I'll still read her stuff because I'm an information junkie, but most of her work seems incomplete to me. If she ever leaves Ars, I'll miss the name and the picture of the girl from "Moonlighting" (yes, I'm carbon-dating myself) more than I will her articles (unlike a couple of other big-name departures Ars has experienced somewhat recently).

Moving on to the article itself, if not the topic proper:

Article wrote:

Hiroshi Lockheimer, vice president of engineering for Android

With a name like that, did this guy EVER doubt what he was going to be when he grew up? I mean, heck, Google musta just stamped "hired" on his application as soon as they saw that name.

(There was a time when I never would even have allowed myself to THINK something so... racist (for lack of a better term - maybe "stereotypical"), so don't jump all over me for having finally loosened up enough to have fun with things like this - the lump of coal up my ass had long since hardened into a diamond anyway.)

Great article, Florence. I think you raise some interesting questions about the need for 3rd party security scans when Google will do some of this natively.

The reality is that Google hasn't shown a great track record in their ability to monitor malware at their official app store (Google Play), even after the introduction of "Google Bouncer" several months ago. This doesn't give us, as users, too much confidence into relying solely on their security updates on Android 4.2. If I can draw a parallel to the PC world, even if Windows offered security built-in, most users still used 3rd party coverage from security firms who's core-competency _is_ security... it adds more layers of protection.

However, something that both Google _and_ most mobile security firms are missing is the fact that the overall risk in the app ecosystem is not just related to malware. Although mobile malware is growing exponentially, malware still represents <1% of the total app count. However, we've found that over 80% of the top 100 apps can access user and corporate sensitive information.

Security, privacy, and proper sensitive-data management are all crucial components of an apps overal risk. It is important for users to see the whole picture when evaluating an app's security profile, rather than just focus on malware. This is specially true for users who bring their own device into an enterprise setting, where apps that are not built securely can place corporate data at risk.

Using services such as Appthority can help users identify risky behaviors in apps to find which apps are safe enough for them. Unlike malware (which is binary... it's either malware or it's not), overall app risk is in they eye of the beholder... the same app that is safe for a Cisco employee might not be safe enough for a Morgan Stanley employee as they have different data on their devices and thus different risk tolerance. There is definitely more room in this space than simply relying on native or built-in security offerings.

Florence Ion / Florence was a former Reviews Editor at Ars, with a focus on Android, gadgets, and essential gear. She received a degree in journalism from San Francisco State University and lives in the Bay Area.