Linux users are more likely than most to be familiar with Chromium, Google’s free, open source web project that underpins their incredibly popular Chrome. Since the project began more than a decade ago, users have been able to compile BSD licensed code into a browser that almost the same as closed source Chrome. As such, most distributions offer their own package for the browser and some even include it in the basic installation. Unfortunately, that may soon change.
A post made earlier this month on the official Chromium blog explained that an audit determined that “third-party browsers based on Chromium” were using APIs intended for internal Google use only. In response, any browser attempting to access features such as syncing Chrome with an unofficial API key would be prevented from doing so after March 15.
For the average Chromium user, this doesn’t seem like a big problem. In fact, you can even assume that it doesn’t apply to you. The language used in the post looks like Google is referring to browsers that are derived from the Chromium code base, and at least in part, they are. But the search giant is also using this opportunity to encode its belief that the only official Chromium compilations are the ones they provide themselves. With this simple change, anyone using a specific build of the Chromium distribution simply became persona non grata.
Dissatisfied with the idea of giving users a semi-functional browser, Chromium maintainers for various distributions, such as Arch Linux and Fedora said they are considering removing the package from their respective repositories. With a Google representative confirming that change is coming, regardless of community feedback, it appears that more distributions will follow suit.
Broken promises
For most users, this is little more than a minor hassle. Of course it was nice to have Chromium available in your distribution’s package repository, but going to the official website and downloading the latest stable version is hardly the end of the world. Those running older machines may have an unpleasant awakening, however, as Google no longer offers 32-bit builds. They also do not provide a native BSD build at the time of writing. For these users, it may be time to give Firefox a try.
The people who are most hurt by this decision are those who have spent years packaging Google’s open source browser. They invested considerable time and effort to compile, distribute and support a custom Chromium, only to have Google pull the rug out from under them without even asking for comments. You may think that this is just one of the risks you take when supporting a BSD licensed project, which by definition does not offer an implied warranty, but in this case things are a little less simple.
As developer Eric Hameleers explains in a lengthy blog post, he received a dedicated API key for his Slackware Chromium builds by the Google Chrome team in 2013. He received “official permission to include Google API keys in his packages” , and it was reported that the usage quota for that specific key would be increased “in an effort to offer adequate support to its users”, since normally the key assigned to it would be for personal development use only. Evangelos Foutras, the maintainer of the Arch Linux Chromium package, indicated that he received a similar email at the same time.
There is no doubt that Google understood how these individuals intended to use their API keys. They even received a special exemption to circumvent the limits of the API, a decision that must have passed through several layers of approvals. The framework for giving specific Chromium distribution packages the same level of functionality as the official builds was agreed and put into operation years ago, that’s for sure. What is less clear is what happened internally at Google that led them to terminate these existing contracts with little more than a vague blog post to serve as a notification.
Keys to the kingdom
We may never know the full story in this situation, and since a Google representative has made it clear that the decision is final, there is little point in worrying about it. Ultimately, Google will run its business the way it sees fit. If they feel it is not worth allowing unofficial Chromium builds to access their cloud services, such as Sync, it is their prerogative to block them. Those who firmly believe in the concept of free and open source software will say that this is a perfect example of why you should be using Firefox or another truly free browser.
Simply put, there doesn’t seem to be any technical reason why a third-party build of Chromium couldn’t simply use the official API keys that come with Chrome. These keys have been publicly known since at least 2012 and, in all that time, have never been changed. Although in fact distributing a Chromium build using these keys may be enough of a gray area for mainline distributions to avoid, a separate script that runs on the end user’s machine and places the keys in the relevant environment variables can be a loophole that Google didn’t expect.