Google: Less Than One Percent of Android Devices Are Affected By Harmful Apps 91
jfruh writes: One of the selling points of iOS is that its more restrictive nature makes it more secure. But even though it's easier for users to accidentally install malicious apps on Android, data collected by Google (PDF) indicates that less than one percent of Android users have actually done so. Quoting: "During October 2014, the lowest level of device hygiene was 99.5% and the highest level was 99.65%, so less than 0.5% of devices had a Potentially Harmful Application (PHA) installed (excluding non-malicious Rooting apps). During that same time period, approximately 0.25% of devices had a non-malicious Rooting application installed. ... Worldwide, excluding non-malicious Rooting applications, PHAs are installed on less than 0.1% of devices that install applications only from Google Play. Non-rooting PHAs are installed on approximately 0.7% of devices that are configured to permit installation from outside of Google Play. Additionally, the second graph shows devices with any PHA (including Rooting applications). Rooting applications are installed on about 0.5% of devices that allow sideloading of applications from outside of Google Play."
Bring back... (Score:2, Offtopic)
AppOps, tyvm. Done.
0.5 percent of 1 billlion is (Score:1)
A lot.
Re: (Score:1)
Well, let's see
If only Jayne from Firefly could help us with the math.
1% of more than a billion?
1+1x1, carry the zero, x 1 billion, divided by, oh goram that's a lot! I aint never seen numbers that big.
A less biased source please? (Score:1)
If Google or Apple talk stats about their ecosystem, take it with a giant grain of salt.
It's pure marketing BS.
Re:A less biased source please? (Score:4, Funny)
According to Apple, iOS users are more virile, and have love-making stamina for hours.
According the Microsoft, Windows Phone users are endowed with the power of invisibility, which is why they are so elusive.
Re: (Score:2, Funny)
"Waah! I don't like teh Appul! It's teh gay!!11111!1" (Self-entitled smirk) (Gets modded up by other smug, self-entitled Slashdotters)
Re:A less biased source please? (Score:5, Insightful)
Even in F-Droid, over half the apps want to read my device ID and permission to record all my calls and contacts, and less than 1% have a legit reason for that info. The vast majority of apps in their walled garden don't actually need any special permissions at all to do whatever the app does, or maybe 1 permission. Find an app that has only the permission it needs. Good luck, hope you ate a big breakfast before you started searching.
How is tracking me with nothing given in return not "harmful?" My privacy has value to me, surely. The claim that there is no harm relies on the known lie that my privacy has no value to me.
The honest truth is that they think less than 1% of android apps do harm that doesn't benefit google . That is actually a different thing than what they're saying, though. So I call lie .
Re: (Score:2)
You don't "know" that, because if you spent time with it and were paying attention, you'd know otherwise.
In some cases they strip out analytics libraries, for example. However, many of those apps are still asking for your device ID and "phone status." "Phone status" sounds like it is about the current status, but actually that exposes all the numbers you call, when, for how long, etc.
And the same app will ask for full network access, even though if you look at the traffic, almost all of them are using HTTP
"Phone status" to avoid the OOM killer (Score:2)
"Phone status" sounds like it is about the current status, but actually that exposes all the numbers you call, when, for how long, etc.
Perhaps it's just to give the app advance notice to autosave the user's unsaved work in case the app gets forcibly OOM-killed by the dialer app on an underpowered device. The problem is with Android itself: the permission for "tell when the phone is ringing" is conflated with too many other capabilities.
And the same app will ask for full network access, even though if you look at the traffic, almost all of them are using HTTP to talk to their services
Your app still needs "full network access" if you want it to do anything other than open web pages in a web browser. Or were you planning on opening a web page in a web browser to send the data to the server
Re: (Score:2)
There are other mechanisms to save work. Also, the whole platform requires you to assume you can be interrupted at any time. This is almost entirely mitigated by the API giving you a sqlite database to store all your crap in. It will still be there. The part the user is interacting with is just a viewer, it is not the core of an app.
It is absolutely, unquestionably, an awful app that would try to use it as you describe. The platform isn't designed to tell you what is happening and to preserve your running i
For both OOM killer and battery use (Score:2)
Also, the whole platform requires you to assume you can be interrupted at any time. This is almost entirely mitigated by the API giving you a sqlite database to store all your crap in. It will still be there.
Would it be prudent for the application to COMMIT the SQLite database after every single character the user types, every single brush stroke in a drawing program, or every frame of a real-time video game, just in case the backend is killed by force? If not, what would be an appropriate compromise?
The only app that needs to know the phone state is a dialer app
Another problem conflated with "phone state" is whether the user is connected to the Internet at all. Say an application is designed to retrieve data from the Internet when the user happens to be momentarily connec
Re: (Score:2)
sqlite doesn't work that way, and file write buffers don't disappear and lose data when an app is killed. That is LOL-level stuff, man.
Googling the details of a specific issue in programming for an API may not return useful results when you're not a programmer in that area. However, your ignorance doesn't demonstrate anything. It actually refutes the idea that you're even disagreeing with me, or participating in the conversation. You don't understand the details, so you'll have to take my word for it; or no
Re: (Score:2)
sqlite doesn't work that way
Let me rephrase in a way that doesn't depend quite as much on the technical details of a particular platform: How many seconds of the most recent work do users expect to accept losing when an app is killed?
file write buffers don't disappear and lose data when an app is killed.
My experience differs, at least on a different platform. When I was in college, I used a schematic capture program called LogicWorks on the Windows operating system. If the user added a part to the parts library file or modified a part in the parts library file, and then shut down LogicWorks uncleanly (su
Re: (Score:2)
sqlite doesn't work that way
Let me rephrase in a way that doesn't depend quite as much on the technical details of a particular platform: How many seconds of the most recent work do users expect to accept losing when an app is killed?
LOL no, that won't help you understand any better. At best it helps you sound less ridiculous. What would the use of making technical comments with less understanding be?
file write buffers don't disappear and lose data when an app is killed.
My experience differs, at least on a different platform. When I was in college...
Woah there cowboy, maybe the crap you used in college just sucked, eh? You mention windows, so I have to tell you... other platforms already had buffers and shit that didn't suck. Sorry you had... whatever it was... happen to you. But it doesn't help you understand the issue on the Android platform where you have to expect things to get kil
Re: (Score:2)
LOL no, that won't help you understand any better.
Then what would help me understand better? I'm trying to be sincere here. How do apps normally avoid loss of the most recently entered data in case of a shutdown that effectively already happened, such as the last keystrokes before the app is killed? The sequence is supposed to be pause, stop, destroy, but I've read that the OOM killer occasionally skips these steps when under severe memory pressure.
Well, then your assumption is invalid wherever the app doesn't require a login. So if you have to concede that my point is sometimes valid, you can then also address your arguments about it to the cases where it is valid.
Apps that do not require any login whatsoever are likely to be read-only. Read-only apps can use ad-hoc encry
Re: (Score:2)
Because in Android development you're required to use a different paradigm that assumes the app the user is interacting with will be killed at any moment. So there is no important work being done in that process. The important work is being done in a background process that is lightweight and doesn't need to get killed when the app interface is killed.
If the phone status changing causes the app you were using to be killed (the most recent app used will actually not be killed then, but the penultimate app is
Re: (Score:2)
However, it lets them look at what all your network connections are.
Is ACCESS_NETWORK_STATE too intrusive? If so, what's the preferred way for, say, a mail client to determine when a device has an Internet connection in order to start downloading updated information in the background for later use while offline? Should users have to install an additional helper app from Google Play Store for each potentially intrusive permission that a main app might optionally use? Or do you think apps shouldn't allow for background updates in the first place?
Re: (Score:2)
If the purpose of the app is not to manage network connections, then that is useless information. It is just supposing that you should check first, without any reason.
A key thing to understand is that checking if the OS says a connection is up doesn't mean your connection will succeed or that there is really a real connection. The networking technology is already designed to deal with that. You have to have error handling already. Checking the network connection first is silly, it adds extra code to bug out
It's about saving battery power (Score:2)
A key thing to understand is that checking if the OS says a connection is up doesn't mean your connection will succeed or that there is really a real connection.
I'm aware of that. I just wanted to find a way for the app to know when it is worthwhile to spend the device's battery charge on attempting to sync.
The way to find out if you can connect is by connecting.
Every five seconds? If not, then how often?
That is the same as on a desktop computer.
The key difference is that unlike a mobile device, a desktop computer has essentially unmetered energy. In addition, a desktop computer's Internet connection is far more likely to be always-on, unlike a laptop or tablet that gets used in a moving vehicle.
And maybe they're happy with it trying again after a minute.
If the app keeps "trying again after a minute" for four hours, som
Re: (Score:2)
>How is tracking me with nothing given in return not "harmful?"
I agree, except for the "nothing given in return" part. They're giving you the use of their software. Part of the price you pay is letting them spy on you. A nice straightforward business transaction - except for the fact that their spying is usually deceptively obscured.
I have no problem with a piece of software that spies on me as part of its declared up front price - I'll tell them to go fuck themselves and look for an alternative unless
Re:A less biased source please? (Score:4, Informative)
Even in F-Droid, over half the apps want to read my device ID and permission to record all my calls and contacts, and less than 1% have a legit reason for that info.
(I'm a member of Google's Android security team.)
This is a valid issue, but separate from what the report is attempting to address. Well, not entirely separate, because the Android security team does in some cases classify apps that request excessive permissions as potentially-harmful, but only when there's evidence that the apps are actually trying to abuse the user.
Note that I'm not trying to downplay the issue of apps that request more permissions than they need. I think (based on lots of evidence) that in most cases this is more an artifact of developer laziness than malice; they aren't sure exactly what they need and definitely don't know what they're going to need in the future and so find it easier to ask for the world. This is a problem the Android security team recognizes and is working to address, in various ways that I can't go into.
How is tracking me with nothing given in return not "harmful?" My privacy has value to me, surely. The claim that there is no harm relies on the known lie that my privacy has no value to me.
Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.
The honest truth is that they think less than 1% of android apps do harm that doesn't benefit google.
Benefit to Google, or lack thereof, is completely irrelevant to the Android security team's decision to classify an app as potentially harmful or not. In general, the Android security team treats the rest of Google as just another app developer and online service provider. It's not our job to enable their revenue streams. Granted that we recognize that those revenue streams pay our salaries, but in the long run treating users well is what will enable Google to continue making money and paying our salaries.
Re: (Score:2)
IMHO, the Google/Android security team is doing a good job. I have never gotten stung on the Play Store, and I've not encountered "fishy" apps (ones that have horror stories in the reviews) that didn't get taken down quickly in a long time.
Of course, I am still partial to XPrivacy, because it doesn't deny an app permissions... it just feeds it BS. However, I do think Google has kept with the times in terms of security.
The black eye with Android isn't Google's fault. Virtually all reports of malware I se
Re: (Score:1)
The black eye with Android isn't Google's fault. Virtually all reports of malware I see here in the US are due to people going to shady repositories for pirated apps. Yes, it might "save" $1.99 on an app, but there is a good chance, a lot more "functionality" might come with the .apk file.
And so there it is: the exact argument for a Curated Collection (a/k/a "Walled Garden")...
Thank You.
Re: (Score:2)
...have you ever administered users in a Mac environment? I have. It made me want to leave IT.
Why yes. Yes I have. In a mixed environment with Windows, so I know the difference.
In that particular case, the Windows:Mac ratio was only about 2:1, yet the trouble-ticket ratio was about 50:1, with Windows being the "50", of course. And no, it is not a reflection on my IT skills in either environment; nor of the relative complexity of the tasks to which the machines of each OS were put; but rather a testament to the stability and ease-of-use (or lack thereof), of each.
. And judging from your responses
Re: (Score:2)
Yes, but Google gives you the choice; a simple settings parameter will allow you to step outside that walled garden (giving me hesitation to even term it as such) while Apple requires you to jailbreak your phone, which they forbid and actively try to prevent.
For billionth fucking time.
WOOSH!
You were so filled with Apple Hate that you completely missed the point: That, perhaps that, even given the choice (which I bet most Android users actually don't tKe advantage of anyway), the number of times that going outside of the Garden would solve an actual need for all but the most esoteric of uses, is so vanishingly small, that it just doesn't make sense by an overwhelming margin.
Typical egotistical slashdotter; what's good for me must be good for the platform...
Re: (Score:2)
Re: (Score:3)
Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.
So when are you going to give us the ability to disable permissions on a per-app basis? You know, like you added to the OS a few revisions back, then took away again?
This is the biggest single reason I recommend people not to buy Android these days if they ask. I'm sick of apps asking for all kinds of permissions that I don't want to give them, and not having any way to block them.
Re: (Score:2)
I recently moved back to an iPhone, after a few years on Android. It is so very nice to be able to update my apps, and not have to review all of the extra permissions that every app is requesting. And not having to manage the permissions in appops/xprivacy.
Re: (Score:2)
Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.
So when are you going to give us the ability to disable permissions on a per-app basis? You know, like you added to the OS a few revisions back, then took away again?
This is the biggest single reason I recommend people not to buy Android these days if they ask. I'm sick of apps asking for all kinds of permissions that I don't want to give them, and not having any way to block them.
That really blasts their Pollyanna "it's all roses" line out of the water. If they hadn't made something that was really great on a technical level, that can give us what we want, and then scaled it back so we can't have it... then I'd still be listening to their line. A few short years ago there was nothing I loved more than a new Google API. Now, it reads the same as "Microsoft API," e.g., something I may have to be aware of at work, but not the thing we're actually going to be using.
Re: (Score:3)
Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.
Of course, then there's THIS [informationweek.com].
Re: (Score:2)
If you are the type of person who will do it, you are not likely to see the fault in your actions.
Re: (Score:2)
I'm sorry, but I simply don't believe you (by the way, is the 'Android Security Team' still six guys, or did you recruit some new people / start talking to the main Google security teams?). If Google cares so much about my privacy, then why does the 'enable Google tracking my location' dialog box have a 'don't ask me again' option that's only enabled if you select 'yes' and not if you select 'no'? This is a relatively recent change in newer versions of Android: previously you could permanently disable the
Re: (Score:2)
To expand on this:
If they wanted to add to the dev tools the capability to auto-generate permissions by running the app in a sandbox, measuring what permissions it actually used, and then generating the manifest, that would be easy to do. In fact, you could just have a test suite that exercises all the app features to drive it. That way for people who write tests, they would get tailored permissions for free; and any missing permission would be parallel to a missing test, and so it would help mitigate bug e
Re: (Score:2)
While I mostly agree with you, there are location-faking apps out there. Probably require root, but on the Google-branded devices that is easy to get since they are unlocked. It doesn't really help much, though.
The ironic thing is that when it comes to Google's money-maker, advertising, they're the only company that protects the consumers data. (by keeping it to themselves and being the middle-man) And then when it comes to their platform, they started with that philosophy, then changed their ways and featu
Re: (Score:2)
The honest truth is that they think less than 1% of android apps do harm that doesn't benefit google.
Benefit to Google, or lack thereof, is completely irrelevant to the Android security team's decision to classify an app as potentially harmful or not.
Nonsense. Broaden the meaning of the words until what I said sounds like a true statement; good, now you've understood my statement. ;)
Like you admit, if you attribute it to laziness you just assume there is no problem. It would be harmful for google to actually try to address the problem, because the only solution for lazy developers would be to inconvenience them in some way; kick their apps out until they fix their permissions. Your whole statement just reinforces my original view; the problem is addressed only in the area that google gets blamed for ("malicious" apps) and totally ignores the problem that hurts users more: incompetence that turns any app security bug into super-malware. Your position makes perfect sense, if the PR of the Google Play Store is the concern.
And history of walled garden software repositories shows that this approach results in malicious parties putting their apps in without the bad parts first, then later making changes in updates. If you're accepting security problems as long as they are only lazy mistakes, you're not protecting against much. The first wave of security work is just enabling the second wave of attacks in that case. The same thing as is happening to advertisers. Google is what it is today mostly because of text ads; there is no malware vector. Everybody else gives power to advertisers to spew HTML blocks at customers, and it is full of malware. Reviewing the ads in advance isn't helping the competition. Google's left hand doesn't have the wisdom of the right hand, unfortunately.
With f-droid though, I can just download the source code, remove the permissions, recompile, and install by hand. Done and done.
Re: (Score:2)
Same thing happens in iOS, except you don't know it is doing so. Try a jailbroken device with PMP (Protect my Privacy), and you will see that a lot of iOS apps do a lot more phoning home than you would think.
Log files, or it didn't happen.
Re: (Score:2)
What do you mean? A company might be dishonest when they audit themselves for marketing purposes? I don't believe you... /sarcasm
Re:A less biased source please? (Score:4, Informative)
If Google or Apple talk stats about their ecosystem, take it with a giant grain of salt.
It's pure marketing BS.
Take it with a grain of salt, sure, that's wise. However, there's nothing marketing-related about the numbers in the report. These numbers are snapshots of the data the Android anti-malware team uses internally to assess its effectiveness. The numbers are not fudged, and what they show is that while there are issues, Google's anti-malware team is making solid progress and the current state of the ecosystem is actually not too bad. There are some caveats (called out in the report) around the fact that the numbers describe the prevalence of known potentially-harmful apps. The charts get revised retroactively when new PHAs are discovered but snapshots in reports are static. Still, I think the numbers are quite reliable.
Note that I'm a member of the Android security team, and my manager is the primary author of the report and blog post, though I work on platform crypto features, not anti-malware.
At worst, the numbers in the report represent the ways in with the Android team fools itself about the state of ecosystem security. At best they're an accurate and nuanced reflection of the state of the ecosystem. The truth is somewhere in between, but I think it's far, far closer to the latter than the former. What the numbers definitely are not is anything cooked up specifically for the public.
Re: (Score:2)
Indeed. For me, the biggest questions were regarding the date range of the data being used. Why just one month's stats from 6 months ago? Why October specifically, rather than continuing on beyond?
Turns out I managed to answer my own questions while scanning through the report for answers. October is when they began monitoring these statistics, so that explains why it starts when it does. As for why the stats only run through the end of October, they were preparing the report in February, apparently, and th
PHA? (Score:2)
Re: (Score:2)
They don't claim 100% accuracy, but they readily admit in the paper that they aren't an oracle who can immediately recognize PHAs on sight. Rather, the capture data for all app installations, and then as apps are flagged as PHAs later (most of which happens within 60 days, according to them), they're able to make sense of the data to understand what percentage of installs were for PHAs. I.e. They're using hindsight to provide accurate data, rather than relying on the information they had at the time.
its not the apps, its the os I worry about (Score:3)
the great Short Attention Span Company(tm) EOLs phones like there's no tomorrow. my older google phone is stuck at android 2.x and will never get updates. I don't care about features, but I'd like kernel, ip-stack and some onboard apps to have fixes for security.
it won't ever happen. we don't really own our phones. and we are suppose to keep landfilling perfectly fine hardware - to keep the monsters in high profit.
even if I ran no apps at all, the os is buggy and full of weaknesses. I'm sure I could be attacked with an old 2.2 android os, probably in just a few minutes time.
this is why I hate phones and have zero interest in spending more money and time on this crap. the ceo's might have gotton it right: use dumb feature phones and be more secure!
Re: (Score:2)
we don't really own our phones.
This is a result of you owning your phone. If you were renting the phone, they would be expected to keep it up to date, instead, you buy it and they wash their hands of it. This is not as much a problem with Google as it is a problem with carriers. The carriers want control, so they get it and cause phones to be end of life'd quicker.
Re: (Score:2)
the great Short Attention Span Company(tm) EOLs phones like there's no tomorrow. my older google phone is stuck at android 2.x and will never get updates.
You're still using a Nexus One? Even the Nexus S got upgraded to 4.1. Serious kudos on keeping that five year-old phone running. Do modern apps run on it?
From a broader perspective, while I think Google should probably do a little better at updating older Nexus devices than it has, it's really not that bad; the Nexus 4 and first-gen Nexus 7 got Lollipop (though it doesn't run all that well on the N7v1), and I suspect that if it weren't for the fact that the SoC vendor is gone, the Galaxy Nexus would have
Re: (Score:2)
Go back to your bedroom. Loads of people think five years is still a child. I am writing this on a ten year old laptop, and regularly use a 10 year old Nokia phone (I have a new Samsung, but quite often I need to be away from the mains for more time than 3 spare batteries allow.
Electronics does not rot or rust, and in the absence of a hard disk or CDrom drive, should last 30 years.
I see no reason why Google should have to maintain old devices. However, I do think that if a manufacturer EOLs a device, which
That's Still A Lot (Score:3)
Make sense (Score:2)
I've seen a lot of crapware with too much permissions and lots of ads, just like on iOS, but nothing the user didn't agree with.
Soon enough, all these apps will be forgotten and replaced by better alternatives, just like nobody still use WinZip or any other file archiver with a nag screen.
Re: (Score:3)
Take a look at the permissions your average (free) flashlight app requests then reconsider your definition of harmful.
Re: (Score:2)
Re: (Score:2)
Me too, but that is a newer thing, many of the older phones did not include that. I was pointing out that there are many definitions of harmful.
https://www.youtube.com/embed/... [youtube.com]
According to this guy, the most popular free flashlight apps steal your personal information and transmit it to other countries. It makes for an interesting spy gadget for them apparently.
I can believe this (Score:1)
Re: (Score:2)
You're probably asking the wrong company. Ask the company who built your device. The google branded Nexus devices don't have that limitation.
Re: (Score:1)
Kind of weird to say the Google branded devices don't have the limitation of not being able to install apps to the SD card, when they don't have an SD card at all.
Re: (Score:2)
Re: (Score:2)
How else to put food on the table? (Score:2)
If not through advertisement, then how do you expect a developer to recoup the cost of developing an application for distribution without charge?
Fixed: Less than 10 million... (Score:1)
Rooting .NE. Sideloading (Score:2)
Rooting applications are installed on about 0.5% of devices that allow sideloading of applications from outside of Google Play.
When an article (and a summary) include garbage like this, I refuse to take the rest seriously. Rooting is not Sideloading. There is a feature right in every stock Android system that tells Android that it is OK to accept Apps from sources other than Google. There are apps included with factory fresh Android that will install these apps as long as the user has chosen to allow i
Re: (Score:2)
Dude! You are full of it, and besides you are an F-droid shill based on at least 3 posts promoting whatever it is in this thread.
Android already puts all apps in sandboxes. It also happens to be open source, so you can put on a tinfoil hat and hack a custom ROM to your hearts content, including denying apps you don't trust any network or shared storage access.
And if you want to be taken seriously, give an example of how core OS or Google Play specifically violated your privacy. Most people voluntarily store
1% = several million (Score:3)
95% of the brand A cars build in the last 10 years are still one road, does not mean brand A cars have a 95% chance of lasting 10 years. Only 10% of the cars built over the last 10 years is likely to be 10 years old. So they could be talking of just 50-50 chance of their cars lasting 10 years.
Define "harmful app" (Score:2)
An app that you don't want, is completely useless, that consumes storage space, but is not removable - that, to me, is harmful. By that measure, 99.9% of Android phones contain harmful apps.
Just wait until one of the cannot-be-uninstalled apps comes up with a major security vulnerability. That's going to be fun to watch.
Never trust the compromised (Score:2)
What do they actually count? When a device was compromised, the attackers should cover their tracks and the device should be difficult to identify as being compromised.
In other words, there is no "compromised' flag to easily identify on devices. Which leads to the question: what does Google's number mean?
Permissions (Score:2)