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.
