4 ms·

> Because you are not running all of them at the same time, you are only running one of them This is not true. The moment Apple allows different browser engine

by planb 3y ago

> Because you are not running all of them at the same time, you are only running one of them This is not true. The moment Apple allows different browser engines, my Gmail app would use blink. As a browser, I’d maybe use Firefox/gecko and all Apple apps would still use the embedded WebKit. Yes, this is my choice and I would do it knowing I’m increasing my attack surface, but apple‘s reasoning is not false…

AnthonyMouse 3y ago
A given application is still not using more than one browser engine. If there is a vulnerability in Webkit and all apps have to use Webkit, all apps are vulnerable. If only a third of apps use Webkit, only a third of apps are vulnerable. A different third of apps might be vulnerable if there is a vulnerability in Blink. When the security record of each browser engine is comparable, this isn't a net increase in exposure, it just averages out to the same. When the others have a better record -- and Google and Mozilla have both introduced a number of novel security and privacy features -- then the net exposure goes down. Meanwhile having the choice is a security advantage because a) the user could choose the one with the best security record, whether or not it's Apple's and b) if there is an active vulnerability in Safari today then the user can use Chrome or Firefox today, and then do the reverse on the day there is an active vulnerability in Chrome. The main concern people seem to have with this is the one which is also caused by Apple -- apps might embed a browser engine and then if it's vulnerable you have to update lots of apps. But this is only because of their lacking support for independent libraries. If the Firefox browser engine was provided as an iOS library by Mozilla then Mozilla would update the library and every app that uses it would get the update at once. That problem is only caused by this not being supported. And is a problem that extends to more than browser engines. Apps can't use their own browser engines, but they might incorporate some common third party code that doesn't require JIT compilation, and then if someone finds a vulnerability in that code you still have to update a zillion apps. Specifically because the code isn't distributed as a dynamic library by its developers and instead gets copied into each app independently -- which not only impairs security but takes up more storage and memory to have multiple copies of the same code.
- astrange 3y ago
  > A given application is still not using more than one browser engine. That doesn't seem true, I can easily imagine an app that's based on Firefox but can still cause a WebKit page to open, you just need a system API that uses WebKit. > If the Firefox browser engine was provided as an iOS library by Mozilla then Mozilla would update the library and every app that uses it would get the update at once. That's not how the app update lifecycle works, they're all independent. (Otherwise they'd break a lot more easily.)
  - AnthonyMouse 3y ago
    > That doesn't seem true, I can easily imagine an app that's based on Firefox but can still cause a WebKit page to open, you just need a system API that uses WebKit. It's still not using two different browser engines for the same purpose. This is no different than having two different apps that each use a different browser engine. The attacker needs the app to be using the exploitable browser engine in the context where they can deliver an attack payload, not in some other context. You can also improve this situation for system APIs by making the API open the page using the user's default browser instead of one hard-coded by the system or the app. > That's not how the app update lifecycle works, they're all independent. (Otherwise they'd break a lot more easily.) Breakage isn't common when systems implement this properly. When you get the new version of libssl from apt, all the packages that depend on it get updated and it's unusual for any of them to break.
  - hotnfresh 3y ago
    I’ve worked on Android apps that embed a browser engine but also use native web views. I doubt it’s rare. They’d exist on iOS too, if it were possible.
- planb 3y ago
  > If the Firefox browser engine was provided as an iOS library by Mozilla then Mozilla would update the library and every app that uses it would get the update at once. That problem is only caused by this not being supported. We don't want to go back to DLL hell, do we? History has shown that this approach does not scale, and definitely not on mobile.

by planb 3y ago

AnthonyMouse 3y ago

A given application is still not using more than one browser engine. If there is a vulnerability in Webkit and all apps have to use Webkit, all apps are vulnerable. If only a third of apps use Webkit, only a third of apps are vulnerable. A different third of apps might be vulnerable if there is a vulnerability in Blink. When the security record of each browser engine is comparable, this isn't a net increase in exposure, it just averages out to the same. When the others have a better record -- and Google and Mozilla have both introduced a number of novel security and privacy features -- then the net exposure goes down. Meanwhile having the choice is a security advantage because a) the user could choose the one with the best security record, whether or not it's Apple's and b) if there is an active vulnerability in Safari today then the user can use Chrome or Firefox today, and then do the reverse on the day there is an active vulnerability in Chrome. The main concern people seem to have with this is the one which is also caused by Apple -- apps might embed a browser engine and then if it's vulnerable you have to update lots of apps. But this is only because of their lacking support for independent libraries. If the Firefox browser engine was provided as an iOS library by Mozilla then Mozilla would update the library and every app that uses it would get the update at once. That problem is only caused by this not being supported. And is a problem that extends to more than browser engines. Apps can't use their own browser engines, but they might incorporate some common third party code that doesn't require JIT compilation, and then if someone finds a vulnerability in that code you still have to update a zillion apps. Specifically because the code isn't distributed as a dynamic library by its developers and instead gets copied into each app independently -- which not only impairs security but takes up more storage and memory to have multiple copies of the same code.

astrange 3y ago
> A given application is still not using more than one browser engine. That doesn't seem true, I can easily imagine an app that's based on Firefox but can still cause a WebKit page to open, you just need a system API that uses WebKit. > If the Firefox browser engine was provided as an iOS library by Mozilla then Mozilla would update the library and every app that uses it would get the update at once. That's not how the app update lifecycle works, they're all independent. (Otherwise they'd break a lot more easily.)
- AnthonyMouse 3y ago
  > That doesn't seem true, I can easily imagine an app that's based on Firefox but can still cause a WebKit page to open, you just need a system API that uses WebKit. It's still not using two different browser engines for the same purpose. This is no different than having two different apps that each use a different browser engine. The attacker needs the app to be using the exploitable browser engine in the context where they can deliver an attack payload, not in some other context. You can also improve this situation for system APIs by making the API open the page using the user's default browser instead of one hard-coded by the system or the app. > That's not how the app update lifecycle works, they're all independent. (Otherwise they'd break a lot more easily.) Breakage isn't common when systems implement this properly. When you get the new version of libssl from apt, all the packages that depend on it get updated and it's unusual for any of them to break.
- hotnfresh 3y ago
  I’ve worked on Android apps that embed a browser engine but also use native web views. I doubt it’s rare. They’d exist on iOS too, if it were possible.
planb 3y ago
> If the Firefox browser engine was provided as an iOS library by Mozilla then Mozilla would update the library and every app that uses it would get the update at once. That problem is only caused by this not being supported. We don't want to go back to DLL hell, do we? History has shown that this approach does not scale, and definitely not on mobile.