Android's fragmentation leads to a digital security divide | Hacker News Reader

Android's fragmentation leads to a digital security divide

money.cnn.com

35 pointspetethomas58 comments

Android devices, as deployed in the wild, consist of a bewildering array of offerings, from shovelware-equivalent throw-over-the-fence devices, to pricey flagships whose makers command some brand awareness. Google has known for years that the Android security patch situation is awful, and has been slowly trying different approaches -- from shipping its own hardware, to moving portions of the OS out of the base image and into Google Play Services-updatable components (much to the chagrin of those who lament the increasing disparity between stock AOSP and Android-as-shipped-on-devices), to its newest: Project Treble, a HAL and vendor interface.

But a big part of Android's headaches is the long tail of devices that have been functionally abandoned by all involved parties: the device maker, the carrier, and Google. These devices are trapped in time and in a cesspit of an ever-increasing number of vulnerabilities. It's like unpatched WinXP, except these devices were once bought new a mere two or three years prior. Because all involved parties have dropped the ball, and at the lowest end of the market, the consumer can't really punish the these parties because they're reliant on the exact same names to get access, this sad state of affairs continues until Project Treble ships for real.

At that point, all pre-Treble devices are still doomed, but post-Treble devices at least have a fighting chance.

As I mentioned in another comment, I doubt Treble will succeed if not followed by legal requirements on the Play Services contracts or gated access to Google servers.

They will keep not providing updates, because they don't come from Google anyway, even with Treble.

I agree. It's now come to the point where OEM's must now be legally required to update their devices for a certain amount of time to be granted access to GMS. There are no financial incentives for these OEM's to do anything once their device is out the door.

And this results directly from the fact that most users not seeing value in updates, otherwise, maybe some small OEM's who offer updates , would be more successful.Or the major OEM's would offer paid updates.

It's also interesting that Windows Phone -- I'm intentionally using the term very loosely -- showed that it's possible to offer lower-end devices that do receive security updates straight from the OS-maker on carrier networks, although a myriad factors, including hard reboots of major versions dead-ending entire device lines, and a less-than-thriving third-party app ecosystem due to another set of problems doomed the entire ecosystem in the end.

But Microsoft mandated UEFI to rationalize the clusterfuck that is the "ARM platform" from the very beginning, and made it so that the carrier would have to explicitly disable an MS-pushed update, rather than the Android equivalent of the carrier having to prep the update in the first place.

This is not correct. All firmware updates can only be made by the OEM and not Microsoft. So any firmware updates would need to be pushed by the OEM and then approved by the carrier.

> all pre-Treble devices are still doomed

The only devices that are doomed are those that:

A. have no reasonable support for third party firmware B. have no user base or community to maintain security

The Galaxy S series since the S3, for example, is unlikely to ever stop getting some degree of support from community ROMs. Of course, those community developments don't have the resources of the OEM - they can't fix the proprietary parts that break, and security hinges on the willingness of volunteers to merge patches, which they don't always do.

I don't think its that black and white, though. Plenty of "supported" devices get updates and ignore security vulnerabilities. Companies can and will stop updating arbitrarily, and you have no way to know who is actually looking for vulnerabilities to fix. All you get is a set of known exploits elsewhere and the means you can test them yourself on your own devices, or someone else did and you already know unpatched vulnerabilities on your end.

>A. have no reasonable support for third party firmware B. have no user base or community to maintain security

You're automatically assuming that these third party maintainers apply all of the security patches released by Google. This would be an incorrect assumption.

Those updates are useless to the common people on the street.

There is no technical reason that Android phones aren't up to date with patches. Apple is not doing something magical here. This is something that could be remedied if Google forced phone makers and carriers to support the latest patches ASAP.

iOS may be more security-focused in general than Android, but this article is centered on updates and un-patched phones. That part of the security equation is very solvable.

Except that they haven't solved it, and show no signs of nor have any financial motivation to solve it.

> show no signs of nor have any financial motivation to solve it

_You_ haven't seen signs ;) Project Treble was announced at Google I/O.

It will fail like the previous initiatives if not followed by legal requirements on the Play Services contracts or gated access to Google servers.

