Have you ever used a service in life where there is no competition?
Straight up lack of competition examples are the easiest: DMV, airport food court, buying beer at a sports stadium etc.
If you work in tech then you’ve probably had to use software over whose purchase you had no control: Jira, PeopleHR, Taleo, Concur. There’s no competition there because you, the end user, don’t have the option to choose from a free market. For the vendor, the software doesn’t have to be any good as long as the sales pitch to you boss is amazing.
Without competition, software rots and/or never gets better. What examples are there of monopolies in Free software that caused a product to languish? OpenSSL, Python’s logging module, systemd since it was locked in as the only properly supported Debian/Ubuntu init, pre-Chrome Firefox/Mozilla, post-GMail Thunderbird.
What examples are there of corporate-sponsored software that languish without competition? Internet Explorer is the classic example but if you think Google are better than Microsoft, at heart, then how’s Android working out for us all in terms of excellence-in-the-void-of-competition?
> Without competition, software rots and/or never gets better. [...] systemd since it was locked in as the only properly supported Debian/Ubuntu init
To be fair, systemd was rotten to the core from day one (literally - namely, the core concept of shoving as much crap into pid 1 as possible to abuse the special semantics that are supposed to only allow for reaping of orphan processes), so you can't really blame that on lack of competition.
Your overall point is spot on, though. (And I suppose you could blame lack of sufficiently direct/credible competition for Debian being able to shove systemd down everyone's throats, rather than being forced to support multiple init systems.)
The argument needs to be more subtle to make sense, since Blink is open-source, whereas IE was not. Contrarily, I see another analogy; Blink being like Linux's dominance in infrastructure.
We are talking at cross purposes: your comment is a reasonable refutation of a browser monoculture, something we agree would be bad.
FWIW I am typing my response to you in Graphene.
Ultimately the issue is: what is the harm in using a library maintained by Google to do the webview rendering in a non-Google browser? I just don't see it.
Google can do pretty much whatever it wants when it's the only player in the space. It certainly hasn't been shy about doing things outside of a standards body. Sure, it's open source, but can you meaningfully influence the direction of the project? If you decide to fork and deviate from what stock Chrome is doing, you're apt to be locked out similarly to sites that don't support Firefox or Safari.
It looks pretty similar to what MS was doing with IE, just with a dash of "here you can skin this thing". The biggest differences being that Google has a strong interest in ensuring the web is the app platform of choice, rather than a desktop OS. On the other hand, Google needs to sell targeted ads, so it's unlikely to be the standard bearer for web privacy.
The problem is that you are giving full power for creating de-facto standards to the rendering engine.
If Blink decides to support a feature, it becomes a de-facto standard even if the feature solely serves Google (think FLoC, AMP ...) or is hard to replicate.
It's also an issue because now the web is at risk to become only usable from devices that are physically able to run Blink/Webkit which means nobody in the future will be able to create a new useful device/os that cannot run Blink or Webkit.
It's also an issue with the good ol' technical debt : what happens when Blink/Webkit become a total mess full of hard to patch vulnerabilities or google/chrome specific code ? You basically cannot rewrite it from scratch unless you have the engineering power of a GAFAM.
There are tons of reasons why having a monoculture of rendering engine is an issue.
> If Google were trying to leverage the renderer to assert Chrome over say Brave or Edge, sure, but they're not, and if they do, it will be forked.
Google has already asserted that. Brave and Edge are a footnote to a footnote to a distant appendix, and are almost entirely reliant on Google to provide the rendering engine.
Eh. That’s kinda like “don’t put all your money in dollars”
If the US Dollar goes to zero or the only rendering engine bit rots, other things are happening such that I won’t be too concerned about not having money or not being able to browse the web.
No, it's really not. It's more like "don't put your money in one stock," but it's much more like "architect your code sanely."
In general, if I have a modular abstraction barrier in my code, I try to have at least two implementations. For example, if I have a generic key-value store so I can switch databases later, I'll make an implementation for e.g. PostgreSQL and redis. That way, I don't accidentally couple to one or the other. Otherwise, I'm fooling myself.
That's just basic software engineering, but for open industry standards, it's really critical. You don't want CSS rendering depending on some browser bug or quirk. It's critical to have multiple implementations, or it's not a standard.
The flip side of allowing multiple implementations also means it's possible to build things like web crawlers, screen readers, and other technologies without spending millions of dollars re-engineering IE or Chrome to be identical, bug-for-bug. It's also possible to build new things we never imagined. Indeed, we had a lot more diversity in HTML 2.0 days, when things were simple enough that anyone could build a novel web technology over a weekend (with full HTML 2.0 parsing).
(Before I get accused of over-engineering, I usually don't have these types of modular abstractions; if I don't expect to ever swap databases, I'll e.g. code to PostgreSQL directly
Forget the monopoly part, the reference to IE6, all that stuff. Let's say we don't care about that. What happens when the Chrome rendering engine has a security bug, a big one, a zero-day? That's the issue we had with OpenSSL, suddenly 90% of the Internet er vulnerable and there are no alternatives until Google fixes the bug.
Given the complexity and feature set of a modern rendering engine I don't think it's to fare fetched. I like the entire Internet not being vulnerable all at once.
So why not just get rid of all browsers and have only Microsoft Edge then? Because that is the problem you end up with a bunch of proprietary features that only whoever maintains the main browser rendering engine has and everyone on Linux and probably Mac has to suffer for it.
I'm not sure how anyone can believe this after seeing Android. Google's modus operandi is to make the open core less and less functional over time after everyone has migrated to it, and then put the useful stuff into their proprietary version (Google Pixel, Google Chrome).
You've forgotten what it was like at the turn of the century. It took a long while for us to break the previous monoculture and clear the way for the innovation we've enjoyed since.
The innovation we've enjoyed since was mostly caused by Google getting tired of waiting for either Microsoft or Mozilla to improve on the browser paradigm and footing the bill to roll their own.
I was referring to the innovations in browser capabilities. Process sandboxing massively improved both the robustness of the browser experience and the boldness with which features could be used (because a crashing site wouldn't take the whole browser with it). It paved the way for the actual "browser is the OS for the web" experience we have today, unlike IE's attempt to wed a crash-prone application to its core OS functionality. As a result, the browser capability specs themselves exploded, which eventually rendered Flash, Silverlight, and ActiveX plugins mostly redundant and allowed browser vendors to make their way towards stripping them out in favor of web-engine-only solutions.
Browser (and features, especially privacy ones), absolutely. Renderer, not so much.