The Danger of Sideloading Chromium

This is seems a bit naive. People are lazy and expect only good enough, hence PWAs. This is why most everything eventually slides to mediocrity. Not to mention the likelihood of a web browser more leaking private data. That is what Chrome is built to do.

It’s incredible that Chromium has outpaced WebKit so thoroughly, especially when you consider that Chromium is a fork of WebKit.

Given Apple’s financial resources, there’s no reason they shouldn’t be competing to be the best browser.

There is a base assumption under all of this: that anything Google comes up with is automatically a good thing for the web and that everyone else is "falling behind". Yes, Apple has some bugs to fix and work to do, but what I really want, and what I think is really important, is a diversity of priorities and perspectives about what the web should be.

Google's propaganda has worked so well that if they were allowed on iOS, that would be it forever. They would become the owners of the web and there would be nobody to stop them. It's truly unfortunate, but that is the situation we are in. It is totally understandable that Apple does not want that to happen.

The fact Apple can ban Chrome on iOS is what makes them lazy. If they couldn't, they'd be forced to invest more in improving their (and others') browsers. So this is a direct example of where their monopoly power is harming users.

We seem to have forgotten that adversarial situations are a forcing function for progress in a world where profit can best be maximized by not investing. Technological improvements occur when companies compete, or countries do, particularly during war. It's not a question of people not being able to invent during other times, but a question of the difficulty of marshaling resources.

@Brad Who’s assuming? Many Web developers may simply like the stuff that Google comes up with. Google does seem to be trying to meet their needs. For me, as a user, it doesn’t really matter whether Google’s ideas are good or it has good motives. I commonly run into sites, some very important, that don’t work in Safari. This was not the case 5–10 years ago. If this is, as I suspect, more due to bugs than philosophical issues around PWA, it’s even worse that we/Apple are in this situation because it would be needless. By the way, there are also Chromium browsers like Brave that have compatibility with Chrome but privacy values more along the lines of Apple’s, and those are banned on iOS, too.

Brave is not banned for iOS. I use it on my iPhone and iPad.

> Safari should not merely be good enough to keep iOS users from abandoning the platform in order to switch browsers. It should be good enough that Apple doesn’t fear Chromium browsers taking over if users were allowed to choose.

I suspect more users would be lost to web site banners insisting on Chrome than to end user feature discrepancies. Telling users to “just download Chrome” is an alluring solution to publishers that don’t want to fund testing multiple browsers, let alone multiple platforms.

You mention using Safari except when you can’t. That sort of browser affinity feels uncommon. After hitting a couple of sites that insist on Chrome, I suspect most users would be gone for good. Firefox has suffered from this for years.

I don’t know the solution. Personally, I want multiple rendering engines to thrive on all platforms. But the majority of real-world developers have to be willing to consistently prioritize and put real money behind that goal. As it stands today, Apple has unique leverage through iOS to force that willingness.

"People are lazy"

Then why aren't they just using Safari on Macs? Why install Chrome at all, if all of this is just a matter of laziness?

"expect only good enough, hence PWAs"

Or, alternatively, web apps have advantages that make them genuinely better options than native apps for many people in many situations.

"There is a base assumption under all of this: that anything Google comes up with is automatically a good thing for the web and that everyone else is "falling behind"."

I don't know if anyone has such a "base assumption," but I've never seen it. What I *have* seen is people who build web apps investing a lot of resources just to get them to run adequately on Safari, which often makes up a single-digit percentage of their user base.

"Google's propaganda has worked so well that if they were allowed on iOS, that would be it forever"

Or it would force Apple to actually compete with Chrome, which would result in Safari working much better across a wider swatch of websites, which would result in more people using Safari, which would result in Chrome being less of a dominant force.

It's very obvious that Apple sees web apps as a threat. But instead of offering an alternative that is genuinely better, their approach is to harm progress for web apps as much as possible, by directly holding up W3C standards, or just not implementing them in Safari. That's not good for anyone - long-term, not even for Apple, because all it really achieves is solidifying Google's stranglehold over the web.

What I've seen are two set of entrepreneurs calling it quits at our first meeting because I told them about Apples 30% tax. All of their needs could have bee met with a fairly simple PWA on android, but not on iOS.

Fighting a dominant player by clinging on to a monopoly is hare brained. It's also delicious to see how fast people seem to have forgotten about Apples latest security blunder. The one where all browsers on iOS were compromised because.. "We care about your integrity"

@bob Brave on iOS has to use WebKit, so it loses the compatibility benefits.

@Plume Yes, exactly. It’s like, suppose (back when it was new) that you think JavaScript on the Web is a bad idea. Honestly, I do find sites that overuse it annoying, and I often wish that certain pages were more like plain old documents. But JavaScript has good uses, too, and a browser without JavaScript is not going to have good survival characteristics. Especially if it offers no compelling alternative vision and drops support for the most popular desktop operating system. You can’t just sit on the sidelines and tell people they shouldn’t want JavaScript.

And now we are in a situation where Chromium already has dominant marketshare. There doesn’t seem to be a strategy to try to catch it because Apple disagrees with the entire direction. I guess one can look at this as a noble stand for Apple’s restricted vision of the Web, but in practice it leads to Google having more control over how the Web evolves. Apple can’t stop Google by ignoring it. The best case for the current path seems to be that Apple is able to slow things down a bit, thread the needle, and stay just close enough behind that its users don’t jump ship. Meanwhile, software continues to move to the Web because of the inherent server-based/multi-platform advantages and Apple’s war with native developers.

I see a lot of what I can best describe as entitlement on the part of many web app evangelists, where they consider anything that lands in Chrome/ium to be a de facto web standard and Safari therefore instantly as dragging down the web by not adopting it there and then. This is at odds with the fact there is an actual web standards body that defines them, and while many Chrome features are at least proposed standards, some aren't. Moreover, even in the former case Apple has rejected implementing some features, at least as currently defined, because of privacy concerns (e.g. your battery level or Bluetooth environment could be used as a fingerprint). Finally, in some cases Chrome provides an API purely as a way to ostensibly bridge the gap between web apps and native apps, only for everyone to later realize the API is so ill-thought out and deficiet in its principle that redoing it completely is necessary; for me, this is what best characterizes Application Cache, which was so exposed by Jake Archibald's legendary article as having no clothes that it had to be not updated, but entirely replaced as a standard by Service Workers (not the best example since AppCache did get implemented in Safari, but there are other such APIs).

Don't get me wrong, I am sympathetic to some of these concerns, especially as I am investigating not so much PWA as offline-only web apps as a way to circumvent Apple's Gatekeeper, and as a result have to forego some niceties only available in Chrome so that what I do works out of the box on the Mac or at all on iOS, but let's just say not all criticism of Safari I see on the web appears grounded in sound engineering…

We found a number of bugs around media playback and CSS when working on NPR's "Joy Generator" stories. We wrote them up here: http://blog.apps.npr.org/2021/08/31/joy-generator.html

I'm actually sympathetic to the idea that Safari isn't going to implement stuff like WebUSB or Bluetooth or whatever. As a web developer, I don't miss those. But a browser that can't reliably play video, has restrictions on audio, breaks IndexedDB on a regular basis, has slow paths for CSS animations that aren't documented, and so on... it's not that Safari fails to keep up with the bleeding edge, it's that it's also not reliable for the features that it does implement, and that were standard years ago.

"they consider anything that lands in Chrome/ium to be a de facto web standard"

There literally are standards, and Apple is sabotaging them, and when sabotage fails, ignoring them.

"what I can best describe as entitlement on the part of many web app evangelists"

They're such entitled brats for wanting to provide good products to iOS users, and not wanting Google to own the web.

"because of privacy concerns"

Because there's absolutely no way Apple could possibly figure out how to implement these standards in a way that respects their users' privacy.

In the end, none of these points really matter, because you're arguing about whether Apple's principles are well-intentioned, while everyone else is arguing about the actual real-world outcome their behavior produces, which is to hand monopolistic control over the most important application platform to Google.

I'm sure everybody at Apple has the best of intentions. Meanwhile, Google has market share, which matters a lot more than intentions.

“they consider anything that lands in Chrome/ium to be a de facto web standard”

There literally are standards, and Apple is sabotaging them

I don’t think that paints an accurate picture.

A lot of the time, 1) Chromium implements a feature, 2) Google immediately submits a draft spec for a potential future standard, 3) web developers start using the feature, 4) web developers realize WebKit doesn’t implement it yet and blame Apple.

