Web Developers Form Advocacy Group to Allow Other Browser Engines on iOS

[LV426]

You've had IndexedDB bug leaking data all over throughout 57 days and you call this petition a "compromise" of your "security" & "privacy", guess you didn't even read the article. Also, your "privacy & security" are no better than most browsers, in fact worse than some.

That's not correct.

The IndexedDB vulnerability was reported to Apple as a possible attack vector on 28 Nov, but not disclosed to a wider audience until 20 Jan.

A fix was released in iOS 15.3 on 23 Jan, three days later.

"Leaking data all over throughout 57 days" is an exaggeration. I suspect that, in the grand scheme of things, very few users would have leaked data in the few days between public disclosure and its fix, and massively fewer affected between 28 Nov and 20 Jan.

 

[nvmls]

That's not correct.

The IndexedDB vulnerability was reported to Apple as a possible attack vector on 28 Nov, but not disclosed to a wider audience until 20 Jan.

A fix was released in iOS 15.3 on 23 Jan, three days later.

"Leaking data all over throughout 57 days" is an exaggeration. I suspect that, in the grand scheme of things, very few users would have leaked data in the few days between public disclosure and its fix, and massively fewer affected between 28 Nov and 20 Jan.

Sure, believe suspicion since these people who wrote 108 pages PDF have no clue what they're talking about.

This is from January 14th, guess Apple sources are a bit slow, like their apps roadmap.

 

[theotherphil]

Safari. Why? Because it's the default browser. That is the huge power Apple has, and always will have. Safari is in no danger of being 'dominated'.

Or maybe because they actually prefer Safari? I do…. integration with the system and my other devices is good and there’s no faster browser on MacOS.

 

[LV426]

Sure, believe suspicion since these people who wrote 108 pages PDF have no clue what they're talking about.

This is from January 14th, guess Apple sources are a bit slow, like their apps roadmap.

...which gives precisely zero indication of how much data was actually leaked in the small window of time that the vulnerability remained a) known and b) unpatched. At the risk of repeating myself, Apple patched it within 3 days of public disclosure which kind of rubbishes the argument that WebKit (and thus iOS Safari) doesn’t get security updates in a timely manner.

 

[rejhgadellaa]

LV426:

I disagree. Apple are more than capable of rolling out minor OS updates to address important security issues in short shrift. I believe that happened not so long ago. Since WebKit is used extensively throughout iOS, as well as by Safari, a security problem is de facto an operating system problem.

Apple do not provide arbitrary updates to individual operating system components, e.g. WebKit (and many other components). They probably could if they wanted, but that could complicate matters for end users. They know where they are with the version of iOS they have installed. Things could get a lot more complicated if iOS and the numerous components it depends on had separate update mechanisms. As has been discussed earlier, WebKit is shared all over the place in iOS for efficiency reasons.

First of all, shipping an OS update is always going to take more time than updating a single app. Second, users tend to postpone OS updates because they take your entire device out of commission for 15~30 minutes (black screen, apple logo, loading bar).

Decoupling WebKit updates is something Apple should do anyway. Google has been doing it for at least 7 years. That's how they update every in-app browser like Facebook, Twitter, etc, in one swoop.

As far as I'm concerned, Apple WebKit gets updated quite often enough. Minor OS updates happen relatively quickly. I certainly wouldn't want to see Apple forced into accepting flaky WebKit 'standards' that compromise my security and privacy.

We're not trying to force WebKit to accept standards they don't feel comfortable with.

We do want other browsers being able to deliver those features and leave it up to developers and users to make a choice.

We do want users to be able to temporarily switch to another browser when Apple takes weeks to plug a major privacy leak (indexeddb, ~60 days) or bugs that break entire sites (indexeddb/localstorage, early 2021).

Just take a look here and tell me the speed at which Apple fixes security bugs is okay (compared to other browsers):

https://pbs.twimg.com/media/FM73b7lVQAA1xg6?format=png&name=large

 

[Sophisticatednut]

The question is not whether or not webkit only is secure. It's not. The question is whether webkit only is more secure than the alternative.

"Don’t compare me to the Almighty, compare me to the alternative."

Well it’s less safe than the alternative. Chrome and all its variations and Firefox is safer and better than safari on the simple fact Biggs and security holes are patched immediately compared to safari WebKit being patched with every iOS update.

 

[rejhgadellaa]

The counter argument to this (and I do wish people would stop saying that other iOS browsers are wrappers around Safari - they use WebKit is all)...

