LWN: Comments on "O-MG, the Developer Preview of Android O is here! (Android Developers Blog)"

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

micka — Thu, 30 Mar 2017 08:16:52 +0000

> Android Pay uninstalling itself when the device is rooted, for example, rooting a device is no longer sufficient to be able to spend the user's money.

Well, it's sufficient to prevent the user from spending their own money. Spending it that way at least.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

haldean — Wed, 29 Mar 2017 22:22:16 +0000

What I heard a lot when working on the Android team was that, if a rooted phone were trusted, the number of devices that had been rooted by exploits against the user's will would vastly outnumber the devices that had been rooted by their owner. The idea behind not trusting rooted devices is to make it a less attractive target, and to decrease the attack surfaces of devices that do end up rooted; with Android Pay uninstalling itself when the device is rooted, for example, rooting a device is no longer sufficient to be able to spend the user's money.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

pizza — Sun, 26 Mar 2017 11:21:27 +0000

This is one area in which Android's fragmentation works to our advantage. There are just so many versions out there, on countless models, so it's not like stupid "secure" app writers can really lock things down to specific ones, much less require a given software configuration of a handset.

(IIUC, they can't tell the difference between a "rooted" handset which disallows root for a given app, vs one that's not rooted at all. This is even more true for the bootloader..)

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

MattJD — Sun, 26 Mar 2017 03:28:57 +0000

> I'd love to share your optimism that any "service provider", particularly any in the financial sector, would be remotely interested in giving me such an option... Banks still tell their customers that non-rooted Android is somehow "secure" and therefore required for their nightmare of a custom proprietary two-factor app. Never mind it's very old and unpatched.

True, that is a very lofty goal. I doubt they'd invest any money in trying to verify this, as Google provides the simple answer (even if there are glaring security holes in the old version of Android running on $handset from $manufacture, patched in latest $third_party_rom). I do think we'd have a better chance convincing them to use a different method if we came to them with one in hand, versus demanding they develop one. I certainly don't, and I've tried putting some brain cycles to the problem. But I can hope.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

seneca6 — Sat, 25 Mar 2017 22:58:08 +0000

> What I think we need is a better way of telling service providers, yes this frankenstein of a software stack I'm running is correct, and no I've haven't been hacked.

I'd love to share your optimism that any "service provider", particularly any in the financial sector, would be remotely interested in giving me such an option... Banks still tell their customers that non-rooted Android is somehow "secure" and therefore required for their nightmare of a custom proprietary two-factor app. Never mind it's very old and unpatched.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

kevincox — Fri, 24 Mar 2017 11:29:01 +0000

You're right, I'm focusing on the downside that Google can't push updates to all devices. If all device manufactures took responsibility over their modifications and either re-basing them on top of newer versions (whether feature or path releases) or patching security issues themselves this wouldn't be an issue. This also loops back into the fact that you should consider future updates when you purchase a device.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

pabs — Fri, 24 Mar 2017 07:42:30 +0000

Perhaps your device is vulnerable to the SamDunk issue?

https://github.com/beaups/SamsungCID

More possible exploits here:

https://wiki.debian.org/Exploits

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

NightMonkey — Thu, 23 Mar 2017 21:51:49 +0000

Yes. And, unlike many phones, no bug (aka "exploit") has been found which facilitates me fully owning the phone I have now fully paid for. (See also the many"Farmers hacking tractors with Ukranian Firmware" stories like https://boingboing.net/2017/03/22/make-hay-while-the-sun-... )

The Linux Kernel may be free, but in the Android universe, it is a free island in a sea of DRM and proprietary, closed, unfree Java blobs and locked bootloaders. It's like "owning" a car, except for the steering wheel, accelerator, gear shift and brakes. But, Google is an advertising company, so it makes logical, if amoral, sense.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

tuna — Thu, 23 Mar 2017 18:22:05 +0000

It makes it possible for device vendors to create unique and new types of hardware without having to ask Google to put in support in upstream. So in a lot of ways it is a very positive aspect of the Android eco system.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

kevincox — Thu, 23 Mar 2017 11:19:25 +0000

This is unfortunately true. Updates are a feature of the device and you should choose what device to buy based on the update cycle they provide. Also unfortunate is that often vendors are not clear about any sort of update promises. (The only one I can find is a promised minimum life-cycle for Nexus and Pixel devices)

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

thestinger — Thu, 23 Mar 2017 02:00:12 +0000

Of course you're still not going to be meant to have a working Android Pay, because their goal is having it only work with Google-approved operating systems. SafetyNet is not primarily a security feature. It's also going to end up requiring exploits to bypass it once they turn it into proper remote attestation which might be years away but is probably going to arrive.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

thestinger — Thu, 23 Mar 2017 01:58:41 +0000

Nexus and Pixel devices support locking the bootloader with alternate operating systems and using full verified boot. Making a signed production build of AOSP with custom keys is straightforward. There is already effectively support for certificates for fastboot, it's just implicit since boot.img and recovery.img are signed and boot.img is able to verify all of system.img and vendor.img via dm-verity. Of course you need to do a proper production build and sign everything with the relevant scripts followed by locking the bootloader. You then update it via `adb sideload` of update packages signed with the same keys to recovery (assuming you're not going to be setting up an OTA update server).

