Without a second browser engine to test pages in, it's really hard to know what is a bug and what is intentional. Devs don't know all the specs by heart. They write whatever happens to work for them, but sometimes they accidentally depend on obscure edge cases in the implementation that were never meant to exist.

In the long term it's paralysing for the engine maintainers, because any change in implementation could be changing some subtle behavior that breaks some pages. W3C requires two independent implementations, so that they'll share intentional behaviors, but hopefully their bugs will differ.

The single-engine Web will be as fun to maintain as Windows: Windows 11 Explorer has a shiny new context menu with an option to reopen it as an older, uglier context menu, because Microsoft couldn't touch a line of code of the old context menu without breaking apps.

They aren't even bugs. The spec allows for interpretations.

Even if the spec was as precise as a source code of another browser, that's not what devs are writing for, so code in the wild web will inevitably deviate from the spec.

And by the way - I'd argue that HTML and CSS are not more "forgiving" towards the user, "silently failing" would be a more appropriate definition. I'd rather have an error message saying there's an unclosed tag so the page couldn't be properly rendered rather than the browser trying to infer meaning from broken HTML and misapplying CSS, generating a dadaist poetry piece instead of a blog page.

These bugs were the worst, because they happened to end users. Users couldn't do anything about unclosed tags or unescaped ampersands, not even notify the developer of the page that refused to display.

Back then HTTPS was rare, but young mobile ISPs loved "optimizing" middleboxes that were messing up the markup. Even if you generated a flawless markup, your pages still wouldn't work for some users. Users were told that your page is bad, and it's your fault, and couldn't contact you about it. ISPs didn't care, because hardly anybody actually used the strict XHTML parsing mode (it made pages inaccessible to IE that had 80% market share). Most "XHTML" pages worked fine thanks to being parsed as regular HTML with invalid extra slashes.

I know this isn’t everyone’s experience, but I believe adding IE11 support to my personal website improved the quality of my code.

There were a lot of things I hadn’t specified explicitly, and for whatever reason Chrome/Webkit and Firefox just happened to make the right guesses. IE11 did not, so I had to go back and be clear about exactly what I actually wanted.

Building a browser for the modern standards-based web is effectively impossible, because it costs too much, takes too long, and requires a standing army to keep up with.

We are at an impasse. The standards cannot be deprecated because they are used all over the web, and because they are used all over the web a new browser maker has little choice except forking chromium or firefox. Even microsoft couldn’t afford to keep adding all the standards to their browser engine. Normally the solution for a messy overgrown implementation is a grand reboot. But we can’t do a grand reboot of the web because we cannot get rid of the legacy. The only viable strategy I see to have real browser engine diversity without giving up on compatibility is moving as much of the standards implementation as possible into JS modules, so new browser makers can start with a small engine that loads the publicly hosted standards modules.

>Building a browser for the modern standards-based web is effectively impossible, because it costs too much, takes too long, and requires a standing army to keep up with.

I wonder which company grew their browser marketshare through ruthless advertising on their already-a-monopoly search engine, then began to compete with the other browsers by purposefully breaking their websites on other browsers (all by accident of course, hundreds of times), then began to implement their websites with alpha versions of their proposed web standards that only their browser properly implemented, leaving other browsers with a dreadful polyfill that had horrible performance on purpose, only to then basically force their proposals through the web standards body that they had made because they couldn't control the W3C, leaving everyone having to follow such great APIs as WebUSB or other badly-implemented-but-only-by-them flavor of the day API, all the way to forcing dreadful protocols like QUIC and HTTP/3, justified by their need to save up three bytes per request and making the user's experience better while they serve 2MB of tracking javascript and ads through DNS-cloaked servers.

I think the name was like... Gogle ? Golgool ? Can't remember.

That is the standardization process. The W3C won't ratify a standard that does not have draft implementations in the wild.

Making it the default and making the fallback only reasonably accessible by installing an extension that will rewrite your links (that all send back to the alpha-using version), causing every browser that isn't Chrome to slow down to a crawl while you happily display a "Hey, did you know the web is faster with Chrome?" isn't working through the standardization process, it is weaponizing it to sabotage other browsers.

A body of web standards that they lobbied for and to be in the form that they are...

As an example, Google holds 18 of 39 seats on the Web Assembly Working Group. This means that if they whip their seats, they only need 2 additional votes to pass anything.

That's making big assumption: that decisions are made by votes, and those votes are done purely based on participation.

And they're not. For decisions within the WG, they're normally done by some notion of rough-consensus (frequently, lack of significant dissent); actual votes within most WGs are relatively rare.

For decisions at the W3C level, it is admittedly done by votes, but it's one-Member, one-vote, so in that case all W3C Member are equivalent in power: Google, Apple, Microsoft, Mozilla all have their votes count as one.

