The FCC absolutely must clamp down on EOL policies and security updates for phones. It's a telecom infrastructure issue. Sure it places a burden on companies like Google and Verizon, but they're the ones who deserve to carry that burden -- not consumers. The secure lifetime of a device that is hundreds of dollars should not be only 2-3 years. That leaves a dramatic number of consumers fully exposed and eliminates the secondary market for used technology.
Edit: Furthermore, if the companies are going to lock down devices and driver blobs so nobody else can fix them, all the more reason that the security of the device is their absolute responsibility.
Be careful what you wish for, this type of legislation may unintentionally prevent consumer level device modifications like rooting and custom roms which allow security researchers the ability to find these issues and basically restrict this to an NSA level of funding. If I were qualcomm that'd be my first response in order to minimize effort on my part.
Ideally Google would just produce a version that was more directly update-able.
Google needs to fix the broken AOSP model. I did a post about this a few months back (http://penguindreams.org/blog/android-fragmentation/), but the TL;DR is that Android needs to be a lot more like Windows: 1) Install the base, 2) install the drivers, you're done.
It's a little more difficult with embedded hardware, yes. But Google could create a standard source-package format and cross-compiling tool-chains to simplify this process. Or they could do something like the VESA standard for x86 to ensure you'd always have a display.
Google -> Manufacture -> Carrier is asinine. The first thing any power user does with a Windows laptop is wipe it, completely, and reinstall from his or her MSDN copy using the serial number from that laptop. Even non-power users still get all the standard Windows updates without any help from Dell, HP, etc (plus the bonus of bloat/spyware updates from said manufactures).
Even if Google didn't want to retroactively do this, they could start with Android O. It's not really in their advantage to, as it works out better for them if people have to buy new shit they don't need every two years to keep getting security updates.
First, a nitpick that the FCC makes regulation not legislation, and it could do this under existing authority. Second, I think a fine solution would be to force open the buildable source including all drivers and firmwares upon EOL. If top-down security updates will stop, then all components must be open source at that point.
All information required to build, package, and install; as well as a license for anyone using or working on affected hardware to the copyright and patents involved for use with affected devices.
Disagree. How about a simple "devices selling in excess of 500 units must have security devices updates provided for four years from the first date of sale"? Legislation doesn't have to be onerous.
Automobile manufacturers are required to produce parts for a certain number of years in support of their vehicles...
> How about a simple "devices selling in excess of 500 units must have security devices updates provided for four years from the first date of sale"? Legislation doesn't have to be onerous.
Even this is problematic, you still generate the a large incentive for the manufacturer to prevent reverse engineering of the device. If no one can find the exploits because the vulnerable firmware is not readable, the drivers are heavily obfuscated, etc, then they don't have to provide any updates and only dedicated actors with access to funds will have any chance at success.
In order to prevent this you may have to make the legislation _more_ onerous and require the manufacturer releases to the owners the ability to sign updates and reverse engineer the device. Something like this needs very careful consideration not to create perverse incentives and to maintain competition and pricing.
How frequently? What constitutes a security upgrade?
Who defines what types of bugs qualify?
Can I release an annual patch for 2 super-huge bugs (let's say kernel-level RCE) found in the 18-to-6 months prior to the patch release, and ignore data leakage bugs in that time frame as well as a kernel-RCE that was found only 3 months before my release and still remain compliant?
That's if the only goal is "security". But we're talking about updates here. I don't think updates and user flexibility are mutually exclusive.
If you do modify your device in a way that it can't be guaranteed that the updates will secure the device anymore (which shouldn't be an issue for the vast majority of user modifications), then you simply lose that "warranty" for updates, or the company is no longer responsible to keep you up to date.
But there are ways in which Google and OEMs can guarantee that for instance an OS image that's clean always resides on a locked-down partition, and that users can always "restore" their devices from that, no matter what other ROMs and whatnot they install on their devices and how many times they unlock the bootloader. The only exception to that may be people that tinker with the lock-down restoration partition as well, but for most custom ROM users that shouldn't be an issue.
So this way 99.9% of the users can still be guaranteed updates, if they want them.
> If you do modify your device in a way that it can't be guaranteed that the updates will secure the device anymore (which shouldn't be an issue for the vast majority of user modifications), then you simply lose that "warranty" for updates, or the company is no longer responsible to keep you up to date.
I'm not saying that the updates must work on modified devices, I'm more saying that the incentive changes to preventing reverse engineering so that exploits don't happen and updates don't need to happen. Preventing that sort of user level modification, combined with heavy obfuscation and locked down firmwares does prevent reverse engineering by most amateurs and many professionals without a near-unlimited budget. If you can't read the executable for the IPC service, you can't reverse engineer it and you can't find exploits in it.
I think qualcomm or anybody would have hard time justifying how rooting prevention (which actually already has some place) helps here.
I hope this trend also eventually brings us proper no-bullshit free and open-source firmware. As long as there are organizations to request some sanity from vendors.
I bought a 2013 Moto X in early 2014. A significant factor in my decision was "owned by Google" and a "promise" of "timely updates".
It was significantly less than two years before I was left on a vulnerable version of 5 with no further updates. Well before my two year "phone agreement" or whatever term ('it's not a "contract"') Verizon was then using, was up.
Because of a special deal, I'm on a Nexus 5x right now. (That Verizon does not officially support -- whatever...) But it may well be my last Android phone. I've no confidence left in the Andriod ecosystem.
I cringe more than a bit at Apple's "walled garden". But, at least they keep it up-to-date. And increasingly, I view the cell phone as a quasi-public medium. If I want true privacy for some aspect of communication, I simply have to take it out-of-band.
For the time being, I may also trust the likes of Signal (Whisper Systems). But most other parties I communicate with have no clue and no desire to get one.
Fortunately, three letter agencies and scammers don't seem to be too interested in my semi-disfunctional relationships. And I don't do banking, shopping, etc. on the thing nor use email accounts tied to same.
The problem you have is with Verizon and their pathetically delayed updates. They do it to tease their impatient customers into new phones with fresh contracts. Just switch to Cyanogen and get your Nougaty goodness today without a middleman to screw you over.
And stop buying subsidized carrier phones in the first place. They need to disappear into the annals of history like landline phones owned by AT&T.
For some of my and my family's use when traveling, Verizon is the only non-local carrier to provide coverage.
Anyway, as I said, I don't trust the Android "ecosystem". Even if and when one can, sometimes with considerable time and effort, find local maxima within it, it overall just sucks in this respect.
By contrast, even on Verizon, Apple has the muscle to tell them to fuck off and to push updates directly. On Verizon, buy an iPhone and you stay as up-to-date as everyone else.
Jesus, can we not encourage this? Getting the FCC to more tightly regulate phones will have two primary effects: 1. No more open source phones. We'll be even worse off than we are now. 2. Phone prices go up. Huge regulatory cost increases for little (or perhaps negative) gain.
Just because you think devices should be supported for longer doesn't mean you should try to use the government as a bludgeon to screw over poor people, security-oriented people (who don't want locked-down phones in the long run), and tinkerers/open source advocates.
A vastly better approach would be to require phones to be open source in the same way as gambling machines in the US. The code isn't entirely out in the open if the company doesn't want it to be, but anyone can audit it. In the case of phones, people could also fix bugs if they wanted to.
Elsewhere I've agreed with exactly this. The regulators will inevitably take action on this, and they should, but it's up to us to influence that outcome toward open devices. The device should either be pre-EOL with a process for security review or fully open or both. We want the company to take primary responsibility for the products they sell, obviously.
That being said, the FCC is a little toothless, and every time they try and do something consumer friendly the courts kick them in the shins.
More likely to see something positive come out of the EU than FCC, but in either case these companies will make changes to all markets because it is more efficient than just doing the EU.
Android in particular could learn a lot from Linux's distribution model (package managers, et al). I've been tempted to move to iOS just because of how much better updates and device lifespan are.
At a smaller scale, California or perhaps Massachusetts could do this independently -- as they often do -- and it will have the effect of reverberating across the country.
If the OEMs are choosing to sign off on the OS and be the gatekeeper for core system updates, then they effectively own the security flaws and they should be held responsible for defects in their product. To me, this is a consumer protection issue.
While i like the idea and most of the others here i think a more practical approach would be to force a labeling requirement for the guaranteed time span a device will get timely security updates.
This way it becomes part of the specs manufactures try to be competitive on and therefore creates an incentive to let that number go up. It would be clear from the start what is the lifespan i could expect of the device and makes me able to better understand price advantages which now are often hidden or not exposed.
Maybe a mix of both would work best. Like right now in the EU they are considering making software updates mandatory for all devices for as long as the warranty exists (which is 2+ years for all electronics).
Maybe do that, too, in the U.S., and then do something like "We guarantee warranty period +1/+2/+5 years of updates."
Smartphones aren't even the devices with the longest lifecycle. Think about all of the "smart TVs" and "smart fridges" out there that people want to use for 10+ years, but they may never get a single update. Something definitely needs to do be about this regulatory wise, and it needs to happen soon before we're already surrounded by dozens of smart electronics everywhere we go, and not one of them had received a single updated after purchase.
I think either what you said needs to happen, or they need to unlock the devices before declaring them EOL so that the user is free to load something open source if they so choose...
Or, they could be nice, and allow it from the beginning... Like that's ever going to happen.
Google already updates their phones every month for three years which is long enough for a device most people replace or break within two years. Verizon isn't the only carrier of course.
Security updates need to be for the lifetime of the /device/ through all parties. Think of it the same way you would an airbag or break recall for a car.
Feature updates? Sure those can go away as the manufacturer feels like it (though they should be required to be upfront about this).
Who supplies security updates for the "lifetime" of their product in your fantasy world? Three years is a good amount of time for security updates but could be extended to four years since people are keeping their phones longer these days.
You are comparing software security updates to products recalled for safety issues? Well phones are already subject to recalls for hardware/battery problems. Let me know when a phone kills or hurts someone due to lack of security updates.
With replacement of consumable parts (mostly batteries), I would not be surprised to see current phones in use for 10+ years.
Just like desktop computers they will reach a point where, for most people, they're 'good enough', even if they're really slow.
For some people, particularly the elderly, the young, and the poor, they'll use it until it literally stops working at all because they literally cannot afford otherwise.
Cell phones are a literal lifeline device, to the point that emergency calls (at least in the US, and probably in any civilized part of the planet) //WILL// always work; without unlocking the phone, without the phone being on a payment plan, as long as the device has the power to transmit that distress need.
It is not difficult to imagine how issues with the security portion of the layer could allow anything from a computer virus to DDoS local infrastructure (jamming), to targeting specific individuals (lock out their ability to call for help, bug and track movement), to picking out individuals that are alone and in vulnerable moments. Those are attacks I thought of just typing this comment and are not an exhaustive list.
This is why the security updates either must be performed by the companies in question through the actual use lifetime of the device: not just by it's first owner, but all the way through to it's last. Or failing that, they should be required to both release the sources and provide everything necessary in a legal sense for other entities in the community to perform the security updates they are unwilling to do. Carriers should also be liable for failing to (offer to) distribute said security updates to devices on their network (it is in the interest of everyone that they do this and do not charge for it).
>With replacement of consumable parts (mostly batteries...
What? Most phones sold today do NOT have replaceable batteries.
>For some people, particularly the elderly, the young, and the poor, they'll use it until it literally stops working at all because they literally cannot afford otherwise.
One can get a new Android phone from Amazon for $50 no contract. Landlines still exist and are almost available anywhere unlike cell coverage.
>Cell phones are a literal lifeline device...
I could live with a dumb phone as my PC is way more important. When are we going to make Microsoft start to provide security updates to XP again?
You must be like 20 years old... I hate to break it to you but no one needs a cell phone to survive.
>This is why the security updates either must be performed by the companies in question through the actual use lifetime of the device...
Well start writing Congress but personally I don't want my new phone to be another $50 more because the OEM is required to provide security updates for phones 5 or more years old.
Define 'most phones' (Not being able to replace the battery is a problem in my world).
Buying a new (crappy, what do you expect for 50 Dollars?) phone because your perfectly working one isn't supported anymore is NOT satisfying and not a solution.
Windows XP is actually a very nice example. According to Wikipedia it came out in 2001 and got constant (you can complain about the quality or bring up other complaints) updates until 2014. It's rather amusing that you bring up Windows XP as a _counter argument_ to decent updates. Most phone manufacturers have a hard time updating their devices for 1.5 to 2 years, let alone 13.
I feel that you're a bit lost. You want to save a bit of money ($50 is your example) when you purchase a new device because if it's becoming vulnerable due to a crappy manufacturer/vendor you can always .. get a different one for the same price?
Ignoring that this doesn't make sense, you're also hurting the 'herd immunity'. This argument of yours is comparable to anti-vaccines discussions. "I want .." vs. "The general public would benefit if this would be the case". I know what Kirk and Spock would decide, but you're entitled to have a different opinion, of course.
>Define 'most phones' (Not being able to replace the battery is a problem in my world).
In my world too but most smartphones sold these days in fact do not have removable batteries by design. You don't know this?
>Buying a new (crappy, what do you expect for 50 Dollars?) phone because your perfectly working one isn't supported anymore is NOT satisfying and not a solution
That $50 phone is just as good or better than a phone sold 3 or 4 years ago.
>I feel that you're a bit lost. You want to save a bit of money
No dude... I buy a new phone every two years to have a faster one, better features (camera), and better security features (fingerprint reader). Lucky me, I can afford it. My secondary phone is a 2 1/2 year old Nexus 5 which still gets security updates and will for many more years via custom ROMs. Security updates were not the reason I bought a new phone.
Sorry, you don't really seem to be up on current smartphone technology to comment on this intelligently but philosophically I do agree with you.
Nexus 4, released in Oct 2012, is still better spec-wise in terms of screen and RAM than most $50 devices.
I picked up one on ebay for $AU80 and the battery is still okay but the non-replaceable feature the only thing keeping me from using it indefinitely. Although the supported OS is Google abandonware, so this vulnerability may finally encourage me to upgrade to a custom ROM.
(And yes I'm currently a thrifty student and happy to accept hand-me-downs rather than spend $500 on new bling)
That is not correct... You know I am taking about the $50 Amazon Blu and Moto Prime deals? Please look up their hardware specifications.
The Nexus 4 was a solid beautiful phone in it's time. It doesn't even officially support LTE and I can name 6 other specs were it comes up short compared to the Amazon Prime phones.
Google abandonware? Nexus devices get better official and unofficial support than any other Android OEM phones.
The iPhone 5, introduced in 2012, is getting iOS 10, which means security updates into 2015. That's a five-year span, which is much longer than the average person uses their iPhone 5.
iOS 9 supports the iPhone 4S and the iPad 2, which again is a five-year span (2011 to 2016).
I have devices that are that old; the iPad 3 I have just prompted me to update to the latest 9.3 update, and it's so slow running newer apps that I gave it to my toddler to play games on instead.
So I agree, three years is good, four years is better, but Apple is already at five years and has been for a while now.
Google loves when people blame OEMs and carriers for bad OS design. There's no reason a security flaw in Google's code needs to go through two layers of approval by other companies to be distributed in a costly OTA distribution method. Google should control the release of fixes to it's own code. If the operating system allows otherwise, the operating system is flawed.
Microsoft distributes security updates regardless of what OEM their software is installed on. With Windows 10, this is true of mobile as well. My two year old Verizon phone runs the latest official version of Windows 10 Mobile, released direct from Microsoft, at the same time as everyone else.
Android OEMs love it when people keep blaming Google for phones not being updated and as long as this happens this issue will never be addressed.
Do you know how open source works? Google has no control over OEM phones or the carrier approval process. Period!
The only reason OEM Windows phones can be upgraded is that OEMs agree to that level of control by Microsoft. Have you ever noticed their are few Windows phone OEMs? LOL Google could try to assert this kind of control on OEMs but Samsung would bail as soon as possible for sure. They would fork AOSP or move to their own OS.
Google can definitely control any phone that has Play Services installed since that requires a non-open-source license. I agree that Samsung would probably not agree to stricter control, but other OEMs probably would since they don't have any other realistic choice.
No! They absolutely can not! OS updates do not come via Play services... Why can't people understand that Android is open source? An Android OEM can (and does) modify their Android distribution anyway they like UNLIKE a Windows phone OEM. The fact is any OS update directly from Google would probably brick an OEM phone not that Google can unilaterally decide to update someone else's phone anyway.
I don't believe parent is saying updates come from Play, just that actually getting the approval to ship Play on your Android device requires signing an agreement with Google. That agreement provides the leverage that Google would need to enforce any policy of "updates for x years".
That don't have leverage... Google is already facing fines from the EU because of what they currently require from OEMs to use the Play Services. Trying to make OEMs accept Google updates is not in the cards.
It's far from clear if the EU complaints would apply to this, which have been strictly about anti-competitive behavior. Which competition would this negatively impact?
#facepalm Google has NO CONTROL over OEM phones. Sorry... Samsung would would fork AOSP tomorrow and create their own store. You think we have fragmentation now...
I don't know why you and others want to keep repeating yourself but that is not going to change anything. I have no idea what you said in your second sentence.
Android isn't open source. Samsung and other OEMs are only permitted to distribute it with proprietary closed source software. Therefore, the platform, as it's sold, is proprietary.
Furthermore, Samsung can't leave, Google has a backroom deal with them, it involves patents.
Not the GP: Android is NOT open source in my world. It's a code drop. It's what Microsoft used to do, before they discovered GH. "You'll get what we did after the fact".
Yes. AOSP is available as 'open source'. As a giant code drop, as far as I can tell. And the steering party for Android is .. that Ad company.
Even 'Nexus devices' aren't able to boot using AOSP last time I checked (Nexus 7, the ~newer~ version), so that is really bullshit. It looks like "Have fun with our current state, and really - nothing will work on your devices anyway because you need a ton of binary blobs matching our kernel".
Android is about as close to open source in my world as .Net was via 'the reference source' a couple years ago. "Source available" vs. "Open Source".
I actually can't produce this document. Google's contracts with OEMs are strictly confidential. Only some from way back in 2011 have leaked in their entirety. If you actually believe OEMs just get AOSP and get to do what you want, you don't know very much about Android.
Google gets to approve or veto every Android device every OEM sells. And that's just for starters. If you're an Android OEM that has access to the Play Store, Google has an incredible amount of control over your company.
Sorry, but the facts don't lie, even the linked contracts from back in 2011 gave Google veto powers over all device releases. You really have no idea how much control Google has over OEMs. Documents are linked above, please read them.
"The company shall not take any actions that may cause or result in the fragmentation of Android." under 2.2
"Unless otherwise approved by Google in writing Company will preload all Google Applications approved in the applicable Territory or Territories on each device." under 3.4
Yeah, five years later we still don't have a newer example of this deal, because Google is so secretive about how they control OEMs. They're under investigation for the behavior pretty much worldwide right now, but if you want to keep your head buried in the sand in the face of documents entered into official evidence in a court of law because it doesn't suit your narrative, go right ahead.
"Company shall not Launch any Device incorporating the Google Applications until it has obtained Google's approval as set forth in (a), (b), and (c) below.", see section 4.3
OEMs can't release an open source only Android distribution. WRONG Google must approve any OEM Android phone. WRONG Samsung can't produce a forked version of AOSP. WRONG
Your only proof about any of this is quoting a clause about Google apps? LOL Yes, OEMs can only use Play services if they include certain Google apps and they need to be presented in a certain way. I already said that many comments ago. The agreement stops say Samsung from using Google Maps but naming the icon Dumbfuck Maps. Google only approves the implementation of their apps NOT the phone.
Dude, go home. You don't know what you are talking about.
You can ship a phone running AOSP without any further agreement with Google.
You cannot ship an "Android" phone. "Android" is a trademark of Google and you can only use it with permission. Moreover, you cannot ship a phone that includes the Play Store or Google apps, nor one compatible with the increasing array of apps that require Play Services, unless you make an agreement with Google.
If you take away the name and ecosystem, you've lost the vast majority of the value of Android. Users will see your phone as if it is running its own, incompatible operating system. Why would they buy this? Why not buy a Windows phone instead?
Case in point: Amazon tried making a phone based on AOSP -- the Fire phone. They made their own apps, their own app store, etc. It was a flop. They gave up. If Amazon can't make it work, why would anyone else expect they can?
So, to realistically sell an Android phone, you have to make an agreement with Google. And that's how they keep control.
Although those security updates have been out for a year now, so technically Google doesn't update their phones for three years yet and we're yet to see this commitment happening. Based on their track record, my confidence level isn't exactly high.
Given that the unsuspecting consumer expects a working device, it would be in the suppliers best interest to keep updating to not be held liable for damages. It's debatable how reasonable that expectation is nowadays. Otherwise the consumer would be liable. I don't think this counts as an unavoidable accident unlike a hail storm might.
> The vulnerabilities are found in Qualcomm’s software drivers that come with its chipsets. Pre-installed on devices at the point of manufacturing, these vulnerable drivers can only be fixed by installing a patch from the distributor or carrier. Distributors and carriers can only issue patches after receiving fixed driver packs from Qualcomm.
> The research team provided Qualcomm with information about the vulnerabilities in April 2016. The team then followed the industry-standard disclosure policy (CERT/CC policy) of allowing 90 days for patches to be produced before disclosing these vulnerabilities to the public.
> Qualcomm reviewed these vulnerabilities, classified each as high risk, and confirmed that it released patches to original equipment manufacturers (OEMs).
The complexity of this is really a problem for security updates.
It's bad enough for Android updates: the OEM packages it and adds their stuff, then the carrier packages it and adds their stuff. A firmware update like this is yet another layer..
While Checkpoint did the right disclosure thing here, I notice they don't mention how far down the patches have gotten, or how many users are still vulnerable today.
>I notice they don't mention how far down the patches have gotten, or how many users are still vulnerable today.
There were a handful of "Critical" Qualcomm specific bugs fixed in the July [0] and August [1] Android security updates.
I can tell you that my Nexus 5X, which is on the July patch level, is still vulnerable to 2 of the bugs according the checkpoint security scanner. One is listed as being fixed in the August update, the other isn't.
Better 'a someone' on the Nexus 5 than 'a series of someones' (e.g. Qualcomm, Google, HTC, and Verizon) on any non-Nexus phone, only some of which have any vested interest in getting you those updates.
There’s a reason we modularized drivers on other systems, which allows people to customize the OS however they want it, because the firmware, drivers, main OS, UI layer of OS, and applications are all properly seperated.
Ah, so I have the source code for the kernel to patch it manually?
I have the source for the firmware to patch that manually, too?
You are still proposing I run proprietary software that can be abandoned at any time, and where I have no way to continue fixing it if it is abandoned.
We’ve seen that with several Nexus devices before, the chipmaker abandoned the SoC, Google couldn’t fix issues because of that, and we didn’t get OTAs from anyone to fix things.
This is in a certain sense a typical checkpoint finding. It's probably a good finding and it's good that they point out the problematic andorid ecosystem.
But their announcement is then filled with some nonsense and marketing bullshit that's more likely to confuse users than help.
In their blog post they say [1]:
* "Use known, trusted Wi-Fi networks or while traveling use only those that you can verify are provided by a trustworthy source."
What's that supposed to mean? Is a Wifi trustworthy if it's named Starbucks, because I just bought a coffee there?
* "End users and enterprises should consider using mobile security solutions designed to detect suspicious behavior on a device, including malware that could be obfuscated within installed apps."
I call bullshit.
* And then further on [2]:
"ZoneAlarm® Mobile Security for Android™ keeps your mobile devices fully protected from malicious apps and Wi-Fi attacks."
Oh really? Can they explain how they overcame the theoretical limits (halting problem) that prevent something like this from being possible?
A lot of it reminds me to the Misfortune Cookie vuln a while ago. Also a good find from Check Point in DSL routers, yet they claimed Zone Alarm can protect you, which was outright nonsense.
i bought this phone only to "vote with my wallet" that more companies should make android phones with keyboards. It is pure garbage in any other aspect. It is the lame phablet size. The keyboard doesn't even have a DOT or COMMA key, let alone numbers, tab, etc.
The only redeeming features is the OLED screen and keyboard. But then they made the software for the keyboard pure garbage, and filled the OS with bloatware.
I've been waiting for root on this phone so i can start to hack away for months. But blackberry with its cave man corporate mentality, thinks that giving out root will scare the 5 old men still buying their products. I can't even buy a developer version like motorola (which have the same mentality) allowed before.
So, thank you for the sloppy coding, Qualcomm! Thank you for not doing your homework, Blackberry! and thank you AT&T for holding OS updates until you can bother to patch your bloatware!
As a former Samsung owner, that's actually the same feeling I get every time I heard of an Android vuln but definitely without the frowny face. I only get frowny face when the exploits don't work on my specific device. Or, rather, used to then I noped right out of that situation and got a Nexus device.
In the same way I never intend to get "free phone with contract" ever again, I hope to never again buy a device that is subject to vendor "enhancements."
Do you really own the same priv as i do? Because i sit with a superb phone on august 5th patch.
Dedicated Comma, dot, numbers keys? Buy a laptop. Or stay with priv, double-click alt and voila! Use all those buttons you named - write numbers and put comma in between without doing anything else.
I regret accidently upvoting your unsubstantiated rant
the priv keyboard is nice, if you have the blackberry keyboard selected.
But as soon as you close the physical keyboard, and get the blackberry soft keyboard, it is pure garbage! years behind the most basic free keyboard. The top 3 softkeyboards for me (swype, google, hacker) have zero support for anything on the hardware keyboard. I can't navigate the cursor, i can't double click alt, i can't swype up, heck i can't even get a word prediction/correction band to show up!
So it is a futile fight with which keyboard you have selected. Then add two languages and now every time you want to switch the language, you also risk switching the keyboard you have selected. It is brain damaging to try to use it.
now, if i have root and can hook up to keyboard open activities on all keyboards (or if blackberry released the source to their keyboard i wouldn't need to do that) i can check if the physical keyboard is open and change it or something.
Some enterprising lawyer could look for people whose phones or accounts get hacked as a direct result of manufacturer-provided security patches not integrated in time by Android core, the device maker, or the carrier.
Then start a class-action lawsuit, with the stated outcome of forcing carriers to allow, at no cost to all users of no-longer-security-patched phones still being paid off on their plan, a switch to newer phone that are still being patched.
While it'd likely result in a settlement, this may be a way to get the ball rolling, and turning our multi-year outrage into actual (if underwhelming) results.
"An attacker can exploit these vulnerabilities
using a malicious app. These apps require no
special permissions to take advantage of these
vulnerabilities, alleviating any suspicion users
may have when installing."
So If I understand correctly, it does require you to side-load an app. Can I assume Google Play apps are "safe", at least from this type of vulnerabilities?
"crap" aside, users of the Play store (as well as Apple's App Store) are overwhelmingly safe.
Google now has Android Security Annual reports [0]. From that you can see that if you only use the Play Store (no sideloading), only 0.15% of devices got a potentially harmful app.
On top of Play Store's security features, if there were a malicious app that began causing trouble, Google has other mechanisms to shut down PHAs. As this vulnerability shows there are issues that are outside AOSP, Android has been shoring up more defenses in depth.
Overwhelmingly safe in the sense that tons of popular apps impede and undermine your security and privacy, especially easily if you're never getting updated to Marshmallow.
I only install very very mainstream apps from major well known authors on my phone. Mostly only from Google but a few others such as Firefox, Netflix, SoundCloud.
If I understand correctly, the exploit needs no special privileges to run the exploit code. Google Play doesn't vet apps before they go up, they take down apps in response to complaints. So no it's not safe, but I'd (maybe naively) expect them to notice a dangerous app pretty quickly.
Google Play does vet apps before they go up. They have several mechanisms to analyze apps before they are published in the app store. Look up Google Bouncer.
This said, it is not clear that their analysis would catch apps that try to exploit these vulnerabilities.
I could have sworn that all apps are run inside a test environment before allowed onto the store. But the process is automated and likely will not catch novel attacks.
This is correct, they do now test apps before they go up. But yeah, plenty of malware is regularly found in the Play Store, so you can't just "trust Google" to protect you.
interesting that they highlighted how ecosystem fragmentation makes patching more difficult; they didn't highlight how fragmentation makes exploitation of their headline-grabbing "900m devices" also very tricky.
This is one of the key reasons the world didn't end when the stagefright series of bugs was released.
As a layperson, I read the report that the exploit could apply broadly (since it's the baseband), but the patches were potentially difficult to roll out because of the layers of fragmentation in approving and pushing out the patches to the baseband firmware and the various mechanisms which might or might not be in pace to do so.
They all look like kernel code/driver bugs to me, meaning there will likely be memory layout and config variations much more significant that you'd see in baseband code which might be a lot more duplicated across devices.
I think I get it more based on your explanation. Essentially, because the potential exploits rely on a larger variety of configurations, it's unlikely that any widespread exploits would take place; the work just wouldn't be worth it.
More likely that they would focus on the largest subset, hence leading to security through variety.
Which is now blocked by SELinux. The android security team has started killing off IOCTL calls which aren't necessary for normal apps. They are also nuking access to weird socket types. Including some Wifi related socket closures, which nukes a huge attack surface on the wlan side of things:
All I ever wanted was pure linux on a phone, so I could do what I wanted to with it, including securing it. Instead what we got was a half open half proprietary peice of crap that even google bent over backwards to let the carriers fuck up with their custom ROMs on top of stock droid.
What we need is an open source phone, metal to screen, so to speak. Oh wait, the cell radio firmwares are all proprietary too?
I blame carriers and their bullshit first, google for not allowing more granular ACL's natively, and consumers for accepting android because they were so ready for anything different.
I wonder if most apps have a reason to use the ioctl syscall normally. I think termios uses ioctl(), but what else? Do apps even need terminal control? Seems like ioctl() could be blacklisted with seccomp. Or maybe whitelist the permitted nodes with seccomp.
Would rooting your phone, and then using an app like SuperSU protect you from this? When a malicious app attempted to get root, would it be able to bypass SuperSU or would the user have to give it permission though SuperSU?
SuperSU is simply a tool which allows apps to gain root access with user permission via an API.
Apps that use exploits like this can still gain root with no need for user permission. However, exploits like this can also be used for users to root their phone and install SuperSU or similar, allowing them to take advantage of the root-only apps on phones with locked down bootloaders and similar issues. This may also allow patching of devices which don't get official updates in similar fashion to "fixer" worms.
This is just getting worse and worse. I'm not going to bash Android specifically, because iOS does get some exploits, but seriously we need to have a more locked down system that allows the user to only install the apps that are downloaded from a app store, that runs the apps in a container and doesn't allow special access to forbidden parts of the system. Of course if the user doesn't like it and wants freedom to use any apps, as well to be open to security risks that come with it, they MUST be allowed to do that, but don't make that the default option on billions of devices...
Yet Google's track record of spam and malware in the Play store is horrific. They obviously care more about quantity of apps rather than quality, and therefor don't do something like Apple with a manual review process.
Google's automatic scanning is actually quite good. Most malware comes from random apk downloads and third-party app stores (often piracy-related). This has been pointed out many times throughout this thread (with links to back it up).
No idea about the exact percentages, but no doubt it's a large fraction of phones. I'm not debating it's insignificant or something - sure, it's giant.
Just thought that pointing out it's Qualcomm-specific issue should make other chipset phone users feel somewhat at ease. (I have an Intel SoC-based one and got nervous upon seeing the title.)
Perhaps I'm not following your intention, but for those with bootloader-locked devices, if we could have gotten enough control over our devices then we would have already jumped off of the antiquated builds. So it's a terrible catch-22: those with super old bootloader-locked devices are actually the most vulnerable to a whole host of these style attacks, but are the least able to do anything to the hardware that we paid good money to buy.
Also, while this may just be my experience with cyanogenmod and the devices that I have managed to root, one can often end up not having access to the necessary blobs to make the phone run as well as it did under the bloated rom. That actually is very similar to Linux and the Win-modems and a ton of Win-printers that followed: sure, you can run a FLOSS setup, you'll just need to be very, very choosy about the hardware that goes into it.
Edit: Furthermore, if the companies are going to lock down devices and driver blobs so nobody else can fix them, all the more reason that the security of the device is their absolute responsibility.