Hacker News Reader

Comment by Flockster | Hacker News Reader

> However, iOS has a different situation. Due to Apple's App Store and sandboxing policies, other browser apps are forced to use Safari's JavaScript engine. That is, Chrome, Firefox and Edge on iOS are simply wrappers on top of Safari that provide auxiliary features such as synchronizing bookmarks and settings. Consequently, nearly every browser application listed on the App Store is vulnerable to iLeakage.

This should be a reason to lift this policy and allow different engines on these devices!

View on HN

Because increasing the attack surface would somehow increase the security?

You have a laptop with a browser. You buy a laptop with a more secure browser. You have increased attack surface yet security is improved.

It is quite possible a native Chrome on iOS would be more secure.

Absolutely not. You now have a computer where you have chromium’s flaws for your daily internet browsing and Safari(or whatever native browser is on the OS)’s flaws for the native apps that use the native browser.

Yes indeed, you’re still free not to use these apps. But would you? At some point why not get a computer where the internet is the “OS” (a chromebook for instance……… where guess what? you cannot use an alternate rendering engine. Interesting, no?)

Technically you can run an alternative browser on ChromeOS under the form of an Android app, or by running a different one in the Linux sandbox.

In exchange for decreasing the amount of affected users and application? Absolutely. No one would be forced to use a non-Safari browser.

A software monoculture means that a bug for one is a bug for all.

But you’d also get apps that decide to use chromium for whatever reason outside of the user’s control, thus making these users vulnerable to chromium flaws…

In short, you increase the possibilities, you increase the attack vectors. There is no way around it AFAIK.

>outside of the user’s control

Using the app at all is in the user's control. The current state of iOS is that they don't have any control whatsoever.

Here’s an example: I know I have the control of not using youtube because I really dislike gougle. Would any of my family member? Absolutely not. Would they use their browser if they could in the youtube app? Most definitely yes.

So no, it is most definitely not in the user’s control.

> Would they use their browser if they could in the youtube app? Most definitely yes.

> So no, it is most definitely not in the user’s control.

You're comparing impulse control to hard runtime limitations. It doesn't really track; I understand your apprehension, but if none of your family members notice or care then maybe Google's hypothetical solution here worked? If that's an undesirable outcome for you, I think you should be lobbying for better alternatives instead of using it as a boogeyman to excuse iron-grip ecosystems. Two wrongs aren't going to make a right here.

> Using the app at all is in the user's control.

Not if it is mandated by work, home, family, government, etc.

If it's mandated then they never had the control there to begin with.

> A software monoculture means that a bug for one is a bug for all.

That's true, but the situation is not improved by a Chromium/Blink monoculture. It's the same problem with a slightly different flavor.

So yes, iOS should be opened to third party engines, but at the same time steps should be taken to stymy Chromium's dominance.

Brave on iOS can disable Javascript on all web pages except those you trust by opt-in.

They should allow different engines, but this isn't a reason. Different browsers have different vulnerabilities, but aren't substantially more secure as far as I'm aware.

But it's for your security! Not joking: https://news.ycombinator.com/item?id=21587191

unironically, having three browser engines is three times the attack surface, what's the problem with that claim?

uarch "multiculture" hasn't saved us from architectural attacks, actually it probably increases the total number of vulnerabilities, and browser multiculture won't magically make them all perfectly secure and perfectly implemented either. if each browser is only 99% secure now you have 0.99^3 total security, you have ~tripled your odds of a vulnerability existing in at least one of your apps at a given time.

there are other arguments in favor of sideloading, but, I don't really see how multiple browsers is a security improvement, actually it seems unironically much worse on that front, since now you are depending on three teams of engineers (two of which are not even at your company) to execute perfectly and never have a vulnerability, in what is one of the highest-privilege applications (essentially the canonical "full control" app). People want their browser to have access to location info (thus bluetooth/wifi settings), camera, camera roll (thus long-term location history), microphone, everything. The fewer applications that exist like that the better you are.

I can't fathom anyone saying that they should, for example, run three different high-privilege pieces of software in their production systems, when one would do fine - f.ex you wouldn't run nginx, apache, and keycloak all mixed into your environments. That would obviously inflate the risk of being subject to at least one attack. Why is the browser different?