This is pretty normal within industrial standards development organisations: voting happens at an organisational level, representing the industrial members, not based on individuals participating from those members. (There certainly are negatives associated with a disproportionate number being from a single organisation, but that's mostly related to disputes in meetings ending up with one individual arguing against ten.)

1. https://www.w3.org/groups/wg/wasm/participants

The first step in saving the web needs to be to stop adding so many new standards that are only needed for "apps".

  > Building a browser for the modern standards-based web is effectively impossible, because it costs too much, takes too long, and requires a standing army to keep up with.

  > We are at an impasse. The standards cannot be deprecated because they are used all over the web, and because they are used all over the web a new browser maker has little choice except forking chromium or firefox.

the browser just becomes an execution engine, the current "web stack" becomes a (cacheable) downloadable library, meanwhile other languages, ui frameworks etc can flourish in the browser (now a much more simple thing that anyone can implement)

maybe just pie-in-the-sky?

The web works because of HTML. HTML is scanable, searchable. It's what allows search engine to exist at all. HTML enables extensions. HTML is also generally responsive. HTML allows uses to be in control (see extensions). HTML allows uses to copy and paste and even for sites that try to prevent it users can go into devtools to get the text. HTML supports all of unicode and so is inclusive across all languages.

A world in which the browser is just an executable environment and people make random UIs means pretty much all of the above disappears. No more searching for content, no more extensions to block ads or block distrdacting feature. No more extensions for language translation, braille, accesabiltiliy. No more all language support, only whatever each framework decides to support, every page with different limits at different versions of the frameworks.

Anyone who writes a compiler or engine for WebAssembly is going to have to deal with the mess of web standards, unfortunately.

1. https://github.com/WebAssembly/design/issues/755

What might happen is that it ushers in technically-unrelated fashions, such as standard WASI interfaces to something slightly less insane than DOM+Javascript.

Just Canvas-over-WASI isn't the answer because of accessibility, but something like it might happen.

Heh. Now you have two problems. One of them is JS, which was a mistake in the first place and now we can't get rid of it for similar reasons.

what exactly is the benefit of having a byzantine set of standards in the first place? Like why not just have a standard and not dick around with it?

If there are things browsers can't do natively, then someone will build their own way to do it and then you end up with non-standard implementations.

It's better to get everyone on the same page and develop an open standard.

Adobe / Macromedia started from the designer perspective but Flash soon became a goal of its own because Adobe wouldn't give up that marketshare.

Only now all parties realise it's too big for one company to own. Well except Google perhaps.

Users and website creators wanted these features and Flash was the way to do them.

Sure, other technologies like Microsoft's Silverlight allowed similar things, but Flash was so widely used it could be relied on to offer these features.

Even now things like clipboard access aren't supported in the same way across all of the major browsers.

I think the disconnect was more with designers. They wanted visual tools back in those days and had no time for CSS and JavaScript. Adobe/Macromedia gave them what they wanted and also entrenched their commercial position this way (which Adobe already had in the paper publishing market!). It took a long time for the graphical guys to come on board with the open toolchains.

Macromedia wasn't a bad company as such as they did make the excellent Dreamweaver which did promote open standards, but Adobe corrupted them badly.

And I recall it enabled a progress bar, too.

They got exactly what they wanted, but its not their fault?

The problem is not in the lack of browser rendering engines, but the lacking innovation and product features of the browsers running these rendering engines.

  >  we can’t do a grand reboot

(inb4 XKCD) Yes, like a new standard.

>While Android is open, it's more of a "look but don't touch" kind of open. You're allowed to contribute to Android and allowed to use it for little hobbies, but in nearly every area, the deck is stacked against anyone trying to use Android without Google's blessing. The second you try to take Android and do something that Google doesn't approve of, it will bring the world crashing down upon you.

Sure, the license is open, and Chromium is therefore technically open. But it's dangerously close to not being usable in any real practical meaning of "open source".

The way things are, we do indeed stand on the precipice of a Chromium-only web with—for all practical intents and purpose—no open browser. Firefox is the last thing that stands between us and that reality. It's just a shame that they seem to be wasting hundreds of millions on admin and management instead of just throwing it all at their developers.

I can't see anything about this anywhere giving any reasons; is it simply that they're released frequently and there aren't really any long-lived branches?

This isn't sustainable open source development in any practical sense. Sure, it's technically open source, but nearly useless for anything but consumption straight from Google. I'd say that that makes it practically not open source.

And it's kinda my whole point: code that can only be consumed wholesale as shipped might technically be open source, but if backporting fixes to a year old version is nigh on impossible, is it truly open source in practice?

Debian has a release model for a reason and it's their raison d'etre. Of course they don't want to compromise that.

Considering the amount of other distros that use them as a base they're providing something that people want.

And we still have to see if other browsers will block the Topics API spyware or not.

As for the Topics API, It looks like to be a new copy of FLOC, which flopped immediately on release, as no body adopted it other than chrome.

This is an excellent test of Google's ability to just push a very unpopular feature into Chromium derivatives.

Google has a lot of control over chromium, but I don't think its even close to how gimped AOSP is compared to Android google edition.

They set the toggle to false and deactivated any of the options to turn it back on. That's very different from removing a feature (or maintaining a legacy feature).

The only code they changed was UX-related and a single default.

Microsoft just did whatever they wanted with the web "platform", and so will Google.

In Microsoft's case what they wanted was nothing. They weren't a web business, saw it as a threat to their platform leverage, and so just left it abandoned and stagnant for years.

Google is simultaneously better and worse: they won't leave it stagnant because the web is their platform, but on the other hand they have a lot more to gain by abusing control of it.

We already have a number of Chromium based browsers that go against some of Google's most fundamental interests (e.g Brave).

Costs matter, and Web development costs are high. Google benefits from coordination, funding, and one migh presume, cost advantages, which would be exceedingly difficult for any comparable US or EU effort to match.

Development in lower-cost-of-living regions, perhaps most viably China, might pose an alternative.

Open source is that option. The economics of starting from scratch vs starting from Chromium's latest commit are fundamentally different.

I'm not saying that it's easy, only that it is not remotely comparable to the IE situation.

MSIE was bypassed not by a code fork of MSIE (itself originally based on the Spyglass browser, which was a fork of the NSCA's Mosaic codebase), but by independent implementations of an HTML-standard parser. Microsoft had some influence over Web development (noteably through ActiveX) but far less than Google has now.

My point is that Open Source of itself is not sufficient, and moreover simply is not viable. Glibly asserting that it is ... is utterly unrealistic.

Though the alternative of forking a Web-like markup and transport, as Gemini is attempting to do, is one option. For other technologies which have become sufficiently baroque, similar worse-is-better alternate paths have been pursued.

Otherwise, this is an antitrust issue, and Google very badly need busting.

And I didn't claim that it was. My point was merely that Chromium being open source changes the equation pretty fundamentally compared to the IE situation.

Whether it's enough to make a Chromium monopoly consistent with an open web, I really don't know. There are very good reasons to be sceptical.

So you’re not claiming open source is sufficient but you are seemingly defending it is a better situation.

While I and some other commenters are signaling we don’t think the situation is better.

To me the fundamental part of the equation is outsized power and influence. Being open source or not is part of the equation, but not as close to as fundamental as the core issues with this. This is made much much worse now than 20 years ago with the costs to get your own browser going so much higher. Which leads back to the outsized power being the fundamental issue.

Open source can even be argued to be a benefit to Google retaining power. Having enough attention diverted to the possibilities of open source when Google has only monumentally gained from open source with paltry benefits that are usually brought up as defenses against its power. Like AOSP mattering because China doesn’t use Google’s Android and some other irrelevant projects.

Any fundamental differences so far are giving Google and any other major central powers more power.

Yes, that's exactly right. I think Chromium being open source changes the equation for the better compared to the IE situation. Whether it is sufficiently better to make it work, I'm not sure. I do see Google's outsized influence as a significant problem. I'm not denying that at all.

The fact that browsers like Brave have made changes that go against Google's interests is cause for some optimism though.

It is very permissively licensed, and Microsoft’s Edge is so successful and Microsoft is contributing a ton upstream. In a few years time they will have de-facto equal say over where the codebase goes. If Google disagrees too much, we will in fact see a fork.

Furthermore, from what I can tell, Edge users are predominantly former IE users (rather than coming from other browsers), and combined IE + Edge use is still declining over time.

I'm not seeing your more recent statement as consistent with the first, given my own response: "Open source without the option for an alternate development organisation to drive or steer development direction means vey little."

Again: Microsoft's locus of control was not based on source code or standards, but on its control over the PC desktop market. MSIE shipped by default with that desktop, and any other browser, including Chrome, had to find its way to that desktop.

Microsoft has now ceded its own browser engine (Trident, I believe) for Google's (Blink), with Microsoft Edge. As this browser still ships by default with Windows, Chrome owns that platform by default.

Google also controls its own operating systems, Android (mobile and tablets) and ChromeOS (Chromebooks). Given Android's overwhelming numerical advantage in overall devices,[1] Google effecitely have Microsoft's previous leverage mechanism to themselves.

Google as the dominant search provider have an advertising advantage in advocating their browser, both within search and on Google properties with "works best with Chrome" or equivalent.

And again, Google effecitvely dominate both development of Chrome and Chromium, including gatekeeping over what code makes it in to each project, and through its own browser development, dominance within WHATWG, and ranking preferences withing Google Web Search, as well as compatibility favouritism through popular Google properties such as YouTube, Web standards themselves.

Microsoft's monopoly lock-in had a single peg, Google has four (OS, promotion, Chrome development, Web standards).

I do have to admit though, yes: It is a completely different situation. Microsoft's advantage was far weaker than Google's now is.

________________________________

Notes:

1. "As of April 2022, Android, an operating system using the Linux kernel, is the world's most-used operating system when judged by web use. It has 43% of the global market, followed by Windows with 30%, Apple iOS with 17%, macOS with 6%, then (desktop) Linux at 0.98% also using the Linux kernel." https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...

My point was merely that Chromium being open source changes the equation pretty fundamentally compared to the IE situation

Yes, and I stand by that. Chromium being open source changes the situation completely. It makes no sense to compare the IE era to any Chromium monopoly without even mentioning that Chromium is open source.

>I'm not seeing your more recent statement as consistent with the first, given my own response: "Open source without the option for an alternate development organisation to drive or steer development direction means vey little."

I don't see any inconsistency. I simply disagree with you. It matters a great deal that Chromium is open source. It changes the politics in the industry. It changes the economics. It changes the regulatory situation. It changes the facts on the ground in terms of available browsers.

I do get your point though, and it's not that I disagree with everything you're saying. I just disagree with the claim that open source Chromium "means very little".

This is just a ridiculous assertion. Blink being Open Source does not change what Google does with the engine. If the web was Blink with a handful of irrelevant Blink forks then the web is Blink. That means whatever stupid specs Google puts forward like WebBluetooth or WebFacialTrackingAttentionMonitor become de facto web technologies.

No one outside of Google will affect the direction of Blink. Even if Microsoft tried, Google still has an overwhelming number of deployments and overwhelming influence with search and advertising.

Part of the problem of IE dominating the web was Microsoft using that domination to push their ecosystem and nudge out competitors. If things like ActiveX and VBScript had been more popular there would have been no room for Firefox to make inroads against IE.

Google's Web* specs they push are their equivalent of Microsoft's proprietary extensions of the web. No browser written from scratch can hope to catch up to Blink without billions of dollars of investment. A Blink fork disabling the most privacy invading Web* specs can't meaningfully compete with Google's install base and promotion.

What you're missing is the fact a project is Open Source doesn't mean it's governance is in any way open. The governance of Blink is not meaningfully open. Nothing a non-Google contributor says means anything to Google. They already add in half-baked and poorly thought out Web* specs to Blink with little concern for standards processes and there's at least some competition from Firefox and Safari. If Google doesn't care now it's ridiculous to assume they would care if Blink completely dominated in the browser space.

That's absolutely right, but it's not the point.

What matters is how much investment is required to offer an alternative to Google's Chrome. Does it take billions or does it take mere millions?

Building on top of Chromium means that it takes mere millions. And that changes the situation.

For that to be true, it is not necessary to wrest power from Google when it comes to deciding what does or does not go into Chromium as Google doesn't get to decide what goes into any forks.

Does any of this negate the power that Google currently has over web standards by way of Chrome's overwhelming market share? Certainly not.

What it changes is Google's margin of safety when it comes to imposing truly user hostile technology on everybody or stop investing in the technology.

And I don't mean "user hostile" in the sense that it enrages the HN crowd. I mean user hostile in the sense that many normal users will actually look for better alternatives on their own accord, not for political/advocacy reasons.

The fact that open source Chromium exist makes Google's dominance over the web far less assured than it would otherwise be.

> Building on top of Chromium means that it takes mere millions. And that changes the situation.

This simply does not follow. If you're building on the back of Blink you're still chasing whatever Google unilaterally decides to include in Blink. You need to do extra work to merge stuff you want and keep stuff you don't want properly disabled. Google has no impetus to make it easy or even possible for third parties to disable features in Blink. The cost to maintain a defanged Blink can very easily go from "mere" millions to billions if Google makes it difficult to merge upstream changes in defanged forks.

If web developers readily adopt whatever Google throws out, and lets be honest it's adtech companies adopting "features" to better fingerprint users without cookies, then a Blink-based alternative to Chrome will get zero uptake. If the top sites on the Web require Google's version of Blink/Chrome with all of Google's handy dandy anti-privacy features then it does not matter in the slightest that a non-Google Blink browser can exist.

You're pretending that Blink being Open Source is somehow going to affect the decisions of web developers (adtech companies). They are going to chase Google's version of Blink/Chrome because that's how they make the most money. Right this second Apple and Mozilla are just barely keeping Chrome from fully dominating the web.

Google is never going to make Chrome overtly user hostile. They're just going to continue to making Chrome an advertiser's dream browser because they are an advertiser. While WebEyeTracking might have some non-advertising use 99% of the user cases will be to make sure people looked at an advertisement long enough. If Google controls the specifications that define the web and sites adopt those technologies, there's no room for alternatives that aren't Google's Blink. Not only can defanged Blink not be practical but neither are non-Blink browser engines.

I don’t think they are. That fork then immediately finds itself in the same position as other engines, where now the fork is going to need to keep up with whatever Google is adding to Chromium.

You might then think, “Then the fork can just pull from upstream.”

Okay, so then:

a) Your fork probably isn’t differentiated enough to matter; and more importantly

b) Google is still effectively calling all the shots!

