The Trouble with Treble

As most of you are probably aware, this past weekend the world was attacked by worms.

Alas, this is not a reference to “Tremors”.

Rather, this refers to the WannaCry worm, powered by an NSA-developed Windows exploit that was released by the Shadow Brokers. While WannaCry is distinctive in terms of its reach and attack vector, in the end, it’s “just” a piece of ransomware, demanding some Bitcoin in exchange for unlocking files that the ransomware encrypted. Many organizations were affected, including some hospital chains, leaving open the possibility that WannaCry has directly caused some deaths.

There, but for the grace of $DEITY, goes Android.

After all, Android powers more devices than does Windows. While this specific worm is Windows-specific, someday, somebody is going to launch a mass attack against Android. The good news is that Android has been a huge success. The bad news is that Android has been a huge success and as a result has a target painted on its back.

Matt Blaze’s security advice has not changed after this ransomware attack: backup, patch, and turn off unneeded features. Unfortunately, Android suffers on all three:

• Android itself has no user-accessible backup mechanism (what it claims is “backup” is really disaster recovery, and ideally ransomware would not qualify as a disaster)

• Neither Google nor device manufacturers want to make it easy for you to turn off unneeded features, as while you might not need them, they want them on, as part of monitoring your actions

• Android overall has had a terrible track record of devices getting any sort of security patch, let alone be able to get one 10-15 years after an OS release (akin to Microsoft releasing patches for XP, as they did this weekend)

The latter issue is where Treble comes into play.

The Base of Treble

On Friday, as WannaCry was starting its wormly wave of woe, Google announced Project Treble.

In a nutshell, Android is stealing a page from the late Firefox OS, going with a three-tier architecture:

• Vendor code, adhering to a specification and Vendor Test Suite, powers…

• The Android OS framework code, which adheres to the CDD specification and Compatibility Test Suite, which powers…

• Ordinary Android apps, which rely on those specifications and test suites so that apps can run successfully on semi-arbitrary Android hardware

The idea is that isolating vendor-specific code from the core OS framework means that the framework can be updated separately.

Android O implements Treble, so all Android O devices (and beyond) should work this way.

This is clearly an improvement in terms of the “patch” step of security. With Treble, it will now be easier for manufacturers to ship updated Android bits that fix bugs, including security bugs.

I Know Not This “Vendor” Of Which You Speak

The Google blog post does not say, exactly, who the “vendor” is with respect to the Vendor Test Suite and the “vendor implementation”. One might think that a vendor is a device manufacturer.

This quote from the post, though, suggests otherwise:

With a stable vendor interface providing access to the hardware-specific parts of Android, device makers can choose to deliver a new Android release to consumers by just updating the Android OS framework without any additional work required from the silicon manufacturers:

The phrase “silicon manufacturers” usually refers to those making the chipsets that power Android devices. In other words, it usually refers to Qualcomm, though other chipset manufacturers exist. Sometimes, a device manufacturer develops their own chipsets. Samsung, for example, uses both Qualcomm chipset and develops their own (Exynos).

If a Treble Fell in a Forest, and Nobody Distributed It, Does It Really Exist?

Treble seems to assume that the “Android OS framework” — everything between the apps and the “vendor implementation” — is unchanged and can be distributed without modifications.

That is not especially realistic. Device manufacturers certainly have changed what would go in the “Android OS framework”, for everything from legacy multi-window to having custom omnipresent sliding side-panels. If anything, the silicon manufacturer code tends to be more stable, though it too can have security flaws.

If the “Android OS framework” needs customization by device manufacturers, then we are back where we started, albeit with perhaps a little less work on behalf of those manufacturers.

And, as Ron Amodeo of Ars Technica points out, that’s not especially realistic either:

Updating Android will still be costly because OEMs and carriers will still be in the loop, and, because updating a device has a negative effect on companies’ bottom lines, they’re not motivated to actually do it.

I am Altering the Deal. Pray I Don’t Alter It Any Further.

One way that Google could address this is by contract. Perhaps not for Android O, but some down-the-road version (e.g., Android R), the contract for licensing the Play Store and other Google proprietary apps might require that manufacturers not modify the “Android OS framework”. At that point, Google might have a way of shipping updates to that framework without involving device manufacturers or carriers.

Then, the question is: how well will that work?

On the one hand, we have plenty of experience in desktop OSes where a software patch breaks things. What happens if the “Android OS framework” rolls out and bricks millions of devices? Or, what happens if the “Android OS framework” bricks certain enterprise-developed apps?

On the other hand, if contract terms prohibit the likes of Samsung from shipping custom Android OS versions, will they continue to support Android? Might they support Android, but instead form some other coalition of manufacturers that eschews the Google proprietary code, enlisting existing manufacturers who do just that (e.g., Amazon).

From the standpoint of app developers, how much will this cause us to have to deal with yet more combinations of possible devices to have to work with? “OK, so this device runs Android 8.0.1 with Framework 14.2, and that particular combination needs Workaround X…”?

Hope Springs Eternal (Begging the Questions: Who is Hope, and Why Was Eternal In Jail?)

While I am being pessimistic, I do not want to discount Treble. A lot of the Treble details have yet to be revealed. Nothing of what I have written here is especially insightful — I have little doubt that the engineers who built Treble have been wrestling with these and other issues. With luck, when the full Treble details are released, some of the concerns here will be addressed in one form or fashion.

Treble is a step forward. How far of a step has yet to be determined.