Linux users are more likely than most to be familiar with Chromium, Google’s the free and open source web project that serves as the basis for their wildly popular Chrome. Since the project’s inception over a decade ago, users have been able to compile the BSD licensed code into a browser that’s almost the same as the closed-source Chrome. As such, most distributions offer their own package for the browser and some even include it in the base install. Unfortunately, that may be changing soon.
A post made earlier this month to the official Chromium Blog explained that an audit had determined “third-party Chromium based browsers” were using APIs that were intended only for Google’s internal use. In response, any browser attempting to access features such as Chrome Sync with an unofficial API key would be prevented from doing so after March 15th.
To the average Chromium user, this doesn’t sound like much of a problem. In fact, you might even assume it doesn’t apply to you. The language used in the post makes it sound like Google is referring to browsers which are spun off of the Chromium codebase, and at least in part, they are. But the search giant is also using this opportunity to codify their belief that the only official Chromium builds are the ones that they provide themselves. With that simple change, anyone using a distribution-specific build of Chromium just became persona non grata.
Unhappy with the idea of giving users a semi-functional browser, the Chromium maintainers for several distributions such as Arch Linux and Fedora have said they’re considering pulling the package from their respective repositories altogether. With a Google representative confirming the change is coming regardless of community feedback, it seems likely more distributions will follow suit.
Broken Promises
For most users, this is little more than a minor annoyance. Sure it was nice to have Chromium available in your distribution’s package repository, but popping over to the official website and downloading the latest stable is hardly the end of the world. Those running older machines may be in for a rude awaking however, as Google no longer makes 32-bit builds available. They also don’t provide a native BSD build at the time of this writing. For those users, it may be time to give Firefox a shot.
The people that are actually hurt the most by this decision are the ones who’ve spent years packaging Google’s open source browser. They’ve put in considerable time and effort to compile, distribute, and support a custom built Chromium, only to have Google pull the rug out from under them without so much as a call for comments. You might think that’s just one of the risks you take on when supporting a BSD-licensed project, which by definition offers no implied warranty, but in this case things are a little less cut and dry.
As developer Eric Hameleers explains in a lengthy blog post, he was supplied with a dedicated API key for his Slackware Chromium builds by the Google Chrome Team in 2013. He was granted “official permission to include Google API keys in your packages”, and was told that the usage quota for that particular key would be increased “in an effort to adequately support your users”, as normally the key he was assigned would only be for personal development use. Evangelos Foutras, the maintainer for the Arch Linux Chromium package, has indicated he received a similar email at around the same time.
There’s no question that Google understood how these individuals intended to use their API keys. They were even given special dispensation to circumvent API limits, a decision which must have gone through several layers of approvals. The framework for giving distribution-specific Chromium packages the same level of functionality as official builds was agreed upon and put into operation years ago, that much is certain. What’s less clear is what happened internally at Google that prompted them to terminate these existing agreements with little more than a vague blog post to serve as notification.
Keys to the Kingdom
We may never get the full story in this situation, and since a Google representative has made it clear that the decision is final, there’s not much sense fretting over it. Ultimately, Google is going to run their business as they see fit. If they think allowing unofficial builds of Chromium to tap into their cloud services such as Sync isn’t worth it, it’s their prerogative to block them. Those who believe firmly in the concept of free and open source software would tell you that this is a perfect example of why you should have been using Firefox or another truly libre browser in the first place.
On the other hand, hackers as a whole aren’t overly fond of being told what to do. Finding unconventional solutions to arbitrary limitations is the name of the game, so what options exist for those who can’t or won’t use the official Chromium builds from Google? Foutras has put forward an interesting suggestion that, at least on the surface, doesn’t seem to run afoul of Google’s Terms of Service. Though that certainly doesn’t mean they’ll be happy about it.
Put simply, there doesn’t appear to be any technical reason that a third-party build of Chromium couldn’t simply use the official API keys that ship with Chrome. These keys have been publicly known since at least 2012, and in all that time, have never been changed. While actually distributing a build of Chromium using these keys may be enough of a gray area that mainline distributions would steer clear, a separate script that executes on the end-user’s machine and slips the keys into the relevant environment variables may be a loophole Google wasn’t expecting.