I remember hearing a bunch of initiatives and plans to keep Android phones up to date over the years[1]. They all quickly disappear and a year or two later there's some new plan. There has been signs, but financial motivation and followthrough is missing.

[1] http://www.androidpolice.com/2011/05/10/io-2011-android-alli...

That alliance sounds like just the motivation/PR part. Treble is the "remove the actual technical hurdle that made it hard" part.

There were many other "initiatives." I remember for the Alliance at the announcement they were very emphatic that it wasn't lip service, expect to hear more soon. 6 months later I saw and article pointing out how nothing seems to have happened since the announcement.

I saw and article from 2010 recognizing that phone updates weren't reaching customers and the initiative was to untether more apps and release them via the app store. They pointed to Google Maps as an example they were copying. I don't really pay attention enough to know if that was successful. That seems like a "lower hanging fruit" version of Treble.

This problem has been around since the very first handsets...almost 10 years ago. Both technical and working groups have been attempted. I'm skeptical things will change.

One difference with security implications is that Apple makes both the hardware and the software. So the hardware is controlled by Apple and can authenticate the software, across the full stack, including the fingerprint sensor (this is why third parties who replaced the fingerprint sensor were running into problems awhile back.)

This ensures all software run on the phone is uncompromised. For android, the software is modified by the carrier, and while their intentions are likely good, their ability to integrate the security patches with their custom changes is open for debate (carriers are not the best software developers.) Further, there are more opportunities for compromising the software that is run- more surface area to attack, including installing malware in the supply chain.

Google already makes a bunch of requirements to access the Play Store services on their contracts with OEMS and carriers, requiring a certain level of updates to access those services is just another legal clause and validation when devices talk to Google servers.

Except the Windows world shows it isn't a technical hurdle either. Microsoft makes their OS, OEMs buy copies of it, and stuff bloatware and crap and change stuff all the same as Android vendors before selling it to consumers.

But then, despite modifications, Microsoft updates their stuff, including the kernel.

It doesn't actually even take hardware vendors being ethical and making open source mainline kernel drivers for their parts. They could just be shipping DKMS kernel modules instead of baking their trash into fixed kernel releases. But they simply do not, because they don't care.

You're missing the part where these Android OEM fork the OS, add all of their source code modifications, compile, link and the build it. Google cannot update an OS created by another OEM because unlike Microsoft, which provides these OEM's binaries of their OS, Google simply provides the source to Android.

I was under the impression that even Blacberry, who release security patches every month, are too slow though...

How are you supposed to force companies using open source software to update it immediately?

Legal actions and blocking access to those devices to Google servers.

Google already has requirements that if you don't install their Google apps and services, you can't get access to the latest versions of Android. They could simply withhold recent versions unless organizations meet these requirements.

There would be nothing stopping companies from using older versions of Android, however.

> There is no technical reason that Android phones aren't up to date with patches.

That's true for the 1st world only. Where I currently live the most recent phone I can get within 1.5h of driving runs Android 4.

Also, Apple has a so much better security track record because they do not cater to the low-income population. Long term support is factored into the price of an iPhone but definitely not into the $20-thingy I can buy at every street corner everywhere in the world.

$20 ? What, Where ? i though $50-$60 was the low end of android phones.

At the risk of sounding like a libertarian, what's the issue here? Clearly the consumers/market has spoken and they place a very low value on security.

I don't think I would say that consumer ignorance counts as consumers speaking via the market. Computer security is complicated stuff and no one really explains to users what the vulnerabilities are and how to mitigate them.

The fact that we don't have chip and pin credit cards in the U.S. is hardly evidence that consumers don't want them or that they somehow prefer a system that makes it much easier for them to be defrauded. It's simply that the few credit card companies we have don't want to spend the money to provide chip and pin (or another secure payment system).

That's untrue. The problem is that because once you get a chip and pin machine customers are obligated to use it. Businesses were wary that this would scare customers away due to "difficulty" so slowed down adoption.

Other parts of the world have been using chip and pin systems for a long time. Clearly, customers understand it. Americans know how to use similar technology from ATM cards (and many make purchases this way).

