Tension in Chrome and Safari’s Dominance ⇥ httptoolkit.tech
There’s a lot of history here. WebKit — being a part of Apple — plays it slow and a bit close to the chest. Historically, they’re pretty tight-lipped about the small number of features they’re working on and uninvolved in community outreach. Quarterly updates to Safari Technical Preview have been an awesome consolation prize, but after years of waiting I find my expectations for the annual release of Safari (specifically Mobile Safari) are intolerably low. This creates an increasing amount of apathy in me that the situation with Safari will get better soon.
These APIs, often proposed by the Chrome team, give browsers power to use bluetooth, write to local files, and sync content with servers in the background. For each of these, Safari and Firefox have signalled that they intend to ignore the API entirely, never implementing it, due to security, privacy & battery life concerns.
Some of the examples Perry gives for products and services that use APIs like these are terrifying to me. There’s a programmable internet-of-things device with a development environment in a website. It only works in Chromium-based browsers because they are the only ones that support Bluetooth and serial connections through a JavaScript API. Maybe this is a sign of my age, but I struggle to believe that JavaScript should be addressing a serial port through a web browser for an internet-of-things device. Is JavaScript now simply a catch-all programming language?
The development environment is also available as a native application. Good. That is a more appropriate way to distribute software packages, particularly those that interface with hardware accessories. There is nothing wrong with creating a separation between websites and applications, and there are risks inherent to mixing them.
Perry:
For the new proposed APIs specifically, in the end they’ll either have to engage with Chrome’s proposals, or become incompatible with the growing part of the web that has, losing large portions of their userbase and their influence on standards along the way. There is no point in winning on principles if there are no users left.
I want to see a world where Apple, Mozilla, Microsoft and Brave are leading web standards, driving the web forwards with features that support new use cases and allow for exciting new products, but with care for user privacy, tracking-resistance and security embedded as first-class priorities.
Perry’s argument is sound: almost no users really care what web browser they are using, so the moment they are told they need to use Chrome to use something, that is probably where they will stay unless something else motivates them to change. That worries me. A web browser, at its core, should be a boring piece of software that frames documents. But today’s popular web browsers are built and distributed by companies that have motivation to undermine that simplicity.
The Chromium rendering engine is the dream of a developer who wishes for the web to be a sort of universal operating system. As Perry writes, it has the broadest API support. It underpins Google Chrome on all platforms, Microsoft’s Edge browser, and its forks power various other browsers; combined, according to Wikimedia’s statistics, these browsers are used by over half of all web users.
Chrome itself is dominant and, by default, it automatically updates whenever Google pushes out a new version. It means that one company in Mountain View, California has the power to change the web browsing experience for about half of all web users every month. That company also operates by far the biggest online advertising marketplace, the world’s most popular search engine, a video platform so commanding that it is synonymous with “online video”, the most popular website analytics software, the biggest email service, and the most popular operating system. One reason Chrome is so popular today is because Google has given it prime advertising space on its search engine for years. Google treats the web as one of its own operating systems because, in some ways, it kind of is.
Then there’s Safari which, on the desktop, is not particularly popular. But its unique position on iOS — where no other rendering engines are permitted — gives it a stick-in-the-mud reputation. Its slow development pace can be seen as protective against Google’s market position, as luddite, and as an anti-competitive tactic to force developers to go through the App Store. I am one of a seemingly small number of people who prefers this approach, even though it makes my life harder as a front-end developer. I do not think websites should be given the same amount of power on my computer as desktop apps, and this is a losing battle I will continue to fight.
Both Apple and Google have incentives beyond developing the best web browser possible for users. Apple has been slowly working for years to improve web apps on iOS and that work continues, but I doubt that web apps will ever achieve the same capabilities as native applications. Google’s incentives may have the knock-on effect of giving websites extraordinary abilities but, in the process, that has introduced security problems, plus privacy concerns that the company has only been too happy to take advantage of to solidify its position in the online targeted advertising space. Those conflicts of interest will, I think, always result in tension between privacy, security, capability, and development speed.
One more evidence exhibit showing why tech duopolies are bad for consumers, no matter whether they playing the role of an end user or a developer. But, on the bright side, it highlights that there is very little web without a web browser, so the companies that make the latter inherently control the former.