For example, yes, Chromium has implemented Web USB for years, and Safari doesn’t. But Web USB has the status of “Draft Community Group Report”.

Is Apple “sabotaging” standards? In some cases, maybe. In other cases, they raise objections to refine the standard. Which you would think is how a standards process should work: multiple stakeholders ultimately agreeing on a compromise.

In effect, Chromium tries to unilaterally push their vision of the Web. That said, I will agree that Apple needs to push harder for theirs.

What I argue (or at least, I think I do) is that Google gets so much credit on the part of most web developers that it benefits from a double standard, in which ways where Chrome "thinks different" tend to be interpreted as a common good, while ways where Safari "thinks different" tend to be interpreted as hostile animus.

And I have proof of that.

For the longest time, support for File APIs in Chrome was slow (it may still be; I haven't been able to check lately), much slower than in other browsers, because of overhead (on the order of a few milliseconds) per call to a file API, regardless of the size of data loaded: http://www.romhacking.net/forum/index.php?topic=20730.msg294230#msg294230 . I had to develop an asynchronous cache specifically so that performance would be acceptable in Chrome: the cache does not so much help by reducing the frequency of file system accesses per se, than by reducing the frequency of calls to the web APIs: even the recommended postMessage() to ourselves features unacceptable overhead on Chrome.

The second proof is this crasher, that is impossible to work around, and which they never fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=776572 . In a comparable situation, the WebKit guys treated my report seriously: https://bugs.webkit.org/show_bug.cgi?id=164458 (I confirmed the fix when it landed in tech preview 19).

Don't get me wrong, I have no trouble believing that Safari has more issues and is less conductive to PWA development than Chrome. But as much as Safari does need a swift kick in the ass in specific areas, making it subject to unfair criticism is not the way to accomplish that.

"A lot of the time, 1) Chromium implements a feature, 2) Google immediately submits a draft spec for a potential future standard, 3) web developers start using the feature, 4) web developers realize WebKit doesn’t implement it yet and blame Apple."

That's not what happens. People are completely aware of the fact that implementing stuff takes time.

What actually happens is that Apple just flat-out announces that they're going to ignore finished standards like the Web MIDI API (which just happens to be a standard that threatens its control over app development, which, peculiarly, seems to be the case for many of the standards Apple elects to pretend don't exist, or implements in an intentionally broken way).