I have no doubt that businesses don't want to change and invest in new technology, but I have never met an individual credit card user who has professed love for our current credit card system.

Chip is not especially hard to use, but it's unquestionably a worse and slower interface.

With a swipe you can do it while they are still scanning your items, and you can swipe and immediately put it back in your pocket.

With a chip you have to wait till they are done, and you have to wait about 5 to 10 seconds for it to do its thing - then sign it, while the card is still in there (so you can't really keep holding your wallet since you'll need two hands, one to hold the machine, the other for the pen).

Then finally it lets you remove the card. And you have to take out your wallet again and put it back.

Swipe uses exactly zero time, since you do it while you are anyway waiting.

Chip takes about 30 seconds. It adds up. It's also more annoying since you can't just put the card right back in your wallet.

I'm curious. Is this common in the US for terminals to operate that way?

In Russia, POS terminals are connected to cash registers, and only initialize after the items are registered - I think I never ever saw them active prior to the final cost display. Only then you can swipe (or insert) the card. Probably that's just a local specifics, so I'm interested in learning how this works in other countries.

The larger the store the more likely you can swipe right away.

In smaller places typically you have to wait for a total.

It varies. I've been to locations where you can swipe as soon as the first item is scanned and others where it won't accept it until the end. The one certainty is there will be no consistency in the payment flow between more than a few businesses.

The interface you’re describing is chip and signature.

Chip and Pin isn’t the same UX/flow as Chip and Sig.

We (US) currently chose the worst of both worlds.

What's the Chip and Pin interface? How does it vary from Chip and Signature?

Chip: "something you have" factor. The card has a tamper-resistant chip, that holds cryptographic keys and does the signing.

Pin: "something you know" factor. Card owner enters a PIN code on the POS terminal's keypad. The card only allows the transaction after the correct PIN entry, and blocks in case of multiple errors.

No signatures required in this scheme. Except for the cryptographic ones, of course.

It works like this: you insert the card, type in[1] your PIN code that is supposed to be secret and then the purchase is authorized.

Requirement to enter the PIN lessens the fraud possibility in case of lost or stolen cards, and requirement to have the chip combats skimmers (if terminal is capable and card has a chip, swiping the magstripe instead of using the chip should result in rejection).

______

[1] If prompted. Depending on the bank, infrequent low-cost low-risk purchases may not require a PIN code. Card keeps a list of recent purchases in the EEPROM and is probably capable of starting to ask the PIN code after number of purchases is over some threshold (but I'm not exactly sure how they're programmed).

That's the same interface as Chip and Signature, except you enter a PIN instead of scribbling on the screen.

Terretta made it sound like there was a large difference.

Well, card's MCU cannot validate the signature, but it can (and does) validate the PIN code.

With chip+sign, if you lost the card, anyone can use it. They'll just draw something remotely resembling the signature on card (if there's any) and that's it. With chip+PIN, this isn't possible.

I think that's a significant difference.

That is a difference, but it's not what I asked (because I already know about the security difference).

He made it sound like there was a UI difference especially as regards transaction speed and convenience.

There is. You insert card, type pin, hit enter, in one step. All that back and forth and waiting around in your UX discussion is for signatures done at a different step. This is most obvious when the chip reader doesn’t have a stylus and you’re waiting for bits of paper and signing those instead.

It’ll really hit home in European cafes vs US restaurants.

I think part of it is chip & signature vs chip & pin UX because this doesn't seem to be an issue in Europe (I also remember their chip reading being significantly faster...but maybe that's an illusion?). There's a story about the Houston airport where people complained that their luggage took too long at the new terminal. They created a longer route for people to walk from the plane to the luggage carousel and the complaints went away.

If I remember correctly, with chip & pin you put in the card, type your pin, then remove your card. With chip & signature you put in your card, wait, after a receipt is printed out (or the screen prompts you) you scribble something that may or may not resemble your name so you can leave.