Even more so the fact that Brave was able to build an alternative ad network on top of Chromium.

Call me when a Chromium fork displaces Chromium.

This hasn't happened with Chromium, but it did happen with WebKit.

You wrote:

> The fact that both Brave and Vivaldi were able to disable Google's FlOC within a very short period of time

Okay, they disabled some stuff. That isn’t a fundamental divergence from the upstream project.

The original argument was that Google wouldn’t control the web in a Chromium monoculture because anybody can just fork it.

I disagree. My argument has two prongs:

1. A Chromium fork can only sever itself from Google’s control if it is not taking patches from upstream (ie, Google). I’m particularly thinking about the most consequential pieces: web APIs, not Google ad tech. That’s going to require an army of developers who now are immediately thrust onto the web API treadmill.

2. If a Chromium fork’s market share is tiny, how is it going to displace Google’s influence on the direction of the web? It isn’t. Everybody will still be coding against Google’s Chromium.

Of course market share has to be part of the discussion. But the way in which you used it seems tautological. Also, market share affects alternative browser engines just as much as Chromium based browsers.

>The original argument was that Google wouldn’t control the web in a Chromium monoculture because anybody can just fork it.

That wasn't my argument though. I don't know if Google wouldn't control the web in a Chromium monoculture. It very well might. My argument was that the IE era does not serve as a valid historical precedent because the fact that Chromium is open source changes the situation in very significant ways.

