As somebody who has been following Android for a while, this statement is incredibly unfair. The Android ecosystem is huge and remarkably safe. For those actually interested in the details, the Android security team releases annual security reviews, and the report for 2016 was just released: https://security.googleblog.com/2017/03/diverse-protections-...
The tldr: the number of devices with a harmful app is 0.05%, and for 1.5B devices extremely impressive. Basically, if you only install apps from Google Play and never enable unknown sources (the default and the vast majority of users) you are safe.
While the argument that most devices aren't running the latest security patch is certainly valid, it's important to note that there are many services running on device and in the cloud provided by Google which are doing most of the heavy lifting. If anything, the example of Stagefright actually shows the safety of Android - many many devices have never received any security patch to address Stagefright and yet most users aren't affected.
Also, quote from linked blog post:
> only 0.05 percent of devices that downloaded apps exclusively from Play contained a PHA.
1. What percentage of Android devices download apps exclusively from Play? They don't say. I, for one, have quite a few not so technical friends who sideload stuff. Also, pretty much all Android devices in Mainland China don't qualify for this criterion, and that's a huge number.
2. Given the track record of malware in Play Store, the number of devices containing a PHA is probably much larger than that of ones containing a known PHA.
> many many devices have never received any security patch to address Stagefright and yet most users aren't affected.
Not sure how you even know that. Not all exploits are visible.
On the other hand, I referenced a report with actual numbers of devices impacted. Obviously you should be skeptical, but as you point out, if millions of devices affected is true, shouldn't we be seeing millions of instances of Android spam, remote roots, SMS fraud, botnets, etc.?
Yes, it is true that some users sideload, and threats to Android users vary a lot by country. There is only so much Google can reasonably do, and this is appropriate given Android is open source and has so many participants (device vendors, carriers, app stores, etc.). But it turns out with good integration with the developers, the distribution platform, and regular check ups, you can do a decent job at protecting your users.
You can also compare to other platforms and recall how devastating actual malware on Windows was, and how long Microsoft struggled (and still struggles) to protect their users. In Android, yes there are many vulnerabilities like Stagefright found, but in the end Android users are surprisingly safe.
Scary-sounding headlines, sure. But there usually is actual evidence.
> I referenced a report with actual numbers of devices impacted.
No, there is no "actual numbers of devices impacted". A number 1.4 billion is thrown out to impress; the pool of devices to which their analysis applies is much smaller, and of which only a percentage is given.
> if millions of devices affected is true, shouldn't we be seeing millions of instances of Android spam, remote roots, SMS fraud, botnets, etc.?
First, what you mentioned do exist. Maybe not in large numbers (not sure), but there's no guarantee they're not rising. Secondly, there are plenty of easier and more profitable channels for hackers these days. Please don't equate vulnerabilities not being exploited with being invulnerable.
> There is only so much Google can reasonably do.
Changing the subject? I was responding to "The Android ecosystem is huge and remarkably safe", and specifically how you quoted the blog post to back that up.
> ... in the end Android users are surprisingly safe.
Webcam users are surprisingly safe too. Not realizing their webcams are DDoS'ing some poor website right now, or their video feed is being streamed online.
Actually, there usually isn't any evidence. Scary headlines sell, finding evidence is a hard work that most readers will not understand anyway. Guess what happens then.
So instead of believing metrics gathered from Google's SafetyNet telemetry from 1.4 billion devices you would rather believe scaremongering blog posts that have no concrete data to back up their claims?
>If Android is so secure, why are we seeing (often more frequently than) weekly headlines on Android security woes, often containing something like "millions of devices affected" (and often enough, no fix in sight)?
Do you really think it's that easy to exploit an Android phone? Once you have an exploit you must then chain it with other exploits to get around all of the Android security mitigation's in place. And then there's the fact that every OEM creates their own version of Android so not every exploit will work on every device or OS version - you can thank device and OS fragmentation for that one.
So this is why bugs like Stagefright never panned out to be the security armageddon that these click bait blog sites all wanted you to believe. Just because an exploit is discovered doesn't really mean it's being exploited in the wild.
This becomes less and less true every year.
Android is open source, after all. Not much Google can do there.
If Microsoft can pull it off Google can do it too. No excuses.
stagefright is the last major Android vulnerability I'm aware of. Do you have sources for these? In my experience it's far less than weekly. Maybe yearly at most.
According to Adrian Ludwig, Android security director, not 1 Stagefright exploit has ever been seen in the wild according to the telemetry they receive from SafetyNet and the 1.4 billion devices it's installed on.
Source: ask any female hollywood celebrity.
The entirety of China doesn't even have Google Play Store.
"If the Google Play Store app still isn't showing up, contact your carrier or manufacturer for help. "
Chinese Government.
>Why doesn't Google allow it to be installed on all devices?
You can install it on devices (with varying difficulty depending on if you can unlock bootloader). It just doesn't come pre-installed on any device sold within China.
When media reports security bugs for Android, it is hardly clear whether the bugs affect AOSP or the Google branded Android, and to what extend.
So if I give you a knife to cut fruits, and clearly tell you that you can also do juggling with it but it's not recommended and you should do it at your own risk, will you still blame me if you get hurt by knife juggling?
I also have an anecdote to share. The only app I've sideloaded and helped others sideload was the one I created myself. Out of 10 teenagers who are the most probably to tinker, 0 of them usually install apps from sources outside of the play store.
Google constantly shot that down and said how it works (agree to everything before downloading) was intentional and expected behaviour. They have finally changed that model now, but in my opinion this was pretty inexcusable and reckless.
I was unable to find the issue in the Android bug tracker now, but it's a pretty long thread.
Maybe "lazy" is the best word, but moving from Android's classic "grant permissions on install" to "prompt for permission" is a major change that they spent a long time working on (I think Android 4 already had a lot of the backend for this?).
It's not like it was secretly granting permissions to apps, and you could always choose to not install something that took too many permissions.
You could say they made the wrong choice, but we're a long way from "this binary can do everything on your files" model of Unices/Windows
Perhaps they were working on it for a long time, but they were actively defending their stance for years after many people were requesting this, and after many incidents of Play Store apps intentionally doing more than expected (uploading contact lists, tracking location, etc...).
As someone who has developed and published Android apps, it was super frustrating to spend half your app description justifying each and every permission used, and still getting negative reviews simply because you had to request some scary looking permission for the most mundane feature addition.
If you're interested in the Android update situation, Adrian Ludwig just gave a talk at Next, the Google cloud conference about it (he even references the Wikileaks CIA breach): https://www.youtube.com/watch?v=Zm6ziX5pqt8
He talks about the task starting with only 5 OEMs to keep their flagships updated. And you start to see the insane complexity of running the update train: this meant 29 devices. Multiply by the 351 carrier partners, which goes to 5000+ builds and variants. That all need to be tested by all the parties. =/
The dasboard tracks versions in the wild, not the amount of users that were blessed with an update.
The report is presented in such a way, as if during 2016 the OEMs had a change of heart and now all provide updates.
Except for the half a billion Chinese Android users who can't access Google Play.
Android smartphones sold in China almost always have unknown sources enabled.
P.S. don't get service from US Cellular if there are other options
It's kind of like with RHEL - the fixes are backported in the old kernel vesion and that's it. It has nothing to do with your operator, you can thank Qualcomm and other SoC manufacturers, that they are not willing to make platform support packages for newer kernels for a given chip.
Google's inept 'management' of the android ecosystem has left us with openness for hardware vendors like Samsung but not end users. Their design of android deprives end users of regular security updates that iOS users enjoy but also deprives them of the right-to-modify that licenses like the GPL were intended to guarantee.
I don't know what everyone at Google intended, beyond 'let's beat Apple', but the way android turned out looks awfully evil to me.
By the way, the upstream Linux kernel supports the Nexus 5X! http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9...
And the bootloaders are based on fastboot pretty much everywhere I think? At least that was the case with the non-Google-related HTC phone I've had.
Android is the emblem and sigil of Tivo-ization. And Google was the key enabler of this. I get that this was successful - after all, "Android overtakes Windows as the blah, blah," is very successful. And maybe if Google had behaved ethically Android wouldn't have been the success that it is. Just don't give me any of the "don't be evil" BS. When threatened, Google was every bit as evil as Microsoft was at the height of the browser wars.
Have look at Redhat, how far got them requiring UEFI at server ARM boards. That's market, where the buyers have much more impact on the design than mobile.
Suffice to say, if it was as easy as waving the magic wand you think it is, it would have happened already.
Instead, if you tried to wave it, handset makers would have walked and just done something else. Heck, some did!
Besides, why stop at Google? Why not blame the carriers for devices like this be on their networks?
By your logic, if Verizon told Samsung tomorrow said "you must update your phone monthly with security updates in order to stay connected to our network" it would have just happened!
Maybe instead of assuming a vast lack of caring or outright maliciousnss, you should consider that maybe it's not the trivial thing you are making it out to be, and that's the real reason it hasn't happened yet.
Yes some have and some more would have. And then it would have been up to these holdouts to come up with a viable OS. Good luck with that. Almost everybody who tried has failed.
There is no doubt in my mind that Google could force it successfully, but why would they? Everything is moving in their direction anyway and users don't seem fazed.
Surely Google is not intentionally refraining from solving the high fragmentation it is suffering from (which makes developing for Android harder, and keeps some people from receiving security updates)
Because it causes friction, it's a distraction for management, and there is a danger that some of those rebel handset makers could have some success or get poached by Microsoft/Bing even if they fail at creating an alternative OS.
There is risk without much upside for Google compared to the gradual approach they are taking now.
Walking away from Android is not currently a realistic option for most of them (recent Sony Sailfish news non-withstanding).
If only they had thought of this. Oh, that's right, I forgot, it's not that this is much more nuanced and complex ecosystem interplay, it's that it's very black and white and they uniformly don't give a crap.
Sadly this also leaves us with the current sorry state of affairs. I don't think much "could've" and "would've" would be helping there, but I would very much like to see a major economic force guaranteeing some common grounds for devices. Imagine what an "IBM clone era" of phones could mean - all it would take would be a common ground w.r.t booting and a couple of drivers.
Sometimes I'm really left wondering why we can't have such nice things...
The sad part is that the 2016 security report just came out and they brag how the whole security improved, without mentioning the elephant in the room.
Google IO is around the corner and I bet they will keep talking as if everyone could upgrade right away to Android O, with N now having barely 2%.
And this mentality is eating its way into all corners of IT as there is a generational changing of the guards. More and more Linus Torvalds (Linux) and Daniel Stenberg (cURL) staying with a project for decades are massive outliers rather than a norm.
This is why they can claim that anything shipped from 2017 onwards will support Android apps, but maintain a list of potential devices from before that. Because said support need various container related features only found in newer kernels to work.
Effectively Google has further masked but not really fixed the issues that makes major updates to Android devices such a hassle.
The Pixel XL was released in October of 2017 which means updates stop one year away from today in April of 2019. Top of the line is $968 and you want top of the line for best memory performance. Why buy one of those phones and purchase sub par performance? It's a waste of money. So if I wanted one I'd pay $80/month for a device that's replaced in October of this year (Pixel 2 is supposedly an end-of-year release) and dropped from feature upgrades not too long after that.
Google need to fix their feature window by extending it to two years and fix their supply pipeline by ordering apple-like quantities of product. Otherwise they're not really competing with Apple.
But let's follow this silly thread anyway. On average, the lawsuit would take three to seven years to resolve.
Assume they win: great, they get some small amount of damages and everyone stops using Android. They can't and won't ever get the remedy of forcing security updates. It's not even something available.
Assume they lose: great, they get nothing and everyone stops using Android.
...
What did this solve again?
As for the other OEMs, there is this thing called contracts and legal obligations.
No updates, no access to Google services from invalid devices.
It is as easy as that, if Google actually cared about the consumers.
Also, the point is still valid that 36 months (or 3 years) is still rather short security lifetime for a device. At some point (presumably soon now that carriers are dropping most device subsidies) the 2 year replacement scheme of mobile devices stops being sustainable and you do start to have to deal with the long tail of people sticking to 5-15 year old hardware devices.
Google seems to have little interest in anything beyond the short horizon and that security tech debt is going to come due.
He stated "+1 for some fixes" which is incorrect as it implies that you may not get all of the security fixes for that additional year and only "some" of them.
>Also, the point is still valid that 36 months (or 3 years) is still rather short security lifetime for a device. At some point (presumably soon now that carriers are dropping most device subsidies) the 2 year replacement scheme of mobile devices stops being sustainable and you do start to have to deal with the long tail of people sticking to 5-15 year old hardware devices.
I agree it is rather short and the sooner Android OEM's can move from an SoC supplier, like Qualcomm, that only provides BSP support for 2 years the better.
Interesting.
The OP's statement was for "upgrades" not security fixes; I read it as 2 years upgrades and 1 for security fixes beyond feature upgrades. The choice of "some" was ambiguous, but "upgrades" is much less ambiguous to me than you seem to consider and not something I'd directly confuse with "security fixes" alone and something that the (+ 1) seemed to directly add "security feature" context to me, despite the ambiguous wording.
Though that still raises the question of if Google properly subsets general (feature) upgrades and security fixes across that 2 + 1 time period. The ambiguous word choice of "some" could be an editorial indication that the OP considers that Google is likely to release some fixes in more general upgrades that don't fall into that (+ 1) time period. As a non-Android user/follower, I have no knowledge in that area and no opinion to offer of my own if that may in fact be the case. I'm also not the OP so I can't express whether or not that was an editorial opinion.
Even if it was an editorial opinion that was expressed, I'm still not convinced it was "disingenuous on purpose", as it may very well be a sincere/candid opinion of the OP. I can only leave that for the OP to comment on.
Just because a fix is available today doesn't mean an old Nexus will get it.
As for agenda, as a consumer and developer, I want a device where I am able to use the same Java libraries as on a regular Java and get updates as on any of my computers without having to pay more than a month salary for such time limited privilege.
Personally, I place all the blame on Google for not making the upgrades possible from their side. It should be easy to upgrade the core operating system as easy as updating Windows, OSX, and Linux.
This makes no sense. "People associate X with Y" is not the same as "Y is responsible for X". If I associate Android with Linux, is Linus now culpable for Android's security problems?
> Personally, I place all the blame on Google for not making the upgrades possible from their side. It should be easy to upgrade the core operating system as easy as updating Windows, OSX, and Linux.
If we were living in a fantasy land where you could wave a wand and things would happen instantly, this would be the case, but mobile devices are not desktops and the challenges they face are entirely different. Google has already been moving logic as much as possible into apps like Google Play Services (updateable without OS changes_, and the fact that they haven't moved everything should make all but the most technically illiterate think "There may be technical challenges involved", instead of your "They're not making this easy" approach.
I understand that, but many of the non-tech savvy people I know do not understand that Google is not responsible for most versions of Android that run on their phones.
> ...but mobile devices are not desktops and the challenges they face are entirely different.
I do not see how they are much different. To many people, their phone is just as important as their desktop/laptop. I do not see anything stopping updates to Android being invisible to the end use as most other updates. iOS is pretty good about updating in a way that is unobtrusive to the user and Windows 10 is getting closer.
It should have been called a "platform", and, since Google has the ability to say so, they should have told each hardware maker to come up with an OS name "on Android". Tizen on Android. NexusOS on Android. So on.
OR, they should have gone Apple and said "you will have this OS, Android, and it will look as such, and it will be patched as such".
This is ridiculous. Linus in Android is a component, not a whole system, and phone vendor own SW are way too accessory in the ecosystem and add so little value in it that they don't render Android a mere component in the same way: the base Android is the system, whereas drivers and 3rd party GUI or other minor stuff are what should be sufficiently decoupled so that Android can be updated without vendor consent.
Doing otherwise has proven to expose users at risk, and given its situation Google is responsible, not a swarn of phone vendors.
I might not be saying that if Android was really open, but then Android might not have that market share. Well, in the end, even that reinforce the argument that Google is responsible...
For most people a computer, a phone, or a tablet is an appliance.
We are getting closer to the point where being secure and up to date is almost painless. That should be our goal in the tech industry.
Also, they could isolate the Java VM layer further such that it could be updated independently of the Linux kernel and related userland.
Google would like you to blame the manufacturer, but you need to realize the fact that you even can blame the manufacturer is a design flaw in the OS which Google designed.
>Google would like you to blame the manufacturer, but you need to realize the fact that you even can blame the manufacturer is a design flaw in the OS which Google designed.
This sentence makes so sense. Google cannot update an OS that they did not create. The OEM rolled the OS so only they can update it. How exactly does Google update an OS from an OEM they don't even have the source for? It's the OEM's responsibility and if that OEM doesn't do their job in updating their OS then maybe it's time to start looking for an OEM that does do their job.
2. Google created the OS. In fact, OEMs are forbidden from forking Android, and therefore, cannot "roll their own OS" from Android, without violating their agreement with Google. Yes, they sprinkle some of their own apps and drivers in, but this is a design flaw in Android: Google needs to be updating their own software independently of manufacturer-specific components.
I know for a fact you and I have had this discussion before.
[1]Someone will mention the Kindle. The Kindle does not compete with Google products, as it is perceived in the market as an e-reader more than a "tablet". And Google barely even does tablets anymore anyways.
Forbidden from forking Android? Every OEM version of Android is a fork. What Google does not allow is for an OEM to distribute a version of Android that does not pass the Android Compatibility Test Suite.
>therefore, cannot "roll their own OS" from Android
Do you know how OEM's "roll their own OS"? They take the AOSP source code that Google drops and then they add all of their source code and then build and distribute their own version of Android that only they can update.
>Yes, they sprinkle some of their own apps and drivers
I'm not sure you really understand all of the changes OEM's make to Android if all you think they do is "sprinkle some of their own apps and drivers in"
>this is a design flaw in Android: Google needs to be updating their own software independently of manufacturer-specific components.
No it's not. Google does not build Android for the OEM's. They create their own version of Android and therefore are ultimately responsible for updating it. Once again, Google cannot update an OS they did not build.
>Google barely even does tablets anymore anyways.
Android is still the marketshare leader in tablets.
Yep that's a insanely huge design flaw, coherent with: "Google needs to be updating their own software independently of manufacturer-specific components."
Is Debian also responsible for Ubuntu's security flaws?
Why do we fault the company for taking steps to pull Android as a brand together?
Google uses their agreements with OEMs to force them to bundle apps and including Google's branding, and protect their business, but refuses to use those agreements to ensure even basic security for their users.
Because we already lived in that world, and it was less secure than the one we live in now, to my memory. Security issue in one of the Android libraries that are now part of Play Services? Good luck; wait for your OEM to update your OS.
What would make a phone hardware able to install anything that compiles to its CPU architecture the same way a PC can?
Stable binary driver ABI. Hardware monoculture. Expensive driver certification program. Letting hardware vendors release binary drivers without releasing the corresponding sources. An opt-out automatic update mechanism.
(Disclaimer: I work at Google, but not on the Android team.)
However, to say that HW interfaces on the PC have been stable since the age of IBM PC clones is a joke. In the DOS days, users manually had to manually set IO memory addresses and IRQ levels. Early Windows sat on top of DOS, so still had to do it there. Plug'n'Play didn't show up until Windows 95, and even then it was hit and miss. Some devices worked, others required manual configuration. RTM Win95 didn't support USB, either. That took the equivalent of a service pack (although, IIRC, they went by a different name back then. I want to say OSR1 added USB 1.1 support). Windows drivers didn't really get friendlier until the push to the NT kernel & it's HAL. Win2k had limited, but good support. WinXP got better. Vista was a step backwards. Win7, 8 and 10 have incrementally improved on Vista. Even on Windows 10, though, I have updates that "forget" a subset of my USB controllers. Windows doesn't know about drivers for my HOTAS. Most recent windows updates cause it to forget about my secondary monitor. Half the time after an update, my USB keyboard doesn't work (I have to login on my desktop using an on-screen keyboard to correct settings). I'm probably one of the only (or a small handful) of people that have a Geforce 690 & 1080 in the same system. Sure, PC might be better in that most peripherals go over USB. But, not all USB devices work with a generic driver, and Windows often doesn't include non-generic drivers for all but the most popular devices.
The core system of PC is highly compatible with OSes in pretty much all directions. (Well now even if I don't ignore the non-PNP ISA configurations stuffs, it does not really change the situation: those were not for core system stuffs)
Then you have drivers for various bus controllers and peripheral, some of which are crucial for using your PC in practice, but as soon as the necessary driver exists, loaded by the kernel way after the core boot, and highly abstracted on all modern OSes (it only access the HW through functions abstracted by the OS)
For non-ancient PC, you even have with ACPI some abstracted functions, provided by the HW, and used at the runtime by the OS. It's to be considered as part of the core plateform, as if it was a pure HW interface, given what we are discussing about. The NT HAL, btw, is a vestigial of early NT years, and is of zero interest for the purpose of PC compatibility today (there is only one HAL that is in use on modern PCs, and IIRC switching the HAL was not even enough when multiple were in use IIRC, other MS binaries still needed to be recompiled -- so the NT HAL is merely an internal detail that bring no consequence in backward or fw compat as far as decoupling of binaries and their update of a partial subset in a system is concerned)
Now the situation for ARM SoC for Android is NOT the same. You just don't boot a generic ARM Linux kernel to driver your random ARM SoC of your random phone. Because even what could constitute an equivalent core system as what exists for PC, follows no standard.
The kids today don't know how easy things are with unified drivers for audio on Mac OS etc. I mean, even USB coming out was amazing instead of serial devices and guessing the COM port? Which LPT1?? And dial up etc etc so easy now.
With PCI and later the OS can ask each device on the bus to ID itself and thus figure out if it is a known device type or not (and if not, ask the admin to install drivers).
On ARM You have things sitting off various buses that expect the kernel to know what they are and how to talk to them from the word go.
It has gotten better as now there exist something known as a device tree that can be read by the kernel at boot. But not every SoC provide support.
Heck, if you crack open the ARM based Windows RT tablets you will find quite the odd duck of an ARM SoC inside. One more reminiscent of a x86 PC than what you find in your average Android device.
IMO the key point out of the things you mentioned is the hardware monoculture, because that definitely does help people get Linux running (and keep it running) on new hardware. I'm skeptical about most of the others.
But the reason I brought it up is that Fuchsia OS will have a stable driver ABI.
I get Windows security updates on every damn computer I buy. Yes, the computer is pre-loaded with bloat, but I still get updates like everyone else.
Meanwhile, on Android, I mostly get nothing. What is so fundamentally different between PC and phone? Why is it so hard on mobile phones?
But it's still Windows.
I just wonder why that is. Maybe Microsoft has stricter licensing?
The reason your question is "stupid" is because you think your phone is just one computer.
In fact, you can do just what you describe - and it wouldn't be that difficult - but it would only be for the application processor and you would end up with a nice PDA.
In order to make phone calls you would also need to control the other two, fully functional, general purpose computers inside of your phone: the baseband processor and the SIM card.
Currently, there is no way for you to control either of those in any meaningful way.[1]
There are deeply entrenched economic and technical forces standing in the way of controlling your own baseband processor and we are nowhere near to doing it.
[1] Osmocom on 2G phones is not meaningful, no matter how impressive and interesting it is.
They update just fine, sometimes even on the major versions. E.g. my phone initially had windows phone 8.1 and now it’s windows mobile 10. And despite the phone is 3 years old, I'm still regularly getting OS updates.
That’s why I don’t believe ARM hardware is responsible.
This is why things like SBSA (https://en.wikipedia.org/wiki/Server_Base_System_Architectur...) were needed before ARM servers could even be talked about, and why things like Rasberry PI's are not directly compatible with BeagleBones, etc, at least for the low-level stuff..
Nothing to do with ARM itself; just lack of ARM standards.
This was similar in the early PC days and had similar headaches - compare the various CP/M machines with what became the 'standard' MS-DOS/IBM-PC 'platform'..
Then they mandated secure boot with keys that cannot be controlled by the user, so that other systems can not leverage the platform on W10M hw :p . (That's in the spirit of what BG wanted for ACPI: something somehow incompatible with other OSes -- MS eventually managed to do this with a sidestep, but well, this did not really help their market share :P )
The The PocketPC and Windows Mobile situation was not much different from the Android situation today, i believe.
- Android breaks compat with old drivers every update - HW makers only ship (often vulnerable) binary blobs.
(And device manufacturers do this too, but it's a ton easier to, say, fix flash with a shim than it is to fix networking.)
Qualcomm (by far the most popular hardware vendor for Android devices) doesn't care about supporting their released hardware.
Quite often these days when a part is initialized, the driver uploads firmware as part of that.
If you look at most Linux distros they have a package of firmwares that various companies have allowed to be distributed with the kernel.
Meaning there is a small part of the Qualcomm blob that needs to interface with the kernel to upload the firmware.
And the interface changes as the kernel changes. This because Linux devs don't want the hassle of trying to debug a kernel panic only to find that it is happening inside a third party blob, and thus they can't fix it. Instead they want companies to either work with them to maintain drivers or hand them the information needed to maintain a open driver within the kernel source.
Linux and its wide adoption, the ability of users to pick and choose hardware and software would simply not have been possible if Microsoft and Intel took the Google-ARM model to 'openness'.
Google and ARM pay lip sync to open source but users are locked tightly to their devices and OS. Users cannot even install updates let alone things like Linux which Android is based on.
The drivers work perfectly on Android yet users trying to install Linux on ARM socs cannot use these drivers? Open source developers struggle for years with ARM and Google with no results. How exactly did this come to pass without by design? There can always be myriad 'reasons' and excuses but the fact is ARM completely controls the hardware and Google completely controls the software and it's their design and decisions that drives net negative results for users and open source.
As a poweruser, I have installed new versions of Windows AND new versions of Android.
To the average user, neither is feasible.
To a technical user, both are possible.
I don't like this comparison. Many of us switch out AndroidOS's very frequently. It's actually not hard at all to install a custom recovery and load a different and custom version of android.
In fact, considering how defined the android ecosystem of alternative OS's is, and how undefined the Microsoft one is, one could easily suggest that Android is far less locked down.
After all, some Android replacements like Cyanogen/Lineage are far more developed and popular than Windows replacements.
1. Insert install disc/USB. 2. Boot to install disc. 3. Spam the next button.
Installing new Android OS versions manually often involves custom third party unlock tools from sketchy download sites.
I worked in a Computer Repair shop for years through college and believe me, the average user has ZERO interest in installing or re-installing an OS. They will pay >$100 to have someone "spam next a few times" as you put it.
I would call that a distinction without a difference. End result is the same: non-technical users do not do it.
You are looking at the past with rose-tinted glasses, or you got very lucky with drivers. New drivers were required for every new Windows version from Win 2000 to Windows 7,even for the display (or if you are unlucky, Ethernet). The only way to get those drivers was via support from the vendor. I distinctly recall trawling dodgy 4th party driver aggregation websites, downloading and burning them to CDs in internet cafes multiple times.
Maybe it's related to browsing habits? IE? I mean, you aren't going to get hit by a drive-by attack on any major websites -- even in the heyday of malicious advertisements.
So, what I'm really asking is: where did this metric come from, and why does it get spread so often?
I witnessed this myself back in the day. I was probably about 14 at the time, had just freshly reinstalled a machine, installed AV (from a CD, hah.) and connected it to the internet for the first time via PPPoE DSL. Within minutes I had AV popups from having been hit by Blaster before I could even update Windows. In that day, few people had routers or WiFi, many, my family included just had a single machine connected to a modem directly and so had no NAT.
It was never individual attackers - it was worms running on other systems that had reached critical mass and were just hitting random IPs on the internet with the exploit in an attempt to infect more systems.
You're extremely unlikely to see something this bad with a modern OS - most of the time you're behind a NAT, provided by your router or your mobile provider which effectively blocks inbound connections. There's also exploit mitigations like NX and ASLR which are pretty much how the Stagefright bug didn't turn into a nice new MMS worm - it just sounded scary, but over a year later we've not seen any major attacks from it.
If you plug directly into the internet or DMZ your machine, you'll still see this type of stuff. I've heard it called "internet background radiation" - old worms out scanning for possible targets to this day.
You could check how frequent the attacks were by yourself. I was using a custom firewall software, called ZoneAlarm, to see how many attacks I was receiving in a day. The log said literally every few minutes, the infectious Blaster worm packet was received. It was like how frequent your SSH server is attacked with random passwords - you can see this from the SSH server log too.
Why did you turn it on in the first place?
Windows even included a utility to let people use it as a router on home networks to "share internet connections". https://support.microsoft.com/en-us/help/310563/description-...
https://en.wikipedia.org/wiki/Blaster_(computer_worm)
At the peek couple of months your computer would BSOD _during_ installation process, right after initializing network interface and RPC service.
I had a single device and had to do a fresh install from factory settings. This meant I had about 30 mins before my 500kbps connection would grind to a crippling halt from all the accumulated malware.
This meant I had to incrementally procure protection, save it, then fresh install and repeat until I could access the Internet safely.
I don't miss those days.
Two minutes is probably too short, but an hour? Maybe not.
You will see random scanning attempts within minutes. Same principle , minus the effectiveness.
Today, yes. But back in those days? I'm not so sure. IIRC, almost everyone had a public IP.
At the peak it got so bad that IPSs were blocking affected ports on all consumer connections just to save bandwidth.
You could basically do "NET SEND 12.34.56.78 my spam message" and it would appear on the screen of your victim.
And i don't think the problem is so much that people do not value security, but that they approach a computer like it is an appliance. Meaning that they do not internalize that it can do things without them being physically present and setting things in motion (i find it unnerving that Windows 10 can apparently bring a laptop out of shutdown to do updates in the middle of the night, thanks to programmable timers embedded in the BIOS/UEFI).
I really wish that a modern PC got more "blinkenlights" not less (i hate helping my mom with her laptop, as the damn thing do not even have a HDD activity light).
Heh, I remember when Apple used that as a feature. Instead of updates, it downloaded your email and other things you'd want to have already available when you open your laptop.
Also, macOS does not force a system update schedule on you, unlike Windows 10 Home.
My work laptop and one or two of my private machines have no HDD light, either. It drives me crazy.
For Windows, there is a tool called HD Activity Indicator. It only works after logging in, obviously, but still better than nothing.
It does, but it's also operating in a much more hostile environment. At least windows had regular updates though, that's not the case for most android phones.
And more competition in the h/w space? Common, you already have an insane amount of competition for Android phones, and even some of the biggest multinational don't give a shit about maintaining SW for their product beyond a few months, even for security purposes. The only think we can do is prescription to every people we know: ex. tell all your non technical friends to never buy e.g. a Samsung phone.
It's ridiculous, because Android is the worse ecosystem for security purposes. If you want to be somehow protected, you can stick to iPhones, or, in a funny way, Windows 10 Mobile.
That competition is only on the surface. For SoC, GPU, baseband, radios etc., you are stuck with Qualcomm. Or maybe Samsung's exynos, which isn't necessarily better.
And then on PC too, you pretty much only have competition on the surface; then it's Intel and AMD. Given how modern CPU are SOC (and chipsets are now paired with CPUs, and with no 3rd party licence anymore), you have almost all of what matter in your system (for system compat) there...
Google uses Linux within Android but instead of allowing the underlying parts to be updated via package management-like functionality, the kernel level stuff is only distributable as images in one "big bang" go.
You could have a bug in a single binary at the kernel level, but instead of a tiny 1Kb diff patch you wait a year for a giant 1.2 GB vendor update that also contains a lot of other changes you have no interest in.
Only with Windows 10 Mobile they engineered a strong way to upgrade the OS without needing vendor intervention too much (or at all?), it is a shame Windows Mobile market share as fallen so low and Windows Mobile is not even a priority of MS anymore :/
On Linux side, some (most?) phone vendors are most of the time not supposed to distribute the kernel and their binary-only driver the way they do it, because most of those distributions are likely GPL violations. The sad thing is some high profile organisations (Linux Fondation comes to mind) don't give a fuck about licence compliance, which is insane given the technical side NEEDS licence compliance in order for the end result to work well and not be dangerous for end-users for a large part of the ecosystem. (Worse, the Linux Fondation happily accept obvious GPL infringers at the highest levels.)
Anyway the kernel part is a small part in an Android distribution, and I'm not sure anything is available to handle the security update problem, or that somebody is even working on it... The technical update model MS has chosen is the way to go and Google is endangering us all by having such a huge market share and not wanting to take any responsibility that should come with it. (It's even worse given how Android has reached this market share levels, using practices that would make look past MS ones as respectful of competition!)
Linux has a driver API; the interfaces are not as stable as windows but they are there - the vendor shoehornning has more to do with closed hardware blobs, drivers not being developed in the open, and profits than a few struct member tweaks here and there shifting across android releases..
the handset manufacturers have no profit incentive to ensure that the phones are compatible for a longer term, and keeping the hardware drivers closed/behind version-specific blobs serves as convenient way to facilitate planned obsolescence
plenty of windows hardware doesn't get new drivers across OS release boundaries for the same reasons so slightly better API stability is not really a very good argument here on its own..
Example: https://arstechnica.com/security/2016/12/fedora-and-ubuntu-0...
Android on the other hand, has isolation mechanism built in as the central thesis of its apps system. Additionally, it also has some additional layers on top.
Unfortunately since nothing gets updated it maybe all moot, but I don't think somehow Linux distros are more secure.
Arguably the security model of main desktop OSes is bad enough so that they are also easy to penetrate. That should not make us dismiss the problem of the way too many unmaintained Android systems!
But the entire system as a whole doesn't get updates to lower parts. E.g. Updating your java app doesn't solve the problems in the underlying C libraries the system uses. We're at the mercy of vendors for that, if ever.
Wouldn't this require phones to compile their own kernels?
Security patches are not 1+ GB in size - no where close to it. You're referring to OS updates that completely replace the old OS.
Is Linus Torvalds criticized as strongly as this, when many of the hundreds of Linux distro maintainers fail to ship kernel security patches speedily? No? Google puts a lot of effort into securing Android and patching vulns quickly, but ultimately it is the fault of the MANUFACTURERS and OPERATORS for failing to update their commercial works derived from Android OS.
You don't have 1000 toolbar crippling your mama's android browser.
I never had to reformat my mobile to "make a clean" install, and certainly not every 6 month like I used to do with windows.
We never had any large scale infection on Android like confiker.
Reports of anything bad, virus, worms, rootkits... happening on Android are incredibly rare and never happened with my relatives.
Clearly we can't hold Google to the same standard as MS, because they are not even on the same level.
I'm wondering what blog posts on the Project Zero blog you consider to be "cheap muck"? There are a lot of posts on the Project Zero blog about Android as well.
[0] https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...
On the manufacturing side, a huge team is assembled with piles of money and resources to design and build a complete product out of hardware, firmware (blobs), and software, test it, document it, and then hand it off to marketing. That entire team is disbanded into a pool from which a whole new team will be created for a whole new product. Maybe less than a dozen people remain on a product team following release, and that's just to cover major bugs found once it's in the field. After about 6 months, it might be a team of two people. If it's a small market product, it might be a team of handful that cover multiple similar products.
Anyway, after 18-24 months there's essentially no one around from the manufacturer to support the product. It's not at all the same business model as say, Apple, where it's a giant team supporting a dozen handsets post-release, with coordinated roll outs for bug fixes.
If you want a newer OS on the Android phone, it's a do it yourself proposition. Lineage OS. Hopefully your phone has a relatively easy to unlock bootloader. And while Lineage OS will have a much newer kernel than the stock OS, the code to support, e.g. the NFC, may not be upstream because it's got some patent encumbered code, or maybe something new in the kernel breaks some driver and no one is around who knows enough about it to get it fixed. The exact sequence to put components into low power state, if not correct can cause battery life to suck. There are all sorts of ways this can not work out well, but at least it's an option.
What Google has done since Android 5 is emphasize library stability and security through Google Play updates. New features and bug fixes happen via Google Play itself being updated; it appears to be just an app update but it's actually what the bulk of 3rd party apps use. The low level stuff including the kernel isn't user space, and while your handset gets stuck for life, in effect, with an old kernel, Google are pushing out a chunk of bug and security fixes this way.
On Google devices starting with the Nexus 5X/6P, there's a separate /vendor partition for blobs, and Google publishes monthly updates for that. I'm not sure if other vendors do this…
What are the worst 2017 android malware doing to the world?
Taking over a machine thanks to autorun.inf, crashing machines with ping, unsecured shared folders, worms spreading everywhere, rendering fonts on kernel code, and a long list of other stupid defects... No. Android has never included this level of idiocy therefore it is not fair to hold it to the same standard.
Installing Windows was once the same as installing a rootkit in your computer. Android might have issues but never as bad as Windows. Windows holds all the incompetency records.
Then, "the operating system released 16 years ago" (Windows XP) is the 3rd most used operating system. It is still causing problems today.
What? That is complete nonsense. Yes Windows security has improved over time but it's still pretty abysmal compared to macOS, iOS, Android and any mainstream Linux distro. Windows still defaults to your main user being an administrator with administrator privileges at all times.
Not to mention the fact that Windows now comes baked in with malware and not only defaults you into turning it on without giving you the option to turn it all off easily during setup, but the major patches that have come out since will re-enable a lot of Microsoft's tracking code and make you jump through hoops to disable it.
The triggering factor for this was the worms though. No such similar thing exists in the Android space.
There clearly hasn't been any major deployment of this - especially at the scale of Blaster or Conficker.
It's "trivial" perhaps for a single device but every device is different and it'd require its own exploit code, exploit mitigation features cause it to be difficult to actually exploit too - making it quite problematic to deploy in practice.
It's not trivial - there's a lot of devices and exploiting mitigation techniques to deal with, there's not even a reliable PoC that works on real-world devices with ASLR enabled.
These exploit mitigation techniques and differences in builds have basically saved it from becoming the disaster it sounds like at first glance.
I guess to answer your question, yes, yes we are that moronic. Not many people will care unless it's proven rapidly and readily exploitable.
It's been about 2 years since Stagefright was disclosed. Are we still waiting for it to explode? And if so, can you give a timeline for when this explosion will occur?
No it's not. Where are all of the Stagefright exploits? This was supposed to be Android's security armageddon according to the scaremongering bloggers. And yet nothing happened. According to Google's telemetry of over 1.4 billion phones there has not been 1 case of a Stagefright exploit in the wild. So your assumption that Stagefright is "trivially weaponizable" is inconsistent with your knowledge of Android security and mitigations.
The only texts I ever recieve nowadays are automated (2FA etc...). Even though unlimited texts come with every SIM.
SMS has remained the great constant throughout all these games. Turns out people don't get in touch if you don't use WhatsApp but shows how much they care eh!
Yes, because it's better to let hackers continue to exploit Windows than inform users and MS that their OS is at risk.
>You've got an even bigger and more complicated mess to clean up, you dug the hole yourself, it's going to take you longer, and you should have started on it years ago.
Security patches are given to OEM's 1 month before they are publicly released. Google patches their devices promptly. Unless I'm mistaken, I'm not aware of technology that allows Google to take an OEM's source code, apply patches, build it, sign it and then release it to all of the OEM's customers.
https://android-developers.googleblog.com/2017/03/android-se...
Apparently now all OEMs are playing nice with updates and everyone that bought a phone in 2016 got their updates.
Meanwhile according to the same stats, Android sits around 37.9%, and I have to wonder just how many of those devices are still impacted by for example the 2015 libstagefright vulnerability. Given Google's guiltless ongoing "throw code over the wall" approach to security and passing the buck on to vendors who almost never ship firmware updates for old handsets, perhaps now is the time for us to begin holding Google to the same standard we applied to Microsoft a decade ago.
Google Security Team, here's your call to stop pontificating on the Project Zero blog and throwing cheap muck at Microsoft. You've got an even bigger and more complicated mess to clean up, you dug the hole yourself, it's going to take you longer, and you should have started on it years ago
edit: If it weren't clear, the tragedy here is that instead of most devices being governed by a well-tested security process owned by a single responsible vendor, they're at the mercy of a plethora of downstream vendors who do nothing, with the ultimate upstream washing its hands and paying little more than immature lip service to the issue, never mind having anything that even remotely resembles a solid process.