Honestly anyone concerned about a Chrome / WebKit browser monopoly needs to use Firefox now if you already are not.
I'd still prefer to see a mainstream Gecko based browser, of course! I think outside of the tech crowd FF is pretty niche.
This attitude is why people dismiss Firefox: “well if FF doesn’t implement it, it must be bad. Other browsers surely have glaring security holes”
(Source: I implemented the file system integration for vscode.dev)
Browser (and features, especially privacy ones), absolutely. Renderer, not so much.
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?
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.)
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.
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.
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.
Do we have the same concerns over type layout engine monoculture?
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.
If the rendering engine bit-rots, goes the way of the original Netscape, Internet Explorer, etc., you don't want the internet to break.
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.
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
Remember IE6 ? That's what we get with a monoculture.
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.
If a private party can do as they please and have such a strong say, why bother with standardization bodies?
Web 2.0 was based on some IE extensions that were introduced when Firefox was the viable other game in town.
Concretely, Google Maps (the poster child for AJAX) launched in 2005, and Chrome launched in 2008.