Because you are not running all of them at the same time, you are only running one of them. The one you choose to run can be better than the current one you are forced to use and thus your attack surface has decreased because you are not using the worse ones.

Having options does not reduce your security except in-so-far as exposing the underlying mechanism allowing choice increases your attack surface, and even then that does not inherently reduce your security. A mechanism allowing multiple implementations requiring more available attack surface, but which is used by a high quality application to provide a highly secure implementation is still better than a reduced mechanism designed to only allow a single application when that application provides a low quality implementation.

Also, the argument you just proposed could just as easily be used to argue that we should disallow any other operating system other than Windows 3.1 since having more operating systems just increases the attack surface. That is patently absurd for the reasons I just stated above and is why your argument is fatally flawed.

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

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.

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

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

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.

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

The ancient Windows implementation of this was flawed because it doesn't use versioning. Newer systems do it sensibly: If two versions of a library are incompatible with each other then they can be installed in parallel.

Meanwhile you still don't need a thousand versions installed because the library only has to declare a version compatibility change if some part of the API is removed. Otherwise a newer version of the library will implement everything an older version does and only make additions or bug fixes.

Then you have some app which needs library version 2.3.4 or higher, some other app needs the same library with version 2.3.5 or higher, so the system sees those dependencies and installs version 2.3.9 which is backwards compatible and can be used by both of those apps. An old app needs version 1.2.0 or higher, which isn't compatible with 2.3.9, so the system installs version 1.2.15, which is. Then you have two versions of the library installed alongside each other instead of the three versions you have now -- and the two versions you have installed are both still maintained, instead of having apps that quietly statically include versions 1.2.0 and 2.3.4 which each have a big fat CVE, and 2.3.5 which patched the security vulnerability but still has a couple of inconvenient bugs you don't need.

This is all done by a package manager which uses the list of dependencies for each app to take care of it for you when you install an app. This has been a solved problem for decades. But mobile fails to implement the known solution and instead sticks you with inefficient manual updating of every individual app.

> The one you choose to run can be better than the current one you are forced to use and thus your attack surface has decreased because you are not using the worse ones.

you seem to think that webkit is the worse one here and that having for example a blink based or gecko based browser would means that these kind of bugs don’t happen.

that is unfortunately just wishful thinking. just read through the release notes of Chrome and Firefox and you will see that they all fix security bugs for every release.

all browser engines are of extremely high quality. but they also all keep having regular and security bugs.

Maybe three times the browser engine, three times the chance to have a safe engine at the end?

As far as I understand, The attack surface will be reduced in the end. Here is why: The amount of processed content is the same, no matter if you use one browser engine on single device or many. So if we assume that browser is 99%, the chance to _not_ hit the vulnerable page is 99%. However, by segregation of browser data between engines, the exposure of confidential information is reduced in case of breach

> unironically, having three browser engines is three times the attack surface, what's the problem with that claim?

If only one third of the users run a vulnerable browser, the other 2/3 would be safe. Security through compartmentalization.

What next? iOS security vulnerability? This should be a reason to lift this policy and allow different operating systems on these devices! /s

If Europe's governments weren't so reliant on Apple's surveillance, maybe their regulators would demand that.

Lol what? You can't just drop a bomb `Europe relying on Apple's surveillance` without any details

https://en.wikipedia.org/wiki/Five_Eyes

> In early 2014, the European Parliament's Committee on Civil Liberties, Justice and Home Affairs released a draft report which confirmed that the intelligence agencies of New Zealand and Canada have cooperated with the NSA under the Five Eyes programme and may have been actively sharing the personal data of EU citizens. The EU report did not investigate if any international or domestic US laws were broken by the US and did not claim that any FVEY nation was illegally conducting intelligence collection on the EU.

For reference, this is the same NSA that has boasted about having inroads at companies like Google, Microsoft and Apple. The same FIVE EYES that recently "somehow" found the damning evidence to accuse India of conspiring to kill a foreign dissident.

Europe relies on America's surveillance network, and America's surveillance network relies on ___________.

Europe's surveillance network. They're all sharing information with each other.

Reply on news.ycombinator.com