You just said you have reproducible builds. Either you are going to audit the code and do the build yourself or you are still trusting a third party.

I think you can agree that being able to see the code, and detect patched builds, makes it much more risky to pull something like this.

What percentage of people have the requisite knowledge to do that? The Heartbleed bug was in open source software for over a year before anyone noticed it.

This could be avoided by only running programs written in safer languages. C/++ allows for very very hard to spot bugs that can cause serious issues like heartbleed. You would have to try a lot harder to hide such a thing in a haskell program .

Since all five widely implemented platforms (iOS, Android, MacOS, Windows, and Linux) and most mainstream open source software is written in C, that would be a tough lift. Also since there are far more people who know C than Haskell, that kind of gets rid of the “many eyes” defense.

There may be fewer people able to read haskell but I would say fewer are needed to verify that a program doesn't have unexpected behavior. Also languages like rust are becoming bigger which should help.

Sure there is a lot of C floating around but there is a solution in sight and there is some amount of effort being put in to rewriting things in Rust.

No, I'm trusting the ecosystem of people and companies who are able to audit the code.

Again, you have not disputed that Apple is worse.

You don’t have to trust the ad blockers. The operating system won’t let ad blockers have access to your browser history. If you want to see how the ad blocking framework on iOS, you are free to go over to WebKit.org.

You really think people are auditing all of the open source software you are using? Where were they the year and a half the HeartBleed bug was out in the wild?

Nobody is claiming it stops all vulnerabilities, so let's get that straw man out of the way.

I'm saying it's significantly better than the alternative, and you continue to ignore that point. For example, reproducible builds directly stops XCodeGhost from ever happening, which was the single largest mobile malware infection in history by a wide margin. As another example, heartbleed has nothing on this 15 year old MacOS bug. https://www.macworld.com/article/3250125/macs/full-macos-com...

So a vulnerability that affects a phone with 12% market share if you downloaded an infected app is larger than a bug that affected all Android phones and all you needed was a phone number?

https://en.wikipedia.org/wiki/Stagefright_(bug)

And since Android phones both have a horrible security model and a horrible history of receiving updates, any malware or security issue is made worse.

There have been no Stagefright malware infections ever reported. Compare to nearly half a billion XCodeGhost infections, which reproducible builds stop cold. When it comes to results, the Android security model is peachy compared to iOS's. https://www.theregister.co.uk/2017/02/15/google_stagefright_...

Even though 95% and 99% of phones were vulnerable and many never got patched, there was really no problem because few were affected?

I live in a neighborhood that has never had a reported break in. Does that mean I’m not more vulnerable if I leave my door unlocked and post a huge sign outside letting everyone know?

There are many layers of security in modern OSes. Apple ignores many of them to the peril of their customers, and it shows in the results. In your example, many Android devices left the door unlocked but had a security guard. Apple locked the door but the lock on the door allowed many other keys to work.

What security guard? There was no security that kept Android from being vulnerable. It would have been just as easy for someone to infect the Android build chain.

Even if you look at something like the way that third party keyboards work on Android, it’s a security nightmare.

On iOS, users have to explicitly go into settings to add a third party keyboard and even then it doesn’t have network access by default. The user has to go back into settings to enable the keyboard to have network access and then they get a big scary warning. Android users happily install keyloggers.

Also, even after you both install the keyboard and give the keyboard network access, iOS still switches back to the default keyboard when entering passwords.

> What security guard? There was no security that kept Android from being vulnerable.

Blocking exploits in the Play Store, among other things. Why do you think Stagefright was never exploited?

> It would have been just as easy for someone to infect the Android build chain.

We were just talking about reproducible builds.

> Keyboard nonsense.

Android also displays a scary warning for keyboards.

Stage fright didn’t involve having an app in the Play store. The review process is non existent, and static analysis tools wouldn’t catch it anyway.

> Stage fright didn’t involve having an app in the Play store.

If the MMS app and the browsers were updated to filter Stagefright exploits (on Android, unlike iOS, system app updates do not require an OS update and happen through the Play Store, one of many things Android gets right and iOS gets wrong), the only way to exploit it is by publishing your own app to the Play Store and getting somebody to install it and hoping that the device doesn't have an selinux policy that limits the privileges of the exploit. The Play Store can trivially block apps that don't use an approved wrapper library for media that filters Stagefright exploits.

Back then the built in Web view that apps embedded was built into the OS as was the browser. You remember that Chrome wasn’t the browser for apps back then.

Also, what’s the differences between updating the OS from Apple’s servers and hypothetically updating an app from Apple’s servers. Are you trying to turn a weakness that Google can’t just press a button and allow every single Android worldwide to receive an OS update into a strength?