>A Chromium fork can only sever itself from Google’s control if it is not taking patches from upstream (ie, Google)

I don't think Chromium based browsers can completely extricate themselves from Google's control. But this is not a black and white question. Alternative browser engines cannot do that either.

You make a good point that web APIs are a better test for Google's control than ad tech. But this kind of control affects independent browser engines just as much as Chromium based ones. If Chrome doesn't implement a particular web API then the API is dead in the water. That's where market share matters.

It's generally far easier to turn APIs off than add new things. Keeping a fork up to date with upstream while maintaining a list of Chromium platform additions that are disabled is exactly what we're talking about here, no?

Because market share can change. Its a statement of the past when we are talking about the future.

Put another way, would Google have had an easier time building Chrome and Chromium if IE had been 100% open source when Chrome was started?

Remember, it wasn't that long ago that IE dominated, and MS still has many of the same advantages now that they had back then.

They created a new ad model where users are paid for their attention.

That's where Firefox is right now, unfortunately.

I've told some people to switch to Firefox. A lot of them switch back to Chrome after a while, simply because it's faster.

Linux itself is at least not a proprietary and commercial entity, though quite arguably its development has largely been captured by a set of proprietary and commercial entities. There's enough multilaterality in that group that fixed loci of control don't seem overwhelmingly apparent, but I'd definitely watch for those.

