What’s wrong with Chromium on Linux? Google at odds with package managers

Linux users are more likely than most to be familiar with Chromium, Google’s free and open source web project that forms the basis of their ever popular Chrome. Since the project started over ten years ago, users have been able to compile the BSD licensed code in a browser almost the same as Closed Source Chrome. As such, most distributions come with their own package for the browser and some even include it in the base installation. Unfortunately, that may soon change.

A post earlier this month on the official Chromium blog explained that an audit had determined that “third-party Chromium-based browsers” used APIs intended only for internal Google use. In response, any browser attempting to access features like Chrome Sync with an unofficial API key would be barred from doing so after March 15.

For the average Chromium user, this doesn’t seem like a problem. In fact, you might even assume that this doesn’t apply to you. The language used in the article gives the impression that Google is referring to browsers from the Chromium codebase, and at least in part, they are. But the research giant is also taking this opportunity to codify its belief that the only official versions of Chromium are the ones they buy. With this simple change, anyone using a distribution-specific version of Chromium has become persona non grata.

Dissatisfied with the idea of ​​giving users a semi-functional browser, the maintainers of Chromium for several distributions such as Arch Linux and Felt have stated that they plan to completely remove the package from their respective repositories. With a Google rep confirming the change is coming regardless of community feedback, it looks likely that more distributions will follow.

Broken promises

For most users, this is little more than a minor annoyance. Of course, it was nice to have Chromium available in your distro’s package repository, but going to the official site and downloading the latest stable version isn’t the end of the world. However, those running older machines are likely to wake up crudely, as Google no longer offers 32-bit versions. They also do not provide a native BSD build at the time of writing. For those users, it might be time to try Firefox.

The people who suffer most from this decision are those who spent years building Google’s open source browser. They’ve spent a lot of time and effort building, distributing, and supporting a custom Chromium, only for Google to pull the rug out from under them without a call for comment. You might think that’s just one of the risks you take when supporting a BSD licensed project, which by definition doesn’t offer any implied warranties, but in this case things are a little less straightforward.

As developer Eric Hameleers explains in a long blog post, the Google Chrome team provided him with a dedicated API key for his Slackware Chromium releases in 2013. He got “official permission to include Google API keys. in your packages ”, and said that the usage quota for that particular key would be increased“ in an effort to adequately support your users, ”as normally the key assigned to it would only be used for personal development. Evangelos Foutras, the maintainer of the Arch Linux Chromium package, said he received a similar email at around the same time.

There is no doubt that Google understood how these people intended to use their API keys. They even received a special waiver to bypass API limitations, a decision that had to go through multiple levels of approval. The framework for giving distribution-specific Chromium packages the same level of functionality as the official versions was agreed upon and put into service years ago, that’s for sure. What is less clear is what happened internally at Google that prompted them to end these existing deals with little more than a vague blog post to serve as a notification.

Keys to the kingdom

We may never get the full story in this situation, and since a Google representative made it clear that the decision is final, it doesn’t make much sense to worry about it. In the end, Google will run their business as they see fit. If they think that allowing unofficial versions of Chromium to tap into their cloud services like Sync isn’t worth it, it’s their prerogative to block them. Those who firmly believe in the concept of free and open source software will tell you that this is a perfect example of why you should have used Firefox or some other truly free browser in the first place.

On the other hand, hackers as a whole don’t really like being told what to do. Finding unconventional solutions to arbitrary limitations is the name of the game, so what options are there for those who can’t or won’t use Google’s official versions of Chromium? Foutras came up with an interesting suggestion that, at least at first glance, doesn’t seem to violate Google’s terms of service. Although that certainly doesn’t mean they’ll be happy about it.

Simply put, there doesn’t seem to be any technical reason why a third-party version of Chromium couldn’t just use the official API keys that come with Chrome. These keys have been known to the public since at least 2012 and have never been changed during this time. So what to do about it distribute a version of Chromium using these keys can be enough gray area for major distros to avoid doing this, a separate script that runs on the end user’s machine and slips the keys into the relevant environment variables can be a loophole that Google did not expect.