Comment by noduerme | Hacker News Reader

Comment by noduerme | Hacker News Reader

I think it's bizarre to conflate Apple's refusal to allow other webkits on iOS with the fact that Safari remains a viable alternative engine. They're far from heroes here. I think it's great they maintain a Chrome alternative kit that mostly works but let's not pretend they're saints or kid ourselves about the reasons for it. The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in user base to dictate terms. It's only being one of the richest companies in history that gives them a seat at the table. If they're afraid of having to open the platform, that's because they're not keeping up.

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.

> The only reason they disallow Chromium and Mozilla is they want their users locked into their environment and they want to leverage that substantial locked-in user base to dictate terms

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.

> 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.

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.

You’re completely cutting off the other half of their post which makes sense with the context you’re quoting.

"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."

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?

> Why don't they do this?

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.

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

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?

This isn't a competition for 'most secure' necessarily. Rather, simply reducing the surface area for attack is positive from a security perspective. If there's some vulnerability in iOS that come from being able to make pages executable, if you only have Safari JIT-ing you have to find a bug in Safari, or the app store review process (and get the user to download your app). If iOS runs Chrome as well, you can find a bug in _either_ Safari _or_ Chrome.

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).

I don't think an audit will be able to even coming close to validate the security of a piece of software with the complexity of a browser.

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")

"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."

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.

Apple thinks (and I'm inclined to agree) that no browser engine is safe enough to be on the platform but as there has to be at least one by necessity, they might as well reduce the attack surface by restricting it to a single one that's tightly integrated with the OS security measures and which is updated together with other OS updates.

Following that reasoning there should only be one app of each kind on the platform: an Apple app.

Minimize attack surface, minimize choice.

A calendar app provides a much smaller attack surface than a browser. It can also perform good enough without the need for JIT compilation.

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

What do you think an audit is, and why do you think you can even approach a useful one on a codebase the size of WebKit? It's not realistic.

Having an engine monoculture doesn't actually reduce attack surface. People don't visit each web page with every browser they have installed on their device.

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.

battery life is another stated reason I believe.

It’s a big one. Google and Mozilla don’t prioritize efficiency, and it shows in the difference in battery life between using Safari and Chrome or Firefox on macOS.

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 can slip one line of code into a modern website that'll target a particular iphone model and run its battery to nothing in half an hour, and probably crash safari as well. Any language is susceptible to badly written or malicious code. At least with Flash it was in a box, in a virtual machine, and you had to approve it and could kill it at any time.

Having a smartphone battery that lasts more than an hour is also a pretty good 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?

It's because there's nothing magical about HTML that makes it more battery efficient than Flash was. Quite the opposite really - Flash is a compact binary format designed specifically for high graphics performance in an era when HTML4 thought floating menus was cutting edge.

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".

There’s nothing “magical”, but Safari uses a lot less battery than Chrome.

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

Right, yet, Chrome has an enormous number of Mac users. Apple argue that battery life is a topic so important it's worth banning competitors for but clearly when given the choice users disagree. There are other things more important to them.

My impression is that most computer users have a limited sense of which software applications are churning through battery, and instead just blame the computer vendor.

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.

Flash didn’t have to be inefficient, but Adobe’s implementation certainly was. I remember the Mac version of Flash pegging the CPUs of PPC G5 and Core 2/Core 2 Duo based machines, turning them into space heaters until the user navigated away from the page containing flash elements. For the vast majority of what Flash got used for, that was in no way justifiable, particularly on devices like laptops and smartphones.

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.

SWF is a compact format, but that doesn't get you an efficient Flash Player. Apple put in a lot of work to make HTML battery efficient and usable on a phone, and Adobe didn't[0] do the same with Flash. In fact, Apple more or less begged Adobe like four times to make Flash work well on phones! Adobe wanted to push that work onto their customers instead of putting work into making every Flash movie ever authored work good on a phone.

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.

Adobe expecting Flash authors to make versions optimized for mobile wasn't particularly crazy though, was it? That's exactly what browser makers expect mobile site developers to do. A non-mobile optimized site mobile is an awful experience.

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.

>> Adobe expecting Flash authors to make versions optimized for mobile wasn't particularly crazy though, was it?

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.

People who don't know conflate Flash as a browser plug-in with all AS3 (e.g. Air apps that run in a native container). You couldn't expect a browser plugin at that time to have GPU access, but Air apps sure did and we used it all the time to make our games run smoothly.

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.

> 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.

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.

> The web is a great threat to their app (and also subscription) revenue stream

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.

You do realize web apps can be packaged up and distributed on the Play Store and work just like regular apps on Android, and so YouTube Music among others are already web apps. Pretending like no one is interested when we're talking about probably close to 100 million users or more for a single web app is disingenuous. Apple is a walled garden and their cultist will make up any excuse to not have to admit so.

Web apps can be packaged up and distributed on App Store as well.

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.

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

> 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/

I can take a mobile web site, wrap it in a browser component and publish it to the App Store. Now I will lose one of the advantages of PWA e.g. remote updates but everything else I can do e.g. push notifications, access device APIs.

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.

Does this argument matter to the question of Apple allowing Chromium?

I think you're ignoring the fact that App Store didn't allow PWAs until fairly recently, among a bunch of other things. Mobile web apps aren't slow or clunky or feature-poor and you can design your interface however you want now... except on Apple products. It sounds like your issue is the poor support from Apple, which is exactly what I was getting at. I'd encourage you to read through the blog post I linked here:

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.

I don't think anyone argues that developers and companies don't want to make web apps. Clearly, many of them are interested in that.

> If they're afraid of having to open the platform, that's because they're not keeping up.

webkit is a bit behind in some areas like APIs but ahead in others like CSS

Reply on news.ycombinator.com