I've been concerned over numerous elements of Linux development (including viewpoints expressed by senior developers) for a decade or so. I think you'll find some level of concern expressed by others, including some very senior former Linux devs. (I'm not positive A.C. has said as much, though that's a vibe I get.)

These sorts of arguments probably help cement Google’s power. By giving the guise that the open source part of the equation can be the key to usurping Google’s power. Instead of it mostly being the other way around.

It would not be surprising if Google loves these tiny changes from Chrome and Android. So the discussions and sentiment never get close to how bad it got for IE or other monopolies and dangers of power.

To make matters worse, Google has put in place some legal roadblocks against device vendors using AOSP in markets where others can fill in for some of the proprietary Google parts.

These requirements are subject to regulatory action and I'm almost 100% certain that they will be deemed anticompetitive and therefore illegal.

The same thing has happened to Linux which was ok as long as it was chasing commercial Unix, spawning POSIX even; but look what happened with systemd, wayland, snaps/flatpacks, Docker, k8s, and all the other erratic developments - all the while not a single end-user app was created in the last decade.

Strongly disagree. Desktop Linux is better than it's ever been before, and not at all comparable to the degenerate hellhole that is the modern web.

systemd isn't perfect, but I think it's an improvement from traditional init. If you prefer the simplicity of traditional init systems, then you're free to use a non-systemd distro. Wayland is a much-needed modernization and simplification of the graphics stack, and again, nobody's forcing you to use it - X11 won't disappear any time soon. Snap, Flatpak, Docker, etc aren't exactly my cup of tea either, but again, nobody's forcing us to use them. Debian, Arch, etc are chugging along just fine. Meanwhile, PipeWire is a significant improvement compared to bare ALSA or Pulse+Jack, and iwd is a significant improvement compared to wpa_supplicant+NetworkManager.

As for new end-user applications, how about Sway?

This is the tragedy of the Linux Desktop. The problem with F/OSS is the "Free" part (as in "Beer"); as long as users resist paying for software, you will never have a rich enough ecosystem to develop that very software. The problems you list with "systemd, wayland, snaps/flatpacks, Docker, k8s, and all the other erratic developments" is that they are largely meant to solve corporate problems.

Safari definitely does not just follow suit (see https://caniuse.com/?compare=chrome+102,safari+15.5&compareC... for example).

Many of those features can be used to comprehensively fingerprint your device allowing advertisers to track you across sites even without cookies. Forget about any laws or privacy efforts it would all be moot. And many of us value privacy far too much.

Apple even implemented the "do not track" API and advertisers completely ignored it.

Call me when I can install Safari on linux (or any platform other than macOS/iOS).

Until then - the ugly truth is that Apple intentionally underfunds and underdevelops the browser because they see it as a fundamental risk to their control and revenue from the App store.

It's there because "they have to have a browser" not because they're doing anything novel or clever. And many of the things they refuse to implement aren't related to ads or Google's control at all - they're things that would have narrowed the gap between what a website can do on iOS, and what the App store apps could do.

Again - Apple is acting EXACTLY like microsoft here. Underinvesting in the browser because they see it as a fundamental risk to their best revenue stream - much like how MS ignored IE when the focus was all on local apps (the king of which was still MS office).

That's not a truth that's an opinion. And one I would definitely disagree with.

When it comes to speed, privacy and battery life I am always choosing Safari over Chrome. And many of us care about those three things over new features that often just make the web worse.

I disagree that Apple is underinvesting: their slower, more deliberate pace can be an advantage: you can see the pitfalls of implementations in other browsers. I am not disagreeing that Apple has had their own share of bugs, though.

I do use a MBP daily, and the software there is amazing. But seeing that their software barely works outside of their platform, it's a miracle they have any customers at all.

I don't think very many of their customers run any of their software anywhere other than on Macs and iDevices, so I expect that doesn't have much effect. Aside from the apple TV app on Roku and various TV operating systems and such. And still, none of this makes Safari not an "actual browser".

These APIs are one of the big areas where chrome/google have tried to expand the remit of what's possible with web apps, for example the file system api can be used by a web app to access files directly on a users machine.

Where things went off the rails was the things Microsoft refused to implement due to their monopoly position. They had a binary component architecture, but it wasn't sufficient to run Java. They had Java, but it was a vestigial and crippled version. Their HTML/CSS engine was just "odd", incompatible not only with emerging standards but with any published standard at all.

Basically "the problem" with IE wasn't that Microsoft "did whatever it wants", it was that it did (or didn't do) very specific things intended to prevent users from wanting to use IE at all, in a vain attempt to favor desktop applications or IE-specific implementations.

Ironically, Safari is more similar to IE in that regard. The web isn't Apple's platform, either, so they're not too interested in continuing to develop it.

Oh and early on they had URL prefetching, but that led to badly written web interfaces from executing operations that shouldn't happen.

It's perfectly possible for Google to be engaging in similar behavior to Microsoft during IE era, while websites decide to support more than one browser for the moment. In the long run, Google's behavior could contribute to more websites deciding to support fewer browsers.

I'm already seeing the occasional website that doesn't work properly on Firefox - for the moment this is rare, but I wouldn't be surprised if it becomes more common.

For users, IE6 was an era of unrivaled simplicity where the essential hypertext purpose was already fulfilled. Trident (its layout engine) wasn't great but it got the job done. And that same era spawned alternative browsers around that engine, the same way we have Chromium derivatives today, where the real innovation happened. Tabs, ad/popup blocking, easy per-site searching, auto-cookie cleaning, etc. were all present in browsers like NetCaptor (https://en.wikipedia.org/wiki/NetCaptor) or Maxthon (https://en.wikipedia.org/wiki/Maxthon), which all used IE. Nobody had to worry about "will this page work in my browser".