Personally, I want to use ApplePay/GooglePay but it's slower and more awkward only because I'm not sure if the terminal accepts it. I can get out my wallet and my credit card knowing it'll be accepted. With ApplePay/GooglePay I have to wait, possibly put my wallet away, pull out my phone and pop up the screen.

I can confirm, chip takes what feels like forever. You put it in and wait for probably 30 seconds until the machine starts making annoying sounds for you to remove the card.

With a swipe, half the time when I'm done sliding my card through it's already prompting me for my pin. This time difference occurs at self checkouts so I know it has nothing to do with a cashier.

Eventually I figured out using NFC is significantly faster but not everyone has them :(

Well there's NFC. You put all your groceries into your bag once they scanned them, you tell them you want to pay by card, hold it in front of the terminal, enter the pin, done. Yes it takes 2-3 seconds until you can enter the pin (only if amount > 25€) and then another 2-3s for it to very it, but during that you can just go back to putting things in your bag. If you want to you can also get a thin wallet and not even take your card out at all. You're also overcomplicating the whole chip & pin/sign process by a lot. If the machines are simply mounted somewhere all you need is two fingers to hold/insert your card and then one of them to enter the pin or one hand to sign if your bank is weird. It's like you really want to see problems with the system. It works fine in other countries.

Huh? I'm confused, I live in the midwest and chip and pin is everywhere. Do stores not use it in other places?

Where I live (also US midwest, rural area), about 2/3 of locations where I regularly shop have the "chip" part implemented, zero have the "pin" part. (Chip and pin = having to type a pin each time you use the card in the chip reader.)

Pretty much every store I go to, I use the chip and then enter my pin. I haven't had to sign in over a year.

I live in not-very-rural PA (45 mins north of Philly) and all the cards and most readers have chips but nobody takes pins, I still have to sign everything.

It's all chip and signature here.

Apparently not where I live, in South Dakota. The machines ask for my pin every time.

Edit: I just figured out why. My bank is apparently providing the chip and pin functionality.

What bank do you use? I've tried several times to get any of my cards switch from signature to pin with nothing but confusion from my banks. "But a pin is only for debit cards" is the typical response.

The US doesn't have chip-and-pin, we have chip-and-sign.

Chip-and-pin provides effective two-factor authentication (something you have, something you know) while chip-and-sign is only single-factor authentication. There is no way to check signatures in real-time (or even at all, really).

Pretty much every store I go to, I use the chip and then enter my pin. I haven't had to sign in over a year. I'm in South Dakota.

Edit: I just figured out why. My bank is apparently providing the chip and pin functionality.

Lucky you. Not having the chip severely reduces security (it can no longer prevent card theft, only cloning).

Frankly it also precludes the idea of a "duress pin" that calls the cops, which should be a thing if it isn't.

Its not just desire to avoid spending the money to provide chip+pin systems

Most Americans have many credit cards, unlike consumers in Europe, for example, where chip+pin is the norm.

US banks and credit card companies worried that Americans wouldn't be able to remember 6 different PINs for 6 different cards. So, they prefer eating the overhead of fraudulent charges rather than potentially reducing the number of credit cards (and profit) each consumer uses

Negative externalities. The cost of poor security isn't included in the price of an Android phone but it's paid for by society.

Libertarianism doesn't have a good answer for economic externalities.

Their answer is supposed to be perfect economic information and all actors acting rationally and fully informed in all transactions.

We have seen cultures adopt and change wildly, quickly, and fundamentally - just look at Russia, China, Japan, and Germany in the last 100 years - but the real libertarian breakthrough would be a reproducible way to shift a nations conscience to perfect information and absolute rationality in all business affairs.

Libertarian view is essentially 1) all negative externalities are some kind of property/personal infringement, 2) the same values that urge regulation also urge externality-free purchasing preferences, 3) people free of large tax/regulatory burdens have an easier time fixing social problems, 4) sometimes the externality is worth bearing (e.g. it may be worth temporary security problems to get a billion smartphones into the developing world now.)

I found these pretty easily by googling 'mises' and 'externalities' and while I could debate the specifics of the points, they seem to be just as legitimate an answer as regulation, which we know has its own negative externalities.

Reply on news.ycombinator.com