Lessons in Vendor Lock-in: Google and Huawei

What happens when you're locked in to a vendor that's too big to fail, butis on the opposite end of a trade war?

The story of Google no longer giving Huawei access to Android updates is stilldeveloping, so by the time you read this, the situation may have changed. At themoment, Google has granted Huawei a 90-day window whereby it will have access toAndroid OS updates, the Google Play store and other Google-owned Android assets.After that point, due to trade negotiations between the US and China, Huawei nolonger will have that access.

Whether or not this new policy between Google and Huawei is still in place when thisarticle is published, this article isn't about trade policy or politics. Instead,I'm going to examine this as a new lesson in vendor lock-in that I don't think many haveconsidered before: what happens when the vendor you rely on is forced by itsgovernment to stop you from being a customer?

Vendor lock-in isn't new, but until the last decade or so, it generally was thoughtof by engineers as a bad thing. Companies would take advantage the fact that youused one of their products that was legitimately good to use the rest of theirproducts that may or may not be as good as those from their competitors. Peoplefelt the pain of being stuck with inferior products and rebelled.

These days, a lot of engineers have entered the industry in a world where the newgiants of lock-in are still growing and have only flexed their lock-in powers abit. Many engineers shrug off worries about choosing a solution that requires you touse only products from one vendor, in particular if that vendor is a large enoughcompany. There is an assumption that those companies are too big ever to fail, sowhy would it matter that you rely on them (as many companies in the cloud do) forevery aspect of their technology stack?

Many people who justify lock-in with companies who are too big to fail point toall of the even more important companies who use that vendor who would have evenbigger problems should that vendor have a major bug, outage or go out ofbusiness. It would take so much effort to use cross-platform technologies, thethinking goes, when the risk of going all-in with a single vendor seems sosmall.

Huawei also probably figured (rightly) that Google and Android were too big tofail. Why worry about the risks of being beholden to a single vendor for your OSwhen that vendor was used by other large companies and would have even biggerproblems if the vendor went away?

Google held a particularly interesting and subtle bit of lock-in power over Huawei(and any phone manufacturer who uses Android)—the power of software updates. Thisform of lock-in isn't new. Microsoft famously used the fact that software updatesin Microsoft Office cost money (naturally, as it was selling that software)along with the fact that new versions of Office had this tendency to breakbackward compatibility with older document formats to encourage everyone toupgrade. The common scenario was that the upper-level folks in the office would get brand-new,cutting-edge computers with the latest version of Office on them. They would startsaving new documents and sharing them, and everyone else wouldn't be able to open them. Itended up being easier to upgrade everyone's version of Office than to have thebossesremember to save new documents in old formats every time.

The main difference with Android is that updates are critical not because ofcompatibility, but for security. Without OS updates, your phone ultimatelywill become vulnerable to exploits that attackers continue to find in your software. TheAndroid OS that ships on phones is proprietary and therefore requires permissionfrom Google to get those updates.

Many people still don't think of the Android OS as proprietary software. Althoughpeople talk about the FOSS underpinnings in Android, only people who go to theextra effort of getting a pure-FOSS version of Android, like LineageOS, on theirphones actually experience it. The version of Android most people tend to use has abit of FOSS in the center, surrounded by proprietary Google Apps code.

It's this Google Apps code that gives Google the kind of powerful leverage over acompany like Huawei. With traditional Android releases, Google controls access toOS updates including security updates. All of this software is signed with Google'ssigning keys. This system is built with security in mind—attackers can't easilybuild their own OS update to install on your phone—but it also has a convenientside effect of giving Google control over the updates.

What's more, the Google Apps suite isn't just a convenient way to load Gmail orGoogle Docs, it also includes the tight integration with your Google account and theGoogle Play store. Without those hooks, you don't have access to the giant libraryof applications that everyone expects to use on their phones. As anyone with aLineageOS phone that uses F-Droid can attest, while a large number ofapplications are available in the F-Droid market, you can't expect to see those same appsas on Google Play. Although you can side-load some Google Play apps, manyapplications, such as Google Maps, behave differently without a Google account.Note that this control isn't unique to Google. Apple uses similar code-signingfeatures with similar restrictions on its own phones and app updates.

Without access to these OS updates, Huawei now will have to decide whether tocreate its own LineageOS-style Android fork or a whole new phone OS of itsown. In either case, it will have to abandon the Google Play Store ecosystem anduse F-Droid-style app repositories, or if it goes 100% alone, it will need to create acompletely new app ecosystem. If its engineers planned for this situation, thenthey likely areworking on this plan right now; otherwise, they are all presumably scrambling toaddress an event that "should never happen". Here's hoping that if you findyourself in a similar case of vendor lock-in with an overseas company that's toobig to fail, you never get caught in the middle of a trade war.

Kyle Rankin is a Tech Editor and columnist atLinux Journal and the Chief Security Officer at Purism. He is the author ofLinux Hardening in Hostile Networks,DevOps Troubleshooting,The Official Ubuntu Server Book,Knoppix Hacks,Knoppix Pocket Reference,Linux MultimediaHacks andUbuntu Hacks, and also a contributor to a number of other O'Reilly books. Rankin speaks frequently on security and open-source software including atBsidesLV, O'Reilly Security Conference, OSCON, SCALE, CactusCon, Linux World Expo and Penguicon. You can follow him at @kylerankin.