Home & Office

Linux distributors frustrated by Google's new Chromium web browser restrictions

Google changed the rules on the Chromium browser's APIs and Linux distributors are taking different approaches on what to do with the open-source browser.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

While Google Chrome is easily the most popular PC web browser, it's open-source big brother, Chromium, doesn't have that many users, but it's always had some fans on desktop Linux. Now, though, that love affair is in trouble.

Google claims it recently found un-named third-party Chromium-based browsers integrating Google cloud-based features, such as Chrome sync and Click to Call, that were intended only for Google Chrome users. In other words, "This meant that a small fraction of users could sign into their Google Account and store their personal Chrome sync data, such as bookmarks, not just with Google Chrome, but also with some third-party Chromium-based browsers."

Also: Best Linux Foundation classes

Google was not amused. 

Starting on March 15th, Google said it will limit access to many Chrome application programming interfaces (API) inside Chromium starting March 15, 2021. This means users using the Chromium web browser or any other web browser based on its open-source codebase won't be able to use most Google-specific API-enabled services. This includes the ability to sync Chrome bookmarks, check your spelling, find your contacts, translate text, and on and on.  

Many users aren't happy either now. Thom Holwerda, managing editor of OSNews, spoke for many when he wrote, Google's "not closing a security hole, they're just requiring that everyone use Chrome. Or to put it bluntly, they do not want you to access their Google API functionality without using proprietary software (Google Chrome)."

Developers can, once they jump through the necessary hoops to get API keys and an OAuth 2.0 client ID, get keys to these APIs. But, Google underlines, "that the keys you have now acquired are not for distribution purposes and must not be shared with other users."

In theory, a developer could pull the API keys out of mainline Chrome and maintain their Chromium's build Google functionality. However, that's just asking for a lawsuit. 

Besides, Jochen Eisinger, Google's Director of Engineering for Chrome Trust & Safety remarked on the Google Chromium developer group, "We won't remove the API from your key, but we'll limit the quota to the quota for development. ... this will make the keys unsuitable for production use." These "APIs were not designed to be used by third-party software, so short of a complete rewrite, there is unfortunately no [other] option."

So, where does that leave Linux distributors who've been bundling Chromium? Between a rock and a hard place. 

Porting Chromium to Linux is not trivial. Alan Pope, Canonical's community manager for Ubuntu Linux engineering service, explained why Canonical started shipping Chromium in an Ubuntu Snap container rather than in a DEB package:

Maintaining a single release of Chromium is a significant time investment for the Ubuntu Desktop Team working with the Ubuntu Security team to deliver updates to each stable release. As the teams support numerous stable releases of Ubuntu, the amount of work is compounded. Comparing this workload to other Linux distributions that have a single supported rolling release misses the nuance of supporting multiple Long Term Support (LTS) and non-LTS releases.

Google releases a new major version of Chromium every six weeks, with typically several minor versions to address security vulnerabilities in between. Every new stable version has to be built for each supported Ubuntu release − 16.04, 18.04, 19.04, and the upcoming 19.10 − and for all supported architectures (amd64, i386, arm, arm64).

While Snap has made this easier, it's still not easy. According to sources, Canonical has not decided yet whether it will support Chromium without the end-user support for the Google services specific APIs. 

Linux Mint recently started bundling its own Chromium browser. Mint leader Clement "Clem" Lefebvre is sticking with Chromium. "We're not going to do anything. We'll continue to package Chromium."

Red Hat's community Linux distro Fedora, however, was seriously considering dumping Chromium. Tom Callaway, Chromium's Fedora maintainer explained that it's because Google is "cutting off access to the Sync and "other Google Exclusive" APIs from all builds except Google Chrome. This will make the Fedora Chromium build significantly less functional (along with every other distro packaged Chromium)."

However, after consideration, Callaway explained "I never said I was going to remove Chromium from Fedora. I said I was seriously considering it, but after much thought, I decided that there were enough users who still wanted it, even without the functionality provided by the Google API." So, starting immediately, Fedora's version of Chromium no longer supports the soon to be depreciated APIs

Callaway really wishes Google would reconsider its position. But, he sees little chance of it. "What frustrates me," Calloway tweeted, "the most is how no one on the Chrome team understands the concept of open source community building. Nothing the Chr maintainers did ever hurt Chrome, they only ever made it stronger."

Other Linux distributions are edging closer to dumping Chromium. Arch Linux maintainers have thought about it, but, for now, they'll continue to keep Chromium around even after the March 15th deadline. 

Eric Hameleers, who maintains Chromium for Slackware Linux, is dropping Chromium. "I will not package and distribute a Chromium for Slackware if that package is crippled by the absence of login to Chrome Sync. I will not package a Chromium build with Google's own ID and secret embedded. Instead, I will do the right thing: advise people not to use Chrome but switch to Firefox."

With this move, Google has alienated code maintainers and developers at multiple Linux distributions. When Linux Chromium users discover the latest versions won't work as they have before, they'll be unhappy too. 

True, this is only a small number. But, it's leaving many others with a bad taste in their mouths over how Google failed the open-source community in this instance. That, in the end, will matter more than this move's immediate impact on programmers and end-users. 

Related Stories:

Editorial standards