Android is moving away from C and towards more secure languages. From one of their recent blog posts, the majority of code written for android is now in memory safe languages.

Apple also has memory-safer languages it is moving to:

Swift: A memory-safer systems programming language: https://www.swift.org

Firebloom: A memory-safer C variant: https://support.apple.com/en-il/guide/security/sec30d8d9ec1/...

Not sure what the answer is for existing memory-unsafe code.

> Not sure what the answer is for existing memory-unsafe code.

It's an engineering approach that involves writing "A buffer overflow issue was addressed with improved memory handling" an awful lot. Hopefully one day they will finish improving the memory handling!

Is the programming language likely the issue here?

Well, theoretically all can be secure (in regards to buffer overflows etc). Some just forbid to shoot you in the arm. And head.

Of course, it's not necessary to use a language where "Give control of your phone to remote attackers" is one of the possibilities at all.

General purpose languages, whether that's something like C or Rust or even Javascript are not the appropriate tool. Turing Completeness is a bad idea from a security point of view, not a wonderful feature.

Yes, almost all of these major exploits are memory safety related and would be mostly impossible in a memory safe language.

That's like asking whether it is the lack of a seatbelt that was the issue after sometime died in a car crash.

Well, of course the real issue was the car crash. But wearing a seatbelt would have sure helped!

And for this problem specifically Android can use WUFFS. WUFFS is a special purpose language for Wrangling Untrusted File Formats Safetly. Trading away generality (the ability to write a program which say, sends email) gets them complete safety and excellent performance.

In Rust we can't trivially write a bounds miss by mistake. But in WUFFS we just can't write a bounds miss at all. Like, that's not a thing in WUFFS, it doesn't compile. You can write your own bounds checks and show WUFFS that works, or you can write code which clearly can't have a bounds miss with no checks, that works too. But you can't just "forget" or "screw up" those won't compile.

This would be frustrating in a general purpose language. WUFFS doesn't have a "Hello, World" program because it lacks both strings and the idea of outputing to the screen. But WUFFS isn't a general purpose language, however it's the correct way to write the code that takes image files we got from some dubious source and processes them.

When Apple announced they wanted to provide proper security for vulnerable iPhone users, this is what that would look like coming from a company which actually cared about security. What you got is what it looks like from a company which prioritised marketing.

Would any of your comment change if I told you the bug was in a Google image parser that they currently also ship to production?

Google at large is slowly banning use of non memory safe languages. Android in particular is doing well at adopting Rust.

Interesting how your response makes it seem like the person you're responding to mentioned android at all.

I think it’s safe to assume that most people know that’s the only other common choice.

>Please... Androids no better.

The Pixel is.

>At least Apple will have it patched within the year of discovery. Can't say the same for other Android vendors.

And the Pixel would have the patch released quicker.

The pixel is decent if using graphene is. Not sure if any system is good by default. Apple fans think their defaults are somehow more private or secure, mostly due to marketing.

Decent? From a security perspective it's superior to the iPhone. As for Graphene, unless you've personally vetted the code I don't see how it can be trusted. And I won't even go into the drama that OS comes with.

> unless you've personally vetted the code I don't see how it can be trusted.

As opposed to proprietary Google code that cannot be vetted?

What about the proprietary binary blobs that Graphene is reliant on? Who vetted those?

I think that we both can agree that less = better, so I don't see your point.

Pixel is not an OS, is not Android. Pixel is a series of hardware that make up less than five percent of the android hardware market.

One device series does not offer a glimpse of the market.

Op’s point stands.

>Pixel is not an OS

Then what do you call the custom OS that ships on the Pixel? Of course it's a custom built OS that's designed to work with the custom hardware on the Pixel.

>One device series does not offer a glimpse of the market.

Security is defined by the marriage of software and hardware. The reason the Pixel is so secure is because of this. The OP made a blanket statement which did not apply to the Android ecosystem.

On Android you can disable automatic link preview and downloading of MMS messages. You can also swap out the application that handles text messages entirely.

This eliminates this whole class of attack.

Also the application that handles text message is itself sandboxed and limited to a fixed set of permissions (to be fair, that include messaging other humans, so an exploit would still be very bad, just not "remote root" bad).

That's the part that is still unclear with this BLASTPASS business. Surely iOS isn't running the messaging app as a device root, right? There's some other presumably-unpatched privilege elevation attack going on?

Yes. The ImageIO vulnerability just allows for an initial foothold.

I have friends with Android phones that are running 5-year-old operating systems.

I have one friend that absolutely refuses to update his 7-year-old Samsung.

I got the fix on my phones (including my 8), iPads and Watch, today.

> Androids no better.

That does not make the situation right for Apple.

You can just avoid crappy Android vendors. 1 year is low bar.