Imagine you have four different browser installed on iOS, and each of them has its own version of WebKit. If each version shares a similar vulnerability (they are all forked from the same base), than all four browsers put you at risk. Other core iOS will also be putting you at risk, since WebKit is a shared iOS component.

Now, that means Apple plus the other three browser vendors will have to update their codebase in order to make your life safer. I'm not sure that really constitutes safe practise.

Ok browsers on iOS are wrappers around a very specific build of WebKit that ships with the OS. The difference with browsers like Chrome, Edge, Brave, etc, is that they ship their own version of the engine. They can turn on/off things, add/remove features. Browsers on iOS can't.

Regarding security: you assume that all browsers share the same vulnerability because they use the same code base. First of all, on iOS, they share the exact same build (exception is Safari which has a slightly different build, long story). Every bug, security and/or privacy issue will affect every single browser, period. Yes, being able to update all those browsers in one sweep is effective - but than Apple would need to drastically improve the speed at which they churn out those updates. Currently, they are pretty far behind, see:

https://pbs.twimg.com/media/FM73b7lVQAA1xg6?format=png&name=large

The argument for having multiple browser engines is that users can temporarily switch to a browser that is not affected instead of having a 100% attack surface for an entire platform.

Both mechanisms have advantages and drawbacks, but I would argue that decoupled WebKit updates (faster deployment to users, less friction), combined with browser choice, is the way to go.

 

[rejhgadellaa]

That's not correct.

The IndexedDB vulnerability was reported to Apple as a possible attack vector on 28 Nov, but not disclosed to a wider audience until 20 Jan.

A fix was released in iOS 15.3 on 23 Jan, three days later.

"Leaking data all over throughout 57 days" is an exaggeration. I suspect that, in the grand scheme of things, very few users would have leaked data in the few days between public disclosure and its fix, and massively fewer affected between 28 Nov and 20 Jan.

The bug was disclosed on january 14 (as already pointed out in this thread). Not sure what your date is based on?

Anyway, you don't start counting when a bug is publicly disclosed, you start counting when the bug is reported (28 nov) - and security bugs are usually fixed and shipped before the public disclosure. FingerprintJS decided to go public because they had not received word from Apple when the fix would land (I think they hadn't even fixed it yet but I could be completely wrong) and they wanted to warn users that they were leaking their browser history and data left and right.

According to Project Zero, Apple very seldomly lands fixes in < 3 days, more like 30 at the earliest:

https://pbs.twimg.com/media/FM73b7lVQAA1xg6?format=png&name=large

 

[theotherphil]

Currently, they are pretty far behind, see:
https://pbs.twimg.com/media/FM73b7lVQAA1xg6?format=png&name=large

Do you have an actual source for this image please so we can see the context behind it? At the moment, it’s just a random image linked from Twitter. Was this 2009, 2012, 2018? Is this worldwide or from users to a specific website? Who compiled it, where is the data taken from and what were their intentions?

 

[rejhgadellaa]

Do you have an actual source for this image please so we can see the context behind it? At the moment, it’s just a random image linked from Twitter. Was this 2009, 2012, 2018? Is this worldwide or from users to a specific website? Who compiled it, where is the data taken from and what were their intentions?

Ah sorry. The graph is taken from Project Zero's latest report (feb 2022):

A walk through Project Zero metrics

Posted by Ryan Schoen, Project Zero tl;dr In 2021, vendors took an average of 52 days to fix security vulnerabilities reported from Projec...

googleprojectzero.blogspot.com

 

[BaldiMac]

Well it’s less safe than the alternative. Chrome and all its variations and Firefox is safer and better than safari on the simple fact Biggs and security holes are patched immediately compared to safari WebKit being patched with every iOS update.

One "fact" that isn't even true is not a complete security comparison.

 

[huge_apple_fangirl]

Decoupling WebKit updates is something Apple should do anyway. Google has been doing it for at least 7 years. That's how they update every in-app browser like Facebook, Twitter, etc, in one swoop.

Yes.

We're not trying to force WebKit to accept standards they don't feel comfortable with.

We do want other browsers being able to deliver those features and leave it up to developers and users to make a choice.

But if WebKit doesn't support the features you want, then you won't support WebKit. If Apple believes PWAs are bad, and won't support them, and then developers make them anyways and tell users to download Chrome... well then either WebKit will die, or Apple will be forced to support features they don't believe in.

