Major Flaw in Android Phones Would Let Hackers in with Just a Text
npr.org
npr.org
You can partially mitigate the risk by disabling auto-downloading of MMS messages in whichever app you have set to handle text messages, such as Messaging or Hangouts. THIS IS URGENT. While the precise details of the flaw have not been publicly disclosed, this disclosure is sufficient for a skilled person to rediscover the flaw, which means that there is a considerable risk that someone will systematically use it on all the phone numbers.
edit: Ah it's in the actual hangouts app that you have to go to settings. Also if those settings are greyed out then you might not have Hangouts handling your SMS messages, so run the Messaging app instead and go to its settings to disable auto open of MMS.
Edit: Messaging (default app) doesn't have this setting, but Messenger does. I tried Hangouts for awhile but didn't like it.
now if you want to make calls from your gvoice number, you must use hangouts.
funny how they think forcing newer apps is the solution to the g+fiasco
Contrary to the NPR article, somebody further down this page said this hack may affect Messenger users too. So I'm sticking with Hangouts!
That seems unlikely given that the researcher hasn't publicly released the details of the hack, and he says that "he does not believe that hackers out in the wild are exploiting it".
Whether it has actually been used, given the value of the bug, is a different story. But it should absolutely be treated as "in active use" already, especially by state or state-sanctioned actors (like Hacking Team).
We do not have a 100% reliable way to determine whether an exploit is known by others (and likely never will have), and as such there is only one reasonable assumption left to make: assume that it is out in the wild and known by others.
This isn't a new concept - threat modelling requires that you assume every worst-case possibility is reality, so that you can guard against it. This was formalized in the 19th century as Kerckhoff's Principle[1], and undoubtedly existed before that in military circles. This applies equally to software security.
So given that we simply don't and can't know whether it is out in the wild, the most 'correct' assumption is that it is - because that lets us protect ourselves against that worst-case scenario, which may or may not be the case.
Are you refuting that fact, or are you not refuting that fact?
Some of them could be rootkits, and have patched filesystem and process explorers to hide themselves. Some could be called virus.exe.
But no, you will never know that you haven't been compromised. In the coming weeks, we may learn about some of the specific malware that spreads this way, and you may be able to test your phone for it, but finding nothing does not mean you haven't been owned by something more exotic.
very convenient timing for all that.
Did they edit their comment between the time you quoted it and the time I posted this comment? Or did HN's quirky rules regarding newlines (gotta put two if you want to display one) change the meaning of your comment?
they may also blast texts out to android only phone numbers (maybe if you gave your phone number to an android app)
Is that possible? I haven't touched iOS in a long time.
When you send a text message from one iOS device to another, it will be blue if it was sent via iMessage, green otherwise.
Again, not sure how this could be automated en masse, but I'm sure it's possible.
Nuking MMS from orbit won't patch your phone.
- They don't read hacker news so they aren't aware of this.
- They won't be able to disable auto downloading of MMS even if they did hear about it (think grandparents)
- They won't ever get an update to their Android phone to fix it (or be able to update it if one arrived)
Instead, why don't Android phone updates work like Chrome's updates do? I installed Chrome v1 years ago on my parents computer and today they are running version 44 (without any intervention on my behalf). They are fully up to date and protected without them having to even know about or run any sort of update.
Why? Why, if it is known to be a poorly written library, is it still part of an official release? And why the hell are client messages allow to specify the level of media down to the library linkage? Wtf.
The author is trying to build up hype for their vulnerability. Maybe if they shit on stagefright enough they can even start selling t-shirts.
To quote moxie: "We don't do any pre-processing that involves stagefright. There are no technical details at all available about this vulnerability (for maximum hype), but you'd have to physically tap on the media and then click through a warning about playing media insecurely before stagefright got involved."
It's also probably possible to extend the patches to detect malicious input.
Someone could probably also create a video with a payload to hot patch libstagefright.
This is brilliant. Assuming that it doesn't cause further problems.
Here's a more modest idea: Google should immediately issue update for Hangouts and Messenger app that at least disables automatic MMS retrieval. Many users have automatic updates for those apps turned on or maybe at least they'll see a notification about app needing approval to update.
[0] https://github.com/WhisperSystems/TextSecure/issues/3817
Edit:And I say this because even though old phone don't get updated, their apps do. Tenuous at best, but still better than nothing.
Yes, I know that Hangouts has GV integration, but it's pretty subpar. There isn't, for example, a decent Hangouts Chrome extension.
The caveat is that MMS media attachments are not accessible in either the Google Voice Android app, or the web UI. They are (IME) only delivered as attachments to the email copy of the MMS.
It's also pretty absurd that Google doesn't support security fixes in a 3 year old operating system (Jellybean).
If the NSA and other three letter agencies aren't using the exploit now, I bet they will have an implementation live within a week.
The ability to remotely tap and track almost a billion people with just their phone number? That sure makes metadata valuable...
The latter can be issued via the OEM or carrier - whereas the former is issued by Google. Since Google own the trademark on the Android name (http://developer.android.com/legal.html), perhaps Google can enforce a rule that an OEM which ships it's device without compliance with the above cannot call their device an "Android device".
Tbh, Google needs to work with the Linux groups pushing for more coherent ARM/device flexibility frameworks, then ban carrier and device manufacturer build modification below a certain level of abstraction. Otherwise they revoke Android branding + access to GApps.
Then they would at least have a base for eventually saying,
"We're going to enable a critical update channel where users take updates directly from Google. We will release these updates to you with a lead time in proportion to the severity. Unless the user has explicitly opted out, they will automatically receive the update after that period. If it breaks your phone, then users are going to stop trusting you as a manufacturer / carrier."
Microsoft still releases regular security fixes for Windows Vista!
(This is separate to the issue that there is ever-changing UI guidelines on Android making each app feel entirely different to another one which is like being in a nightmare and not being able to wake up or understand how it SHOULD behave).
As someone else said, you wouldn't be happy with a laptop that did not let you install Windows updates.
This is the same problem we have with Android, and I'm getting really tired of it and ready to jump ship. It's all very well saying Nexus devices will be updated but why distribute Android to all other manufacturers if they won't get or push out updates? I can't see anyone clapping for Microsoft if they just pushed out service packs and updates for the Surface exclusively.
It is/was an issue in Stagefright.
Details of CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828, CVE-2015-3829 probably available soon?
In my experience, people will open a message just to clear the notification and that's all that it would take for them to be compromised.
It sounds like the fix can't be (or isn't being) made in the hangouts app.
Goddamn you Hollywood.
And yes, the mediaserver has internet access so that it can fetch and decode streams on its own without forcing all I/O to go through a user process. Basically it's a performance optimization, though indeed probably one necessitated by having to wall off all that DRM handling in the first place.
That said, mediaserver, while it has lots of access to things that Android apps don't (e.g. open file descriptors to kernel vendor-specific drivers with lets-just-say-questionable security practices), is not a root process. And it's reasonably sandboxed in recent Android versions using selinux. An exploit into it may not be quite as device-cracking as is being claimed.
Still, not a good thing at all.
Is it safe to assume that this attack vector is not a concern with Android 5.1? (or later)
But at least there is some sandboxing in place; the security architecture was designed to admit the possibility of a breach of the mediaserver.
They share the blame, too. They can't all just throw their hands up in the air and say "they made us do it".
This is huge.
Next they introduced a check for strings shorter than 6 bytes because that's the shortest possible valid string. Why not just check for a valid encoding in the first place? There are too many implicit assumptions about the data going on here and not enough actual validation.
This entire module needs scrapping and rewriting with a proper FSM/parser generator.
And why is an MPEG4 metadata decoder directly handling UTF anyway?
The other parts of Android written in C++ are also a horror show, though I think they have gotten better recently.
And don't even talk about the proprietary HAL blobs or kernel modules. Unspeakable things happen there. And of course, libstagefright talks directly to these.
Looks like an instant code smell to me.
https://en.wikipedia.org/wiki/Single_responsibility_principl...
EDIT: I appreciate the replies. I was really wondering if I can disable video attachments without disabling other MMS features such as pictures and long messages (in Android 4.3).
The only problem is that many phones automatically turn long SMS messages into a single MMS message. As I understand it, you might not receive those -- although I'm not sure about this.
1. http://review.cyanogenmod.org/#/c/103267/
2. http://review.cyanogenmod.org/#/c/103268/
3. http://review.cyanogenmod.org/#/c/103269/
https://github.com/CyanogenMod/android_frameworks_av/commits...
So. Good luck with a class action suit. You've likely agreed to a contract in which you waived your right to file one. :(
Yes, this sucks. I wish Congress would fix up federal arbitration law.
I bought the Moto X largely on the... assurance ("promise"?) that this particular phone, coming from a Google-owned Motorola, would actually be updated expeditiously by not just the manufacturer but also, downstream, Verizon.
Well, about a month ago my still 4.4.4 phone received an update. FINALLY. Then I looked at the version information; still at 4.4.4 .
I tell you, Google, I'm about done with your mobile products. Not that I hate dealing with them, with Android, but the U.S. (and elsewhere?) ecosphere for them simply sucks.
At least I am at 4.4.4 . Were I at 4.4.3, the last I read I would be subject to a web component vulnerability that Google has refused to fix below 4.4.4 . I suspect there are a lot of phones and tablets stuck at 4.4.3 or below. In fact, my parents have one, a Samsung tablet sold to the by... VERIZON, about a year and a half ago. (And they didn't buy at the cheap/old end of Verizon's tablet offerings.)
I am DONE with this bullshit. Meanwhile, Apple seems to have added some efficiencies to iOS that now allow a 4s phone (not sure about 4) to work reasonably well.
I was staying away from Apple's rather closed ecosphere and attitude. I am seriously reconsidering, at this point. I need my primary phone to fucking work and be reliable. I'll keep the more experimental stuff to other platforms.
https://motorola-global-portal.custhelp.com/app/software-upg...
Verizon has long been a bastard with regard to releasing updates. However, travel takes me where they are the only thing that works (other than a local carrier that makes no sense back at home). They also tend to have better coverage here at home.
BUT, they told me that one of the selling points of this model on Verizon was that they were committing to releasing updates in a timely manner.
My fault for believing Verizon. But... Google's fault for not pressuring them. iPhones on Verizon get updates. This becomes "simple math", for the user on Verizon. And, Verizon has a lot of users, here in the U.S.
P.S. Even if Google is not in a position to effectively do anything about this, they should recognize the pressure this applies to users to switch platforms. Something I would imagine they ARE interested in.
I may look into jailbreak/rooting options that are compatible with ongoing Verizon service, for the phone.
In future, if I don't switch to an iPhone, I may well go with another carrier, and just eat the cost of e.g. a prepaid Moto G for the times when I travel and need the network covereage. Still, seems ridiculous. And if not Google, the FCC should be taking a good, hard look at Verizon Wireless. At some point, negligence should apply that, if nothing else, gets their spectrum allocations revoked. That would get their attention, fast.
P.S. Maybe a Google lobbyist and/or lawyer could have a quiet little conversation with their FCC contacts about this?
And I apologize, after that rant I realize it doesn't really have anything to do with the topic, but I've sunk the cost already!
There were some hiccups with the upgrades to 5.x, but I didn't get caught by those. News reports taught me to be a bit conservative, in exercising a bit of delay before applying OS updates if there was no looming security fiasco.
Compared to my parents' contemporary and more expensive Samsung tablet, with Verizon LTE (and thus, Verizon as well as Samsung in the middle), that is still stuck on 4.4.1 or 4.4.2, the last I looked... And with some crappy third party calendar app as the default that had my mother confused for a while...
Well, via that comparison and others, I'm agreeing with the other commenter that if you can go straight Nexus, that seems to be a better way to go WRT the Android platform.
I'm hitting "tired"; otherwise, I might be able to think of some of the software concerns I've had that are not OS / updates specific.
Oh, I remember the time I added some photos to Keep, to learn that there was no way to keep them from syncing while on the cell connection as opposed to WiFi.
And, I could lament the whole "fish around on the web for random articles, for your documentation" approach, these days.
Anyway, I'm mostly responding to show a bit of support, despite our differing satisfaction levels / experiences. When something doesn't work, too often the environment/app leaves us feeling SOL. They got my money, so f--- me! ;-)
The fact that the only way to get reasonably-paced system updates is to install 3rd party operating systems (e.g. Cyanogenmod) is extremely frustrating.
Buy a Nexus phone. It's that simple
unofficial Motorola word on xda was that there was a single intern handling releases for older phone. heh i actually believe it.
everyone here with a short memory will say they are on 5 already. which adds nothing. and they will forget the 4 months they were on a insecure 4.x
Do you have to have the "Hangouts" app installed for this security vulnerability?
Google doesn't seem to have learned from Microsoft's decade of "autorun" problems.
It has been (0) days since the last C language buffer overflow vulnerability.
No. The flaw is present in the extraction of the image data from the MMS message. Anything that uses the system standard way of doing this, including but not limited to Hangouts, will be vulnerable.
Hangouts retrieves MMS messages by default. This can be disabled under Settings => SMS. Turning this off disables the automatic processing and thus the passive exploit, but opening an MMS message containing the exploit can still be done by hand.
Edit: Just had a look. I do not have TextSecure as my default client. There is MMS configuration information, but not a simple "disable automatic retrieval" or similar setting, as there is in my default SMS/MMS client. I don't know whether one appears when TextSecure is the default client; I suspect not, and maybe this should be addressed?
Maybe I will make TextSecure my default app. I'll give "the hype" a day or two to start sorting itself, while I have the "auto" stuff disabled in my current default app.
In my -and my lady friend's- experience, TextSecure is the the only app to correctly handle MMS group chat. We tried the stock Android app, the stock Samsung app, and Hangouts. They all failed to do the right thing in one way or the other.
http://support.whispersystems.org/customer/portal/questions/...
That would be the cheapest solution.
edit: added benefit, everyone is free to load on his device whatever he chooses. Google should have gone that path way earlier.
In the US, the business model for mobile phones is that carriers buy phones from the manufacturer and sell it to the end consumer. The carriers have ultimate influence on what they purchase which affects what the manufacturers produce. You, the end consumer, is a consumer of carriers rather than phone manufacturers.
Their stronghold is even enough to prevent ODMs (!) from building non-Play-licensed phones - either you only ship non-play-licensed phones or you ship only licensed ones. No in-between.
It isn't that simple. Although creating a successful smartphone platform from scratch would be very difficult, if enough manufacturers got tired of the terms they might band together are create an app store to rival Play while maintaining Android compatibility. In this case, app developers would only need to change code for in-app purchases, licensing, etc. so a large enough group of manufacturers could draw a significant number of apps to the new store.
If Google had required this at the start, Android would never have gotten off the ground. Requiring hardware manufacturers to open source everything would have been a non-starter.
Automatically parsing videos before the user even chooses to interact with them makes it even worse - although I suspect most people would play a video sent to them over MMS even if it came from an unknown contact.
an opportunity for Microsoft too.
Clearly this plus the web-view exploit fiasco will damage the android plate-form for the long run.
Hundreds of millions of devices are affected by this exploit and most of them will never be patched. I'm sorry to say but i'll have to pressure my IT department to ban android devices, period. The problem isn't the MMS tech, the problem is android's lousy security model. And the fact that Google think it can wash its hands off all this and shift the blame on manufacturers... outrageous.
While some manufacturers actually opensource their android 'implementation' (like Alcatel, you can actually download some source code for a specific device and patch it yourself) , most don't even bother doing that.
This stuff is a disaster.
http://blog.zimperium.com/the-biggest-splash-at-blackhat-and-defcon-2015/
I wouldn't rule out browser as attack vector but I do think the heavy sandboxing at least limits damage and scope. As the article points out, messaging apps are in a different class.
Will be interesting to see how this develops. And because the vulnerability is in the system libraries, any app that can deliver video content may be used as an attack vector.
I thought phones didn't even support this anymore. I've never seen anybody using it, and I wouldn't know how to send one.
All the multimedia messages I see people using are transmitted through the Internet.
There, it sent an MMS. It's transparent to the user.
Non-MMS: Hangouts to another Google user, Whatsapp, Telegram, Viber, etc etc
In the US most people are still on a monthly plan that includes "unlimited texts" (inc. MMS). In many other places a single MMS can cost you between 5c-$1, so people use WhatsApp, Google+, or many other free (or cheaper) alternatives.
But MMS is definitely popular in certain regions. It is also very unpopular in regions. If you're in the UK you could very easily disable MMS, but in the US? I wouldn't...
If this issue got bad I might disable it. But it would be unfortunate to have to do so.
> In this attack, the target would not need to goof up — open an attachment or download a file that's corrupt.
Is this line simply erroneous?
this is a nightmare bug that will haunt android forever
I can already imagine many celebrities getting hacked through it
If they get one celebrity, they could get all their friends.
I predict a second one of these https://wikipedia.org/wiki/2014_celebrity_photo_hack
Ironically this time iphone users will be protected.
There's your discovery layer: https://en.wikipedia.org/wiki/Kademlia
C&C: http://www.reddit.com/r/netsec/comments/2pmmfu/using_the_blo...
Persistence Layer: https://github.com/cockroachdb/cockroach
Dissemination Layer: https://en.wikipedia.org/wiki/Gossip_protocol
Sprinkle in some AES and public / private keys for verification and you're done.
Sequential list isn't needed.
(well, all the robust & stealthy large systems engineering together with the low level exploit knowledge is probably a little too much for one person to pull it off, but for a Hacking Team or nation sized actor it's quite doable)
Pretty sure celebrities use iPhones.
And I also wonder how many more critical exploits are known and used by 'hackers' or agencies today while we have this puffy feeling that our data/communication is private and secure ?
The conclusion I can draw from this: never trust that your phone is secure. Or computer for that matter.
He says it will take a long time for those patches to make it to devices, but I question the validity of the assertion simply because Google has moved more and more into the Play framework. So, unless it is truly a kernel bug I would expect that it's fixable in the framework ore target application.
Please correct me if I am mistaken though.
AND... could one possibly use this exploit to push their own patch? Could someone who has a payload with a fix mass-message all android users? That payload could also try and send itself to others within the then-patched device's contact list.
[0] https://play.google.com/store/apps/details?id=com.google.and...
Android should rather work on a feature that allows them to patch their not-so-open operating system just like Apple does (or use a concept that is close to the one in the GNU/Linux world but I don't think Google is gonna do that).
- It's made by Google (i.e. the guys who made the phone's stock SMS app)
- It has nearly identical navigation to the stock "Messages" app, simply with a much cleaner interface
- It does not hook into anything other than your contacts, unlike Hangouts
For all intents and purposes it's the successor to the stock app, made a separate app specifically so that it can receive timely updates without being tied to a system update.
Having used both, there's really no compelling reason not to switch to it (sans the grandma-with-a-smartphone edge case who has never opened the Play Store).
I'm not going to replace my phone each time there's an exploit that the manufacturer doesn't fix. So I don't think an Ubuntu phone would be such a bad idea.
http://www.techmeme.com/150727/p8#a150727p8
It seems one of the original reports is here:
http://blog.zimperium.com/experts-found-a-unicorn-in-the-hea...
I'd also note that it seems this is research that will be presented next week at Black Hat and then again at DefCon.
GNU/Linux distros are free open source software, and don't suffer from these sorts of update problems. Many distros have special high-priority security update channels that are enabled by default.
Please, call this out if you have friends writing / spreading such nonsense.
That isn't "spin". Android's ecosystem is (largely) controlled by the phone carriers in this context. Their "open" system is a fractured jumble of closed systems with indifferent maintainers.
If Google took it up, Apple's method here would be a solution. Were Google to force carriers into supporting security updates on Google's terms, we wouldn't see this kind of issue.
Nobody making the Android/iPhone comparison in this context cares about "openness". That's largely a foregone conclusion on both devices. They care about the effective and timely distribution of security updates.
> GNU/Linux distros are free open source software, and don't suffer from these sorts of update problems.
Why on earth would NPR compare Linux distributions (which the general public has basically never heard of) to smartphones? It might be "more accurate", but it's not an accessible comparison.
See also my other comment about words having false connotations, regardless of intent.
> Nobody making the Android/iPhone comparison in this context cares about "openness".
I don't know why you just assert this so nonchalantly. Clearly some people care, because they keep repeatedly associating closed systems with security update mechanisms, even though we have plenty of open systems with relatively good security update mechanisms. That is in fact my whole point; other people keep veering off on a tangent.
> it's not an accessible comparison.
What is "accessible" is very transient, dependent on the environment and cultural background. Those of us who are interested in balance and accuracy, have to make it accessible. Not doing so is irresponsible.
The fact that Apple runs a closed system is not relevant to Android having poor security updates, as is evident by how GNU/Linux distros work - yet these things are mentioned next to each other, as if they are related.
(edit: lots of people missing the point here. media articles can equally point to free open source software GNU/Linux distros as having relatively successful security update mechanisms, yet Apple's closed ecosystem is always given more focus as the contrasting example to Android's; why? it is not the closed property that makes a security update mechanism succesful, yet that is the implication.)
(edit: this is how weasel wording works; statements of fact which may be individually correct, are placed together in suggestive positions, so that the non-cautious reader walks away with a false understanding of a more complex point, but allow the author to deny responsibility of this)
Other media articles have similar weasel wording. I'm not commenting on the author's intent - e.g. they may just be repeating the dominant narrative on this - however the wording has misleading connotations regardless of intent.
This isn't that hard:
Bug in iOS:
1. Apple releases a patch
2. All users of supported devices can install it
Left hanging: people with old devices (minimum age approaching half a decade)
Bug in Android:
1. Google releases a patch
2. Many Nexus users can install it immediately
3. Everyone else has to beg dozens of manufacturers to ship an update for a device which brings no further revenue to the hardware manufacturer
4. At least in the U.S. everyone then has to beg carriers to ship an update to existing devices rather than using this as a chance to push you to upgrade to a $$$ new device and extended contract lock-in
Left hanging: everyone who doesn't own a recent Nexus device. Minimum age: negative – devices without the current OS will be sold to users months after release.
Note that absolutely none of this is Android's fault technically. It's only Google's fault to the extent that they naively believed everyone else would be responsible and neglected to have this license require updates, unlocking after dropping support, etc.
Otherwise known as "entirely their fault". It was very evident that this would be the case, as it was always the case before. Left to their own devices, OEMs and carriers will not approve updates because they simply don't care and have zero motivation to.
It happened with Treos, Nokias, and BlackBerries. It didn't happen with Apple because they used their clout to strongarm carriers into playing by their rules, and they are the OEM.
Google deliberately went buddy-buddy with the carriers to saturate the market as much as possible in response to the iPhone, and the concessions they made to do so are part of the reason Android devices still have this problem.
There was absolutely no reason to assume that anyone would "be responsible" if left to their own devices. It was not naivete, it was a calculated tradeoff to grant carrier control over user security, to give carriers a reason to promote Android over iOS. Google did a lot of things right with Android, this was not one of them.
infinity0's point seems to be that a more fair reporting would be: (1) here's the problem with Android's ecosystem [was included] (2) here's the solution with Apple's ecosystem [was included] (3) here's the solution with OSS distros' ecosystems [was NOT included]
I think it's fair to take umbrage that an intelligent but uninformed reader could very easily walk away from that article with the conclusion that "If Google ran Android more like Apple runs iOS, then Android would be more secure."
Which itself is probably true, but far from the only solution. And indeed, probably the least free (speech) solution.
Point 3 is only true if you cherry-pick “OSS” to mean “People who installed Red Hat, Ubuntu, Debian, etc. themselves and religiously install updates”. OSS also includes things like the various forks and boutique distributions which started drifting behind, all of those insecure libraries where someone installed a copy of OpenSSL, libtiff/libpng/etc., or almost any PHP app, and never came back to update it.
This problem is only going to get worse as the IoT gold rush continues and all of these “Two EEs and a web developer” companies ship a device shortly before folding, being bought out, etc. and there's no indication to the customer when it's no longer safe to have that device on a network.
Note that this isn't saying that open-source is insecure – the same problems routinely happen with commercial software, too – but rather that it's not a magic wand for solving the problem. Apple ships updates promptly because their reputation depends on it, which is the exact same mechanism which keeps Debian, Red Hat, Ubuntu, etc. going, too, but that approach doesn't work in the case where the real customer isn't the person using the device. As long as Samsung keeps Verizon happy, they only care about the user experience to the extent that many people would choose to buy another not-Apple device instead of theirs.
Ultimately, I think we really need legal changes to ban corporate attempts to shirk liability for flaws in their products and sharp restrictions on the ability to prevent users from securing their own devices – something like a vendor being required to publish the full source, build toolchain, hardware unlocks, etc. if they go more than a couple months without releasing a patch for a known problem in a particular device.
Google sets the terms by which it does business with OEMs. And yet, they've never been held to blame for the bad experience that users get due to this model. Google uses these terms to protect it's monopoly dominance, by mandating OEMs install 20 or so proprietary Google apps, but not to do anything really valuable to the customer, like mandating a security patching methodology.
Agreed, and imho this is in practice where Android differs from OSS as I referred to it.
Worst case, if you're running a non-Redbuntianwarint distribution, then you still have much better access and separation between components. Admittedly in practice almost no one avails themselves of the ability to build from source. But that's not the point.
The point is that someone can do so, and distribute that to others if they want it.
With Android, that prospect on {random device X} gets a lot more tenuous. Either because there are hardware security locks to prevent you from doing so or because there are missing or unavailable pieces that are included in the official manufacturer/carrier's build.
Perhaps as we get more physical hacking events that are easy for the media to cover, companies will start taking this seriously. If so, I'll guess that Google will assume that responsibility in exchange for more Apple-like control over the update process. There's no other sane way.
Most of the problem is that the general cycle for Android is a decent base OS which has two levels of middlemen adding cruft to it mostly for marketing reasons and that's as bad as it is because they're only looking potential income. Not letting them dodge liability changes that calculation in favor of either not obstructing the update process for branding reasons or, if they really think their custom UI is such a great selling point, actually hiring enough people to support it reponsibly.
I don't see how they would have to cater for what their readers infer from this text about open source at all, as I can't find any way they even suggest that Android is open source.
The only reference to 'open' I can find in the text is "open an attachment or download a file that's corrupt.". The closest I can find to "Android is open source" is "Google gives its latest version of Android to manufacturers, and they then tweak it as they please.".
I think anybody who makes the jump from that to 'they can tweak it because Android is open source' also knows enough to not make the further jump to 'open source is dangerous'.
> 4. At least in the U.S. everyone then has to beg carriers to ship an update to existing devices rather than using this as a chance to push you to upgrade to a $$$ new device and extended contract lock-in
The solution is for Google to pay manufacturors (or share revenue, however you want to put it) to update all existing phones:
- Google is accountable for shipping the bug. They should pay the costs.
- Google is currently taking almost all the profits. Android phone makers, as we've all read, are running on thin margins, if they aren't losing money. The media stories that say Apple makes 95% of all mobile profits fails to include Google's profits.
Google not doing this is, IMHO, an ethical breach and putting profits before users greed. What shinratdr said.
1a) If the issue can be fixed and/or worked around in Play Services, Google does that and "everyone" gets the fix without even having to explicitly install it.
3b) For each OEM, if the problem can be fixed/worked around by updating the apps and/or frameworks they publish via the Play Store, they do that (if only for the sake of new and upcoming devices) and all of their customers get it once they install those update.
Those cover a large (and growing, because Google and the OEMs are both aligned on this) chunk of your "left hanging" users.
#3b is particularly optimistic since that assumes an OEM will ship updates promptly and that's been the underlying problem here since day 1. It particularly wouldn't help if, say, a vendor ships an update for their flagship Android 5 devices which doesn't run on the 4.x devices which most all of their users have and will never receive an upgrade to Lollipop.
I wonder why do the manufacturers even lock the phones if it brings no further revenue. They lose nothing if users where able to pull the updates directly from Google.
Because a Google update that conflicts with their own customization and borked the user experience would cost them future revenue, since it would reduce the chance that the user would by a phone from them in the future.
1. goes unfixed for months
That it's closed against us is not nice at all, but being closed against Deutsche Telekom and Verizon and such is a feature, not a bug.
The issue is described fairly accurately.
It would however be nice if the article brought up the point that the issue could be mitigated if users were allowed to actually control the software that runs on their phone (without hacking around restrictions). Instead most users are reliant on the device manufacturing seeing the financial incentive to provide updates.
Most users are reliant on this regardless. Few people possess the technical ability, much less time, to perform these tasks. Making the platform "open" and pointing to that as a solution would also be a way of weaseling out of that responsibility to users.
Obviously there are users who will be left behind, but that is an issue for novice users of ANY free and open source software.
But there are plenty of crappy, not-updated-that-often linux distros that strand users too!
Just like in android, on GNU/Linux you are dependent on how good your OEM is, and what they provide you in terms of a security update mechanism/times.
Here is what it looks like to play the game:http://www.htc.com/us/go/htc-software-updates/
Agreed, but I would go further and say that the _PC platform_ doesn't suffer from such problems. You can buy a computer from HP/Lenovo/Toshiba/whatever and later buy an OS upgrade from Microsoft. Ordinary users can do this.
How can you "text" a video? Texting uses.... text. The clue is in the name.
Not bothering to read the rest of the article.
This is similar to sending malicious attachments with an email (which is just "text", after all) which the user's email client opens automatically.
Snootily declaring "not bothering to read the rest", though...