The endless browser wars

Chrome, of course, is Google's proprietary browser, bundled with Android and widely installed on other systems as well. The Chrome browser, though, is built on top of Chromium, which is an open-source project; in theory, anybody can build Chromium and get a browser of nearly equal capability, minus perhaps some proprietary DRM modules. In practice, Chromium users are a tiny fraction of the browser-using population, while Chrome becomes increasingly dominant. Current estimates suggest that 60-70% of web users are running on Chrome.

Chromium users do exist, though, and many Linux distributions package a version of the Chromium browser; it's a way to deal with the increasing number of "only works on Chrome" web sites without having to run proprietary code.

Or so it seems. Much of what appears to be Chrome (or Chromium) functionality is, in truth, provided by servers in Google's data centers. These include bookmark synchronization, the safe-browsing feature, search suggestions, spell-checking, and more. These features are not part of Chromium, but Google has long provided API keys for distributors of Chromium builds to use, ensuring that Chromium users had equal access to them.

That era is coming to an end, though. On January 15, the Chromium blog carried this brief notice that, as of March 15, non-Chrome builds of Chromium would lose access to these APIs. The loss of the bookmark-synchronization API, in particular, has drawn a fair amount of attention, but there are quite a few others that, it seems, will be restricted as well. After that date, users wanting to use those features will have to run Chrome to do so.

In other words, as of March 15, Chromium-based browsers will become rather less capable than they were the day before; this will reduce the value of Chromium to many of its users. Some of them will certainly throw in the towel and just install Chrome instead. Anticipating this, distributors are already wondering whether packaging Chromium (evidently not the easiest of tasks) is still worth the effort. Longtime Fedora developer Tom Callaway, for example, posted a Twitter thread in which he said: "I am seriously reconsidering whether there is any value in a crippled version of Chromium remaining in Fedora/EPEL".

This concern goes far beyond Fedora. The openSUSE community is currently discussing whether shipping Chromium still makes sense. The Arch Linux Chromium maintainer has stated his intent to drop the package if Chromium cannot be made to work with services like synchronization. Eric Hameleers, who provides Chromium packages for Slackware, doesn't want to continue if this change causes users to switch to something else. And so on.

There is, of course, an alternative to dropping Chromium that Callaway hinted at: "The official Chrome API keys which will permit this usage have been known since 2013 (they're embedded in every Chrome binary). It would be terrible if everyone used them instead." Taking that approach has been discussed on some distribution lists, but it seems unlikely that anybody will try it. It is an uncertain path, in that Google could invalidate the keys — though that would involve force-upgrading a lot of Chrome users. But it's even more uncertain in a legal sense; there are likely to be few volunteers to find out how Google would respond to such a move among the established distributors.

The unhappiness emanating from Chromium users who are about to lose features is understandable. But this move on Google's part is just highlighting a situation that has existed for years already: you might use Chromium as a way of avoiding proprietary software, but if you use Chromium with features like synchronization, that objective has not been met. Chromium has taken a path similar to Android's; there is a core built with free software, but getting its full functionality requires accepting layers of proprietary code on top of it. The fact that said code is running on a remote server somewhere does not really change that situation.

Many of us run free software — and avoid proprietary software — because we want to remain in control of our systems. Free software can be counted on to not disappear at inopportune times; proprietary software works at the whim of its owner and has no such guarantee. The stripping of functionality from Chromium builds is just another example of an owner indulging a whim and taking away features that they no longer wish to make available.

Meanwhile, smug Firefox users are able to use Firefox Sync with no impending interruption in service. It is worth noting that this service, too, could be withdrawn at any time, but Firefox at least allows the use of alternative servers, so concerned users need not be dependent on the continued existence and good will of Mozilla. The server-side code is available for anybody wanting to take that approach.

The larger problem, though, is that it's not at all clear that Firefox will remain a viable alternative to Chrome. Its market share has been falling for years, and not everybody is pleased with the directions that the Mozilla Foundation has taken. The creators of web sites have responded by not caring about Firefox; having to retry broken web sites in Chrome is a ritual that many Firefox users have had to get used to. It's not surprising that users give up and just run Chrome from the outset.

This is not a great trajectory. A lot of effort went into wresting the web from a proprietary browser; we should really know better than to allow ourselves to get into that situation again. Ironically, Google might have helped in this regard by stripping some non-free components from Chromium; users will now be more aware of their exposure and might just be more motivated to support a free alternative. That all depends on fully free browsers remaining viable, though, and that is unlikely to happen if we all just give up and run Chrome.