For devs, IE6 was the closest thing to a real standard the Web ever saw... more than at any time before or since. Its monopoly created a much stronger de facto web standard than anything the W3C has tried to coerce or the WHATWG has tried to suggest. It allowed innovation around a common web layout, in terms of browser features, instead of overloading the DOM with flashy interactives that nobody asked for.

Then ActiveX came and went, competed with Java applets, Flash took over, Firefox and Webkit started taking off, Javascript got more powerful... and Microsoft's beautiful walled garden collapsed. What do we have to show for it, two decades later? Slower pages with unnecessary complexity, written in transpiled languages ten layers deep, with a UX more focused on dark patterns than getting to the point. What's your typical complex web app... Gmail? It's good, sure, but in replacing Eudora, we ended up with the messiest, jankiest, hackiest ecosystem in the history of consumer computing.

It was really too bad Microsoft was the one who got away with IE6's monopoly. If it had been a proper browser vendor who took (and maintained) control from the early days, the web would be a much cleaner ecosystem, like the walled garden app stores we have today.

Even today, we're back in the same situation with on iOS, where every browser is just WebKit underneath. iOS web browsing is thus a lot cleaner than than crapfest on Android, where every browser ships their own renderer and no two cheap Android phones ever render the same website the same way.

<old man yells at cloud>Frankly, I'm just not sure it's worth it? Twenty years of web dev later, and honestly I think it's just gotten worse. Most people still just want to look up restaurant hours or send a message to their friends or whatever. The rest is crust.</old man rant>

Edit: well, that and ActiveX, but that's not a good thing...

modern DOM, Ajax, modern CSS, bunch of other small details of JS, all iirc came from IE.

It could be just apathy towards choice. I've observed this behavior among GNOME advocates as well. Some of them would rather see GNOME as the only de facto choice for a desktop environment on Linux and considering how it's installed by default on most major distributions, those words and their effect aren't far fetched.

That's what it looks like to me as well but whenever this is asserted, GNOME folks are quick to point out that they are understaffed and GNOME is a community project. I suppose we'll never know the reality.

> Despite being an even larger collection of s/w than GNOME and strongly supported by SuSE

I remember reading on HN that SuSE has people for GNOME developement but no one for KDE development. IIRC, they also ship with GNOME as the default choice.

> That shows the power of big corporate money's ability to take over even ostensibly "FOSS" software that's theoretically free but practically still dominated by a few companies

I've mentioned GNOME being similar to Android and Chromium in its nature of "look but don't touch" open source (unless you are part of their "community") but this hasn't been received well.

openSUSE has a KDE team, but I'm not sure to what extent they do upstream KDE development. [0] Also, openSUSE does not have a default desktop choice. I don't know where the enterprise offering differs from the community offering in these matters.

[0] https://en.opensuse.org/Portal:KDE

[1] https://en.opensuse.org/openSUSE:Desktop_FAQ#How_to_choose_a...?

Mozilla (Firefox) was our chance for something different. They were ahead of IE once but they watched on and did nothing whilst they had their pockets lined up with Google's money and allowed them (Google) to overtake everyone and now everyone is complaining about it. It even goes back before Chrome was a thing when the Mozilla CEO declared that they could move away from depending on Google's money. [0] Now 14+ years later, they are still unable to do so.

Since then it is only Google (Chrome) and Apple (Safari) again, just like for Android and iOS. All other attempts at stopping them was a complete failure like Firefox OS was and now Mozilla and Firefox are the ones fizzling out of existence as they are unable to make money as the majority of users are running to Chrome, Brave, Edge and Vivaldi.

It is no wonder websites are beginning to not only break on Firefox, but also tell or block users from their web apps to instead use Chrome.

[0] https://web.archive.org/web/20120105090543/https://www.compu...

Really close to gnome 3 spirit, it continuously removed user features and personnalisation.

Gnome 3 really epitomized that but it's a general trend of linux on desktop catching up to proprietary os in first 2 decades culminating with the bonus coolness of compiz fusion.

And then the 2010-2020 were most of the time was spend changing the technologies (removing XUL,going to system-d,wayland) and the user experience suffered.

I think open software has a special responsibility to empower users not only through programming but also through their interface, it can be extension or extensive settings but it has to.

It ends up making more practical, feature reach software and open source needs that because we don't always all the resources to make the most polished software.

All of this I saw in the last few years, some of that is still valid today.

Browser compatibility bugs absolutely exist.

See https://github.com/webcompat/web-bugs/issues for some more examples.