Apple seems to think that ignoring Web MIDI hurts Web MIDI, but actually, it just means that more things will tell people to install Chrome.

"in which ways where Chrome "thinks different" tend to be interpreted as a common good, while ways where Safari "thinks different" tend to be interpreted as hostile animus"

Assuming you're right, so what? Chrome has the market share, they gained it fair and square, not through OS bundling, but through being better. Even if that's the only reason people default to using it as the primary dev target platform, that still doesn't help Safari.

Apple can either whine about how unfair everybody and the universe is, or they can compete. If they don't want Google to gain monopolistic control over the web, I suggest they start doing the latter.

"making it subject to unfair criticism is not the way to accomplish that"

At this point, I have almost monthly meetings with my devs where they implore me to finally make the decision to drop support for Safari, every time coming up with a fresh new list of things they had to work around. This is not "unfair criticism", this is a browser that requires much more investment than either Chrome or FF, produces worse outcomes than both of these, pisses off developers, and commands a minuscule market share in many cases.

This is a bad situation, and pretending it isn't bad isn't going to make the bad go away, it's only going to make Safari go away.

What actually happens is that Apple just flat-out announces that they’re going to ignore finished standards like the Web MIDI API

Firefox objects to it as well, citing security concerns.

It’s also not a “finished standard”; it’s in draft status.

Chrome has the market share, they gained it fair and square

Oh come on. They gained it by heavily advertising for it on their own platforms and by implying in some of those ads that something about non-Chrome browsers as inherently inferior. Google can and does play dirty when it feels like it.

Nothing about the browser market has every been “fair and square”. There was never a time when people actually made an informed choice and installed the browser they thought was best. It was either the browser the ISP bundled for them, or the browser bundled by the OS, or the browser that lied about other browsers.

Between being advertised on Google.com and being preinstalled on a device, I’d have to say being preinstalled is the weightier side of the scale.

Speaking of chrome exclusives, look at this
https://runwayml.com

Quick and powerful video editing in the browser

By the way, for any interested party I found more specific references (that I initially misplaced) on the file API slowness in Chrome:
- Mailing list discussion (note the praise for providing a detailed, researched, actionable report) https://groups.google.com/a/chromium.org/g/chromium-discuss/c/iKxJ8FKCJzU/m/wsNJYlchCQAJ?pli=1
- NPM package for a JavaScript file API cache so trivial that it ought not provide a 10x performance improvement compared to directly calling browser APIs, yet here we are; description contains benchmarking in various situations https://www.npmjs.com/package/simple-file-cache
- Chromium bug, which I did not start but contributed to. Still unsolved. https://bugs.chromium.org/p/chromium/issues/detail?id=349304