If you want a phone with top-notch security, buy a Google phone which is guaranteed, by Google, to come with 3 years of monthly security updates.
If you want a phone with top-notch security, buy a Google phone which is guaranteed, by Google, to come with 3 years of monthly security updates.
I find it amazing that supporting a $1000 phone for 3 years is considered excellent. It's not very sustainable to make several billion new smartphones every 3 years...
But I agree that $500+ phones (Google AND Apple) should IMHO be security-supported for 5 years. It would be better for all of us.
A 128GB Pixel XL with device protection is $968 US before tax and still has the same 3 year support as the entry level Pixel.
The fact is Google sells a $1000 phone with 3 years of support. They also sell less expensive variants with 3 years of support.
If you buy a phone that you know is already going to be obsoleted soon (it's not like Apple makes its release schedule a mystery), you should assume it will have less support than the latest model.
When phone vendors releases a phone, they can deposit the vendors custom binaries/source in google servers.
Google will maintain and release security updates for vendors for X number of years for Y amount of $$$/Year.
The phone vendors can snap a "Android Security Update Guarantee by Google until year ZZZZ" logo/label on the phone.
In a plateauing market where more customers buy their own phones, it could be a differentiating factor. As an iPhone user I buy an unlocked phone every 3 years or so, updates are therefore important to me -- but clearly not to enough of the Android market right now.
Right now, I'm on a Nexus 5x that works on Verizon while not officially supported. Verizon network, without the Verizon crapware and retarded (as in, delayed or never delivered) security updates. I might move to the Pixel 2, when it comes out. Even then, I'll buy it directly from Google and forego the Verizon crapware-and-delay leash.
Samsung seems to have a renewed commitment to timely updates, and the moxie to pressure U.S. carriers to pass them on -- somewhat.
Other than that, I'd advise most of my friends to stay away from Android on U.S. carriers. It continues to be a shitstorm. My friends with Apple remain mostly simply happy and unstressed. I'm not particularly fond of "walled gardens." But for a lot of people, it's "just a phone" and they want it to "just work."
My point regarding Google itself: They bought Motorola and had Motorola thence promising timely updates for a reasonable period of time. Didn't happen.
I trust Google to do what it perceives to be in its best interest. Including updating its own phones for PR reasons. Beyond that, just like the newer products they launch or buy and then often kill a year later, it's a crapshoot.
P.S. Like others are expressing, Google's a big place with many pieces. As to the topic of the OP, I'm glad Project Zero continues to have support and is doing what it's doing. And that it has the muscle and inertia of Google behind it, to weather the political and legal shitstorm attendant with the mess that is is IS/IT security, these days.
Basically, it allows all the running .exe programs signatures be checked at once with 56+ virus checking websites and results shows up in the GUI of procexp.
No wasting of CPU cycles to scan every files in the system, typical < 3 seconds to check all the running programs - Light up green/red in GUI.
https://www.youtube.com/watch?v=RnPtuTbqzd4&t=3s
Love to see google do something similar to this in Android.
It is very trivial for Google to dev, deploy these kind of tools/REST API/website. If this is deploy in billions + Android phones, Google should be able to detected/collected/analyze new/potential malwares instantly.
Known good programs with valid signatures - do nothing.
Unknown programs sig - setup special container and monitors app behavior - collect the binaries if needed.
Also, I think google should be able to separate the Google control portions of AOSP from the 3rd party vendors systems drivers/utilities and allow them to be upgrade separately.
I used to work on porting the AOSP on cell/tablet SOC before. It is doable.
THis sounds good, but it can take much less than 3 seconds to compromise user-space data and ship it off.
And thereby lose access to the Play Store?
Amazon would probably let them use their store though...
Samsung alone has more market share (by device) than Apple.[1] Samsung could probably do it, but it would be bumpy.
> Amazon would probably let them use their store though...
Maybe not without major concessions. Amazon subsidizes a lot of apps in their store because of their add serving architecture.
It might come though http://www.androidpolice.com/2017/02/06/no-really-this-time-...
Yes, this won't be "open-source", but it will be open enough, in that you can still read the source code, modify it, ship a phone without Google's permission, and so on.
The free for all model we have isn't working.
Google gets away with this because it is "free", so the refrain is "you can't complain if it's free". Google could go the same route Microsoft did, but it chooses not to.
Phone manufacturers would be happy to have binary blob updates for free - but it would never happen. Google would have to custom-build, test, and certify every binary blob for every piece of hardware, which is an unjustifiable cost.
If you want a phone with top-notch security, buy an Apple phone. They're supported longer, they fix their security bugs promptly, and they honestly have a better model for their OS anyway. (disclaimer: I hate Apple)
In general yes, but not always. Security updates may stop as soon as 2 years after purchase: the iPhone 4S was discontinued on September 9, 2014, and the last iOS for it is 9.3.5 released on August 25, 2016.
So the iPhone 4S, which you use as an example of a lack of support, was supported for three years longer than the comparable Android.
By contrast the Galaxy Nexus support ended 3.5 years ago and is no longer representative of Google support's policy which is now longer.
so your statement that iphone gets more support than the equivalent nexus is spurious at best.
What? Double what? Microsoft doesn't require this because they don't require they have a stable driver ABI, so Microsoft can ship updates to Microsoft code without requiring that device manufacturers ship updated drivers to go with.
Either Android/Linux needs a stable driver ABI, or somehow (looking at you Google) the hardware vendors have to be convinced to release driver source.
Last weekend I installed the latest Debian on a Pentium II from 1997. What madness that I can't install the latest Android on a three year old phone?
Unfortunately I think this falls to Linus and the kernel developers.
The ARM portions of the kernel are a fucking dumpster fire of epic proportions.
Because every SoC vendor can bolt on different components, there is a truckload of one off code in the kernel to handle every variation of an SoC a vendor makes. Couple this with the fact that there are very few rules governing where and how vendors connect external devices via IO, and you have code for specific boards to ensure they work.
It's simply not maintainable. Many ARM boards ship with heavily patched kernels, which while having their source code released, will never be merged into the mainline kernel because of lack of effort by the manufacturer or simply the kludgy nature of the code offending the good senses of kernel developers.
Where Google can help is by preventing manufacturers from shipping a device with Android unless their kernel changes have been accepted to mainline Linux. This is the only way to ensure support for multiple years.
Actually, that will only help devices which have Google Play Services. Since Android is open source Chinese manufacturers can just release their own builds based off AOSP which don't include Google Play Services and then Google has absolutely no recourse.
The stagefright debacle didn't have anything to do with the kernel or Linux ABIs. libstagefight is Android's own userspace library.
Quadrooter was kind of related to ABIs in that it was inside Qualcomm's driver, but it would still have been trivial for vendors to just pop in a patched driver from Qualcomm and release a software update. They do all have systems ready for making software updates, since phones ~always get OTAs early in their lifetimes. A stable kernel ABI (so all vendors could have samed the same binary of the fixed driver) would not have made this significantly easier.
The main problem is lack of product liability cases due to lack of high profile really bad things happening (malicious worm epidemic etc). If consumers demanded (and won) their money back from phone vendors due to security incidents, diligence wrt updates would get written into contracts between operators, phone vendors, SoC providers etc and it would work.