What’s the matter with Chromium on Linux? Google on a Package Maintenance Opportunity

Linux users are more likely to be familiar with Chromium, Google’s, the free and open source web project that forms the basis of their hugely popular Chrome. Since the start of the project more than a decade ago, users have been able to compile the BSD licensed code into a browser almost 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 installation. Unfortunately, that may soon change.

An article that appeared on the official Chromium Blog earlier this month explains that an audit found that ‘third-party Chromium browsers’ used APIs intended for Google’s internal use only. In response, every browser that attempts to access features like Chrome Sync after March 15th with an unofficial API key.

To the average Chromium user, this does not sound like a big deal. In fact, you may even assume that it does not apply to you. The language used in the post makes it sound as if Google is referring to browsers cut off from the Chromium base, and at least in part. But the search giant is also using this opportunity to codify their belief that the only official Chromium buildings are the ones they supply themselves. With the simple change, everyone who uses a distribution-specific form of Chromium has just become persona non grata.

Unfortunately with the idea of ​​giving users a semi-functional browser, the Chromium maintainers for various distributions like Arch Linux and Fedora said they were considering pulling the package completely out of their respective repositories. As a Google representative confirms that the change is coming, regardless of community feedback, it appears that more distributions will follow suit.

Broken promises

For most users, this is just a minor annoyance. It was certainly nice to have Chromium available in the package repository of your distribution, but going to the official website and downloading the latest stable is hardly the end of the world. However, those using older machines may be rudely awakened as Google no longer makes 32-bit constructions available. Nor do they offer an indigenous BSD build-up at the time of this writing. For users, it may be time to give Firefox a try.

Soon a reminder of simpler times?

The people who are actually most hurt by this decision are the ones who have been packing Google’s open source browser for years. They put a lot of time and effort into compiling, distributing and supporting a custom-built Chromium, only to have Google pull the rug out from under them without asking so much for comment. You may think that this is just one of the risks you take when supporting a BSD-licensed project, which by definition offers no tacit guarantee, but in this case, things are a little less dry and dry.

As developer Eric Hameleers explains in a lengthy blog post, the Google Chrome team provided a dedicated API key for its Slackware Chromium constructions in 2013. He “obtained official permission to include Google API keys in your packages”, and was told that the usage quota for the key in question would be increased “in an effort to adequately support your users”, since the key provided he was awarded, would normally be for personal development only. Evangelos Foutras, the maintainer of the Arch Linux Chromium package, indicated that he received an email around the same time.

There is no doubt that Google understands how these individuals intended to use their API keys. They even got special dispensation to circumvent API limits, a decision that should have gone through several approval layers. It was agreed years ago on the framework to give distribution-specific Chromium packages the same functionality as official constructions, and this is very certain. What is less clear is what happened internally at Google that led them to terminate these existing agreements with just more than a vague blog post to serve as a notice.

Keys to the Kingdom

We can never get the full story in this situation, and because a Google representative made it clear that the decision is final, there is not much point in it. Eventually, Google will run their business as they see fit. If they think it’s not worth it to use unofficial Chromium buildings in their cloud services like Sync, it’s their right to block it. 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 another real libre browser in the first place.

On the other hand, hackers are not too fond of saying what they should do at all. This is the name of the game to find unconventional solutions to arbitrary constraints, and what options exist for those who do not know the official Chromium builds of Google or not? Foutras has made an interesting suggestion that, at least at first glance, does not seem to detract from Google’s Terms of Service. Although it certainly does not mean that they will be happy about it.

Simply put, there seems to be no technical reason why a third-party Chromium could not just use the official API keys that come with Chrome. These keys have been publicly known since at least 2012, and in all that time, they have never changed. While actually distribution a build up of Chromium using these keys may be enough of a gray area that will remove the mainline distribution, a separate script running on the end user’s machine and moving the keys in the relevant environmental variables may be a gap which Google did not expect.

Source