There are instructions on making proper signed builds at https://copperhead.co/android/docs/building. A patch needs to be backported to change the default make_key hash algorithm away from sha1 if you're building AOSP rather than CopperheadOS though, and you'll need to deal with the vendor blobs using android-prepare-vendor which supports proper signed builds where vendor.img is verified.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

MattJD — Thu, 23 Mar 2017 01:22:36 +0000

> I don't understand that problem. Surely, Android Pay doesn't rely on the cooperation of user devices to ensure merchants actually get paid following a transaction.
>Also: apps don't feel trust, people do. When a program implements a trust policy it does so as an agent, acting in the interest of a human being. So who is it that doesn't trust a modified system? It can't be the device owner: that's the one who modified the device in the first place, so of course they trust those modifications. Therefore, apps written to serve their users should trust them, too.

I don't think it's (necessarily) because Google is trying to restrict users here, it's that users are not great at security. Android Pay loads your credit card details into the phone in a way that anyone can make a transaction against if they appear to be a merchant. For those of us on LWN, unlocking your bootloader (disclaimer: mines unlocked) isn't a bad thing, and we (in theory) know how to protect ourselves.

Many users don't know or care about this (they just want it to work, and rely on Google to protect them), and an unlocked bootloader may be a sign of a compromised device. What I think we need is a better way of telling service providers, yes this frankenstein of a software stack I'm running is correct, and no I've haven't been hacked. Until then, they rely on you running what they think should be running as a signal everything is fine. It is especially hard/impossible when the attacker has physical control of the device.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

lsl — Wed, 22 Mar 2017 21:33:29 +0000

I don't understand that problem. Surely, Android Pay doesn't rely on the cooperation of user devices to ensure merchants actually get paid following a transaction.

Also: apps don't feel trust, people do. When a program implements a trust policy it does so as an agent, acting in the interest of a human being. So who is it that doesn't trust a modified system? It can't be the device owner: that's the one who modified the device in the first place, so of course they trust those modifications. Therefore, apps written to serve their users should trust them, too.

I can see why apps written to benefit *someone else* at the detriment of the user might not want to extend trust to the latter. I don't see why these shady and morally corrupt practices should see any kind of support, though.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

tuna — Wed, 22 Mar 2017 21:27:15 +0000

"Will Google address the release fragmentation and poor update history of Android releases on devices, with Android O by forcing vendors to ship and update it or will Android O bring literally zero benefits to end users and consumers alike in the Android ecosystem?"

No. The whole point of Android for device manufacturers is that it gives them the freedom to use ASOP to create any system that they like. If you want updates and upgrades buy from vendors that have delivered that for their devices.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

Flukas88 — Wed, 22 Mar 2017 12:29:54 +0000

How come?
Locked bootloader?

Android O puts a big priority on improving a user's battery life

rakoenig — Wed, 22 Mar 2017 07:34:52 +0000

Does that mean you feel less exhausted after spending the whole day looking at your smartphone? ;-)

SCNR this one...

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

johannbg — Wed, 22 Mar 2017 06:49:13 +0000

I dont get what's supposed to be so much O-MG about Android O other than O-MG I will never be able to run this release on my devices despite those devices being powerful enough to run this hardware wise for years to come thanks to Google and it's vendors.

Does anyone know if Google has finally caught up with mainline or will be shipping Android O with old exploitable kernel that is million patches and changes behind mainline like Google does today and we be forced to watch the same stagnation with repeated slides over and over again from Jon and Greg for another decade?

Will Google address the release fragmentation and poor update history of Android releases on devices, with Android O by forcing vendors to ship and update it or will Android O bring literally zero benefits to end users and consumers alike in the Android ecosystem?

Will people really have to start pushing for legislation to start addressing this problem with huge fines to Google and it's vendors because Google and it's vendors wont wake up and smell the coffee in the 21 century?

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

tscs37 — Wed, 22 Mar 2017 06:28:58 +0000

Android should make more use of security processors when present in the phone.

The problem with a rooted phone is that the App can no longer trust any API or test it performs with good reliability, using a security processor is no problem even on a rooted system, especially if the secrets have been stored pre-root.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

gutschke — Tue, 21 Mar 2017 23:28:55 +0000

That's one of the big reasons why I would never buy anything other than a Nexus (or these days Pixel) phone.

The ability to unlock the bootloader and the guarantee of monthly security updates is worth a lot to me.

Of course, Google partially counter-acts these benefits by conflating unlocking with rooting, and by making popular apps such as Android Pay incompatible with an unlocked boot loader. This ironically means that instead of making things more secure, for the first time in a few years, I have rooted my device again. With a rooted device, I can hide the unlocked bootloader from AndroidPay.

I wish, Google instead spent some thought on how to rework security so that we get the benefits of an unlocked bootloader and of root access without also compromising security. We already have client certificates for ADB; maybe Fastboot needs the same. And maybe this information can also be propagated to a Google-provided "sudo" app.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

flammon — Tue, 21 Mar 2017 22:37:19 +0000

I'm in the same boat with a Note 3. It has plenty of life with 3GB of RAM but sucks on Lollipop.

O-MG, the Developer Preview of Android O is here! (Android Developers Blog)

NightMonkey — Tue, 21 Mar 2017 22:21:07 +0000

If only I could root my Samsung Galaxy Note 4, I'd be really excited. :/ Instead, Verizon will artificially stop it's useful life with Marshmallow (Android 6), and there's nothing I can do about it. :( </vent>