Which was very frustrating given they are both free software :(

1: https://github.com/jitsi/jitsi-meet/issues/4758#issuecomment...

System requirements for Google Earth

- Google Chrome 67, Firefox 63, Edge 79, or Safari 11.

- Make sure that you turn on hardware acceleration.

But I do know that Apple Business Manager wont run - not sure why as it seems to be a fairly basic interface and says Firefox is supported, but yea I have to use Chrome for that

That seems like it'd be google nerfing other browsers, they're pretty anticompetitive. If it doesn't work in FF and is still maintained I bet if you change the browser identity to pretend it's chrome it'd probably work.

macOS-specific browser share numbers are hard to come by, but on our own moderately sized website we see about 60% of macOS users choosing Safari. Even if iOS allows other browser engines, presumably a similarly large number of iOS users would also choose Safari, either because it's the default or because they like it. So regardless of what happens with iOS regulation, it seems likely there will always be significant Safari usage on the web.

So then the only way we end up with a Chromium-only web is firstly assuming a worst-case scenario for Firefox essentially falling out of use, but its usage on desktop appears to have stabilised around 7-8%. Secondly Apple would then need to decide to ditch WebKit for Chromium. I can't imagine they'll ever do that. Apple have a strong desire to do things their own way and keep full control over how their browser works. So I think we're a long way from a Chromium-only web.

If they wanted to, they could switch Safari to Blink just like everyone else did, but still keep adding features on top of it (privacy, iCloud integration, whatever), the same way Microsoft does.

No user asks for a different layout engine, that's corporations fighting with different values and priorities. The differentiating features for users are layers above that and arguably held back by renderer differentiation.

Safari and iOS mobile are the main outliers. Firefox is a little behind too, but few people use that anymore.

Chromium/Blink development is what actively drives the web forward, with everyone else playing catchup. Apple just doesn't care about that (or is perhaps purposely trying to slow it down) in favor of their own priorities and platforms.

>Google had a plan called “Project NERA” to turn the web into a walled garden

https://twitter.com/fasterthanlime/status/145205394150468403...

It's not that they're one judgment away from that day. They know that. It's just that they want to get as much mileage as they can before they too abandon Safari and first allow, then switch to Chromium. That will happen in the next 5 years.

What might come of it all would be a reset where new branches form and new innovators get to introduce new proposals. Standards aren't a bad thing if they're open. If Safari dies then Google will be next in the line of fire for antitrust action anyway... things will fragment again. I'm personally pissed at the number of great technologies left as litter along the road, not least AS3, just to get to this shitty middle ground / cold browser war between two companies I hope die and one that won't help itself. Let the standards win and let's have a standard platform to innovate on top of.

That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one.

They also want to make sure that if they fix the next security flaw what will undoubtedly be reported in WebKit, that all the apps with an embedded browser will get the fix and won't continue to be vulnerable due to them not updating whatever version of Chromium they were embedding.

Of course, between sandboxing and not allowing JIT compilation, those vulnerabilities couldn't do do much harm, but that embedded Chromium also wouldn't be much fun to use.

Which means, if you let me make a prediction of the future, that when Apple is forced into allowing other browser engines, articles will be written about how Apple is complying by the letter of the law but not the spirit by "seriously hampering 3rd party engines" compared to their own by now allowing JIT compilation.

If they had to then also allow those 3rd party engines to do JIT compilation and bypass the sandbox in means that browser engines need to, then we'll be in a much worse position security wise.

We'll see how this is going to play out, but I'm pretty sure exerting control is not the only reason for Apples' stance.

Yes, because Chrome and Firefox have such a terrible track record with security /sarcasm

Lets face it, that's a conveniently plausible excuse, not an actual reason.

It’s like the skepticism over the Steve Jobs “Flash” memo… why do nerds have such a hard time accepting that Apple might actually be sincere about wanting to make a decent product?

The Jobs Flash memo was crystal clear about why Flash was being booted off his platform. It was to avoid "a third party layer of software coming between the platform and the developer".

HTML5 by and large didn’t have this problem. Was it possible to write a grossly inefficient HTML5 site? Yes, of course, but it wasn’t the default state, as evidenced by how much happier those same machines mentioned in the last paragraph were when running e.g. the HTML5 YouTube player instead of the flash one.

Safari developers optimize for battery life whereas Chrome developers seem not to care about client-side resource use.

That is, if Chrome churns through battery on a Mac laptop, the typical user is going to just think “Apple laptops have poor battery life”, never realizing that switching to Safari would make a significant difference.

The real bullshit about the Jobs Flash memo wasn't that it was justifying not shipping Flash Player on phones, but that it was justifying banning apps that used any third-party developer tool. Adobe had decided to just ship a packaging tool that let you stick a SWF and Flash Player into an iOS app; which Jobs considered to be a way to pollute the App Store with garbage apps. Except this wasn't a ban of one specific developer tool, it applied to everything that wasn't entirely C, C++, Objective-C, or JavaScript[1]. This only lasted about 3 months because...

1. A lot of mobile game developers were already using scripting tools that violated the new rule, and the games they were shipping were not garbage

2. The FTC was threatening to sue Apple

After that, Apple caved completely. In fact, if you've played iPhone games, you've probably already used Flash Player on iPhone. Jobs' fear was mostly unfounded because developers absolutely could make performant mobile games in Flash and ship them as apps. The problem was that they had to work around all of Flash's legacy crap to get there.

[0] Safari has several UI affordances for mobile web usage that Flash never got. Notably, those "cutting edge floating menus" still work because Safari treats finger touches as either a hover or a click, and picks between the two based on how the page changes when it simulates a hover.

Furthermore, browsers around this time were moving to GPU compositing internally, but Flash has always been built around a particularly quirky scanline renderer. Getting that to work on GPUs was apparently too much for Adobe, and even Ruffle has rendering problems caused by it.

[1] The language in the developer agreement was "originally written", so no, transpiling doesn't get you out of this.

The same people will say Flash was slow by default. I remember running canvas vs flash rendering tests in mobile Safari when the plugin was still available, and Flash blew canvas rendering away. Of course it was all about what you chose to do with it... no one was writing really complicated behaviors in canvas at that point, and wasm didn't exist, so if you wanted special animation or complexity you used Flash. The appropriate thing would have been to have Flash off by default until someone tapped an embed to load it.

W.R.T. compositing, browsers took a long time to move to even just GPU based compositing, and full GPU based rendering took longer still. Certainly, if Flash hadn't been killed off so prematurely it seems reasonable that either they'd have done the work to keep up, or users would have organically abandoned the platform.

Indeed, you make a good point that it was really a fight over forcing devs to use Objective C and nothing else. Flash was just roadkill in that fight.

It took a few years for plain old HTML/JS sites to be optimized for mobile, and not many of them were then. Given some time, Flash devs would have too. I'd already optimized my own and was optimizing a Flash-based gaming site for mobile when Apple pulled the plug.

If they really cared about security then they could subject their browser to an independent security audit, and require the same audit be passed for any other browser that's allowed on their platform.

Why don't they do this?

As it stands now, WebKit and the processes hosting it (Safari, WKWebView) are probably the most complex piece of software running on our iOS devices and as we can see, they are full of security flaws.

But so are the engines of all other browser makers.

Audits is not what uncovers security flaws. Detailed research, fuzzing and effectively unlimited time to do both on the side of white-hat hackers and unlimited budget and criminal energy on the side of black-hats is what does.

Same is true for other engines of course.

But being restricted to a single engine shipped and updated as part of the OS with tailor-made support by the OS for sandboxing and JIT restrictions for this one engine does help to reduce attack surface.

Also, my initial concern isn't as much about third parties shipping their browsers (though, consider how many third party browsers exist and how many are well-maintained), but much more about apps embedding a vulnerable version of an engine and never updating it ("it works fine for us - no need to change a running system")

What it does is hold part of the system constant, so that attackers know ahead of time that iOS users will be running WebKit. Reducing variability makes attacks easier and increases the value of WebKit vulnerabilities.

Audits aren't supposed to be an ultimate guarantee of security, but provide a minimum, independently judged hurdle that has to be passed to get on the platform.

If there's a better, independent way to judge what browsers are "secure enough" to be on the platform (ie. not just "Apple says no"), I'd love to hear about it.

Minimize attack surface, minimize choice.

As I said in my comment: I believe Safari and the underlying WebKit to be the most complex and most insecure part of iOS by multiple orders of magnitude.

Not adding more of equally complex and demanding pieces does provide a significant reduction of attack surface

Because the idea that all you need to do to ensure software is secure is hire an expensive consultant is ridiculous.

Especially with a web browser which are highly complex pieces of software.

Taking Apple's word for their browser being secure and other browsers not is just as if not even more ridiculous.

What fair, independent way of determining browser security would you suggest be used instead of an audit?

While that's just Safari and Chrome, that's probably ok. But what happens when it's Safari, Chrome, Firefox, Opera, Brave, etc, etc?

For the security test, there are various ways that an org builds software with integrity, and it's the sort of thing that requires a huge amount of effort to get right. Standards like FedRAMP, SOC2, ISO9001, etc etc are the sorts of standardized things that exist (containing things like 'all code must be reviewed'). I think for a browser, if you were Apple and were looking to accept other browser partners, you'd likely do something like this; regular audits of quality, requirements that must be met to maintain access, pentests, basically a continuous process that's to be met by the supplier (similar to how hardware suppliers must meet many requirements).

While users can choose their primary browser, they have no control over what embedded browsers third party apps use, and so if embedding Chromium becomes popular in third party apps it will unavoidably cut the battery life of many if not most users.

When/if Apple starts allowing third party engines on iOS, I think they should require engines to meet minimum efficiency levels to prevent this issue. As a bonus, it’ll allow savvy laptop users to use community builds of desktop Chromium/Firefox with iOS efficiency compliance flags switched on if they want to extend the battery lives of their laptops by an hour or two.

I'm not a great future-reader myself, but I don't see this happening soon. The web is a great threat to their app (and also subscription) revenue stream, and they have a lot to lose with little to win for their platform. They lag behind because they want to, not because they can't.

This is as ridiculous today as it has been every year since the iPhone began.

Mobile web apps are terrible and despite all the years of promises that "feature X" will fix this nothing has changed. And you can't blame Apple because Google et al could easily have made mobile web apps work on Android.

If you want to make a mobile web app then go right ahead. Apple isn't stopping you. But just don't be surprised when no user is interested in it.

People tried it with PhoneGap for years and it failed. I even built some of them.

It has nothing to do with Apple and everything to do with the experience being objectively terrible.

So bad in fact that even Google gave up trying and built Flutter.

> While WebKit is making progress on PWA support, at the time of this writing, PWAs remain a second-class citizen on iOS. The iOS App Store’s support for PWAs is non-existent, requiring a web view-based solution like PWABuilder’s.

> Additionally, because iOS doesn’t allow 3rd party browser engines, your PWA is limited to WebKit’s PWA capabilities, which are currently lagging behind other browser engines.

Google isn't abandoning PWAs, and in fact Chromium continues expanding support to make them as native as possible:

https://web.dev/window-controls-overlay/

Might I also add that the web app manifest is also an open standard, that Safari is lacking on:

https://developer.mozilla.org/en-US/docs/Web/Manifest

https://w3c.github.io/manifest/

This has been available for close to a decade.

Guess what. Users hate it. They hate mobile web apps and their slow, clunky, feature-poor, non-native interfaces and for that reason they will also hate PWAs.

https://blog.pwabuilder.com/posts/publish-your-pwa-to-the-io...

> PWAs remain a second-class citizen on iOS

> PWABuilder doesn’t guarantee that your app will be accepted into Apple’s App Store.

> In 2019, Apple released new guidelines for HTML5 apps in the App Store

2019 isn't close to a decade.