Implementors
Tags: browsers, rendering, engines, google
Published: 2020-07-10 10:06:38

---
title: Implementors
published: true
date: 2020-07-09 08:54:27 UTC
tags: browsers,rendering,engines,google
canonical_url: https://adactio.com/journal/17114
---

The latest newsletter from [The History Of The Web](https://thehistoryoftheweb.com/) is a good one: [The Browser Engine That Could](https://thehistoryoftheweb.com/how-a-browser-engine-dominates-the-market/). It’s all about the history of browsers and more specifically, rendering engines.

Jay quotes from a 1992 email by Tim Berners-Lee when there was real concern about having too _many_ different browsers. But as history played out, the concern shifted to having too _few_ different browsers.

I wrote about this—back when Edge switched to using Chromium—in a post called [<cite>Unity</cite>](https://adactio.com/journal/16331) where I compared it to political parties:

> If you have hundreds of different political parties, that’s not ideal. But if you only have _one_ political party, that’s very bad indeed!

I talked about this some more with [Brian](https://bkardell.com/) and [Stuart](https://www.kryogenix.org/) on the Igalia Chats podcast: [<cite>Web Ecosystem Health</cite>](https://www.igalia.com/chats/ecosystem-health) (here’s [the mp3 file](https://www.igalia.com/downloads/interviews/ecosystem-health.mp3)).

In the discussion we dive deeper into the naunces of browser engine diversity; how it’s not the numbers that matter, but representation. The danger with one dominant rendering engine is that it would reflect one dominant set of priorities.

I think we’re starting to see this kind of battle between different sets of priorities playing out in the browser rendering engine landscape.

Webkit published [a list of APIs they won’t be implementing](https://webkit.org/tracking-prevention/#anti-fingerprinting) in their current form because of security concerns around fingerprinting. [Mozilla is taking the same stand](https://lists.w3.org/Archives/Public/public-new-work/2020Jun/0012.html). Google is much more gung-ho about implementing those APIs.

I think it’s safe to say that every implementor wants to ship powerful APIs _and_ ensure security and privacy. The issue is with which gets priority. Using the language of [principles and priorities](https://adactio.com/journal/16811), you could crudely encapsulate Apple and Mozilla’s position as:

> Privacy, even over capability.

That design principle would pass the reversibility test. In fact, Google’s position might be represented as:

> Capability, even over privacy.

I’m _not_ saying Apple and Mozilla don’t value powerful APIs. I’m _not_ saying Google doesn’t value privacy. I’m saying that Google’s _priorities_ are different to Apple’s and Mozilla’s.

Alas, [Alex _is_ saying that Apple and Mozilla don’t value capability](https://infrequently.org/2020/06/platform-adjacency-theory/):

> There is a contingent of browser vendors today who [do not wish to expand](https://webkit.org/tracking-prevention/#anti-fingerprinting) the web platform to cover adjacent use-cases or meaningfully close the relevance gap that the shift to mobile has opened.

That’s very disappointing. It’s a cheap shot. As cheap as saying that, given Google’s business model, Chrome wouldn’t want to expand the web platform to provide better privacy and security.