We do want users to be able to temporarily switch to another browser when Apple takes weeks to plug a major privacy leak (indexeddb, ~60 days) or bugs that break entire sites (indexeddb/localstorage, early 2021).

Would anyone really switch over that anyway? If they're the type of person who follows this, they probably factored that in to their decision to stay/leave iOS.

Just take a look here and tell me the speed at which Apple fixes security bugs is okay (compared to other browsers):

https://pbs.twimg.com/media/FM73b7lVQAA1xg6?format=png&name=large

That is a problem. But your solution brings other problems.

 

[webkit]

But if WebKit doesn't support the features you want, then you won't support WebKit. If Apple believes PWAs are bad, and won't support them, and then developers make them anyways and tell users to download Chrome... well then either WebKit will die, or Apple will be forced to support features they don't believe in.

This is kind of the nature of business. If a company doesn't meet the needs of suppliers, vendors, customers, etc. they risk losing share. It's not unusual for companies to do things they may not “want” to (and I'm assuming no opposing illegal/antitrust issues are in play) in order to remain relevant, keep or increase share, make money, etc.

 

[LV426]

you don't start counting when a bug is publicly disclosed, you start counting when the bug is reported (28 nov)

But you don't start counting the time it is being exploited from this date. When it isn't.

security bugs are usually fixed and shipped before the public disclosure.

This is true, and we can all be thankful for that.

FingerprintJS decided to go public because they had not received word from Apple when the fix would land

I do agree that Apple were not behaving responsibly by not engaging with FingerprintJS. They shot themselves in the foot by leaving them in the dark. Note to Apple: don't do such a silly thing in future.

 

[LV426]

I would argue that decoupled WebKit updates (faster deployment to users, less friction), combined with browser choice, is the way to go.

I disagree. It is really not necessary at all to decouple WebKit deployment, providing the OS can be updated in a timely manner.

If a severe security bug in iOS were discovered today, Apple could release an OS update tomorrow if necessary. This is something I have done myself with complex systems. Branching and merging happens all the time. Apple are never in a position where they couldn't release an important fix to the OS, even if it's just a couple of lines of code that makes all the difference.

I absolutely do not want to see random WebKit libraries installed by third party vendors. They are inherently dangerous.

 

[rejhgadellaa]

I disagree. It is really not necessary at all to decouple WebKit deployment, providing the OS can be updated in a timely manner.

If a severe security bug in iOS were discovered today, Apple could release an OS update tomorrow if necessary. This is something I have done myself with complex systems. Branching and merging happens all the time. Apple are never in a position where they couldn't release an important fix to the OS, even if it's just a couple of lines of code that makes all the difference.

I absolutely do not want to see random WebKit libraries installed by third party vendors. They are inherently dangerous.

According to Project Zero's report, they have seldomly shipped an update within one day of fixing the issue (fixing takes time, too, that's totally fine as long as it doesn't take almost two months...). But yes, they have done so 3 or 4 times if I read the graph correctly. More often, it takes at least 30 days:

A walk through Project Zero metrics

Posted by Ryan Schoen, Project Zero tl;dr In 2021, vendors took an average of 52 days to fix security vulnerabilities reported from Projec...

googleprojectzero.blogspot.com

Regarding apps shipping WebKit libraries: first of all we want browsers to (be able to) ship their own, full engines, not just a webkit variant. Secondly, we do not want apps like Facebook saying "we are a browser!" and ship their own in-app browser engine. In-app browsers should use webviews or, preferably, something like Custom Tabs (a webview provided by the user's default browser).

Shipping your own full browser engine should basically only be possible if the app is a browser (apple already has rules for this for apps that want to be able to be default browsers and email clients).

Candy Crush should not be able to ship a browser

 

[LV426]

Regarding apps shipping WebKit libraries: first of all we want browsers to (be able to) ship their own, full engines, not just a webkit variant. Secondly, we do not want apps like Facebook saying "we are a browser!" and ship their own in-app browser engine. In-app browsers should use webviews or, preferably, something like Custom Tabs (a webview provided by the user's default browser).

We will have to agree to disagree. On a mass-market iOS device, I don’t want third party browsers putting privacy and security at risk. Currently you can install multiple browsers on iOS and none of them have the ability to use dodgy WebKit features.

Better that browser vendors get their heads together.

 

[rejhgadellaa]

We will have to agree to disagree. On a mass-market iOS device, I don’t want third party browsers putting privacy and security at risk. Currently you can install multiple browsers on iOS and none of them have the ability to use dodgy WebKit features.

Better that browser vendors get their heads together.

Hehe yeah I think we disagree..

Just to set the record straight, according to the data I shared earlier, it's Apple that currently puts users' security and privacy at risk:

- by enforcing a monoculture where every single user is vulnerable against the same issues with no option to (temp) switch to a safe browser while a fix is yet to be shipped (making it a very lucrative target: 100% success rate).
- by being slow to ship those fixes to users

Finally, you say "I don't want 3rd party browsers on a mass-market device to put user's security and privacy at risk" as if Android, Windows, macOS and Linux haven't had 3rd party browser engines for decades - browsers that ship security and privacy issues a LOT faster than Apple.

These are just facts, unfortunately...

Btw, I am very glad that all browser vendors are coming together and improve the web ?

 

[LV426]

Hehe yeah I think we disagree..

Just to set the record straight, according to the data I shared earlier, it's Apple that currently puts users' security and privacy at risk:

- by enforcing a monoculture where every single user is vulnerable against the same issues with no option to (temp) switch to a safe browser while a fix is yet to be shipped (making it a very lucrative target: 100% success rate).
- by being slow to ship those fixes to users

Finally, you say "I don't want 3rd party browsers on a mass-market device to put user's security and privacy at risk" as if Android, Windows, macOS and Linux haven't had 3rd party browser engines for decades - browsers that ship security and privacy issues a LOT faster than Apple.

These are just facts, unfortunately...

Btw, I am very glad that all browser vendors are coming together and improve the web ?

Well, I can't leave it at that, ho ho.

Why randomly pick on a browser susceptibility in particular as an example of the woes of a monoculture? Do you have the option of installing a new network stack if there is a problem with iOS TCP/IP underlying mail apps? If the cellular modem has a firmware issue, can you load that from somewhere else? Can you fix a Bluetooth security issue by installing a third party app? Of course, you can't. I could go on, and on. Apple see this "monoculture" as a distinct advantage in that they have control over the core libraries that get installed on an iPhone, and they can address security issues for millions of users in one place, fixing multiple apps simultaneously (e.g. all the iPhone apps that make use of WebKit).

3 days after public disclosure to fix, test and deploy a security update is not exactly slow. I'm pretty sure that iOS users are, one the whole, much better protected from the ills of the internet than, for example, Android users. Because of Apple's practices. You're going to have to try very hard to convince the world that Apple puts more users at risk than other phone vendors.

 

[nvmls]

 

[rejhgadellaa]

Well, I can't leave it at that, ho ho.

Haha yeah, couldn't help myself, neither can't you I guess.. so here we are

Why randomly pick on a browser susceptibility in particular as an example of the woes of a monoculture? Do you have the option of installing a new network stack if there is a problem with iOS TCP/IP underlying mail apps? If the cellular modem has a firmware issue, can you load that from somewhere else? Can you fix a Bluetooth security issue by installing a third party app? Of course, you can't. I could go on, and on. Apple see this "monoculture" as a distinct advantage in that they have control over the core libraries that get installed on an iPhone, and they can address security issues for millions of users in one place, fixing multiple apps simultaneously (e.g. all the iPhone apps that make use of WebKit).

Say your browser, network stack and bluetooth have a vulnerability, wouldn't you want to plug as many holes, as fast as possible instead of being vulnerable against all three?

3 days after public disclosure to fix, test and deploy a security update is not exactly slow. I'm pretty sure that iOS users are, one the whole, much better protected from the ills of the internet than, for example, Android users. Because of Apple's practices. You're going to have to try very hard to convince the world that Apple puts more users at risk than other phone vendors.

Shipping a fix *after* public disclosure is basically the definition of slow, especially if you see how Apple took ~60 days to fix and ship it, where Chrome and Firefox tend to be much faster (see the chart I shared before).

Again, the time it takes to fix and ship a security fix is counted from the day it's privately disclosed, not when the researcher feels obligated to disclose it publicly because users are at risk and the company responsible for fixing it remains silent.

Also, again, the bug was publicly disclosed on Jan 14th, so the time between disclosure and shipping the fix is more like 10 days. You keep saying it was 3, where did you get that information?

(Sorry if I sound snarky, it's getting late - early, actually - just wanted to get out my arguments before going to bed)

 

[Sophisticatednut]

One "fact" that isn't even true is not a complete security comparison.

Well it’s factual.
If competing browser engines/forks such as edge, opera, chrome, Firefox etc can provide faster security updates and patch issues. And historically have done so faster than apple who is forced to provide a complete iOS update instead of a small application update, then safari is objectively less secure.

I disagree. It is really not necessary at all to decouple WebKit deployment, providing the OS can be updated in a timely manner.

True, apple unfortunately can’t evidently provide timely updates to WebKit

If a severe security bug in iOS were discovered today, Apple could release an OS update tomorrow if necessary. This is something I have done myself with complex systems. Branching and merging happens all the time. Apple are never in a position where they couldn't release an important fix to the OS, even if it's just a couple of lines of code that makes all the difference.

True, but we are talking about security patches for the browser, there is no reason to tie it to iOS updates. Older iOS devices or even enterprise deployments can easier test compatibility with a singular update of a program than an entire OS update

I absolutely do not want to see random WebKit libraries installed by third party vendors. They are inherently dangerous.

Why would you se that? iOS currently doesn’t allow any forks of WebKit and just use the system provided WebKit library with customer settings and skin. This is made up issue

 

[Sophisticatednut]

Well, I can't leave it at that, ho ho.

Why randomly pick on a browser susceptibility in particular as an example of the woes of a monoculture? Do you have the option of installing a new network stack if there is a problem with iOS TCP/IP underlying mail apps? If the cellular modem has a firmware issue, can you load that from somewhere else? Can you fix a Bluetooth security issue by installing a third party app? Of course, you can't. I could go on, and on. Apple see this "monoculture" as a distinct advantage in that they have control over the core libraries that get installed on an iPhone, and they can address security issues for millions of users in one place, fixing multiple apps simultaneously (e.g. all the iPhone apps that make use of WebKit).

3 days after public disclosure to fix, test and deploy a security update is not exactly slow. I'm pretty sure that iOS users are, one the whole, much better protected from the ills of the internet than, for example, Android users. Because of Apple's practices. You're going to have to try very hard to convince the world that Apple puts more users at risk than other phone vendors.

It’s the fact users have the ability to use different browsers by simply opening a different app.

Users today have the ability to use completely different mail solutions with custom software not related to iOS mail.

Cellular modems firmware isn’t something people tend to change… compared to a different app.

A browser isn’t comparable. Users used different browsers with different abilities and features for personal preferences. A website looks funky, use a different browser. A critical security flaw, change the default browser for a few days.
No library is needed to compromise iOS.

Or would you argue games are only allowed to use one engine? Only Unity, or only UR4 or UR5 or godot or only Clickteam Fusion etc etc?
Or the day apple makes their own game engine, it should be the only allowed technically?

 

[Sophisticatednut]

Well, I can't leave it at that, ho ho.

Why randomly pick on a browser susceptibility in particular as an example of the woes of a monoculture? Do you have the option of installing a new network stack if there is a problem with iOS TCP/IP underlying mail apps? If the cellular modem has a firmware issue, can you load that from somewhere else? Can you fix a Bluetooth security issue by installing a third party app? Of course, you can't. I could go on, and on. Apple see this "monoculture" as a distinct advantage in that they have control over the core libraries that get installed on an iPhone, and they can address security issues for millions of users in one place, fixing multiple apps simultaneously (e.g. all the iPhone apps that make use of WebKit).

Let’s for argument sake say. You have a vulnerability in the 4G modem, Bluetooth chip, WebKit browser, iMessage services, iOS sandbox feature, iOS wallet and pages.

Do you want to fix everything in a bigger update or provide updates as soon as they are available?

Why not update WebKit(safari), pages, iMessage and iOS wallet through the AppStore as an app update when ready and update iOS sandbox, Bluetooth chip, and 4G modem through a separate iOS update?

Why insist on bundling it for no advantage? You could still provide WebKit as a core part that apps use if safari or other browsers/engines aren’t installed such as chromium and it’s fork’s or Firefox gecko etc etc

 

[BaldiMac]

Well it’s factual.
If competing browser engines/forks such as edge, opera, chrome, Firefox etc can provide faster security updates and patch issues. And historically have done so faster than apple who is forced to provide a complete iOS update instead of a small application update, then safari is objectively less secure.

No, it's not factual that "bugs and security holes are patched immediately" on Android. Nor does the one fact that they are patched with application updates make iOS web browsing less secure overall.