[pjmlp]

iOS and Windows Phone architecture are already much better than Android in this regard.

Also Symbian had a relatively good security architecture, with its micro-kernel and the permissions model introduced in S60 v3.

Android security lags behind, because Google doesn't want to force OEMs and providers to provide updates. Additionally the OS architecture makes it pretty easy to extract an APK and reverse engineer it, even if written with the NDK.

But in any case, the best exploits are social and there isn't any help there.

Most of the users get p0wned trying to find stuff for free in dubious sites, and installing it, instead of paying for the real deal.

[fpgeek]

> Android security lags behind, because Google doesn't want to force OEMs and providers to provide updates.

What do OEM updates have to do with a security hole in Chrome? Despite all the merger chatter, Chrome isn't an OS-level part Android the way it is with ChromeOS.

The exploit sounds serious, but once the Chrome team understands it and comes up with a fix, all Google needs to do to deploy it is publish a new version of Chrome on the Play Store. I suppose they could add a nudge or two via Play Services (or otherwise) if people aren't installing the new version, but, in any case, that's nowhere near the effort required to get an OS update out (and neither OEMs nor carriers can block the fix).

[pjmlp]

First of all, I was replying to " I wonder if the next generation of phone operating systems will have something more akin to a true exo or micro kernel to help mitigate these sorts of attacks."

Second, most mobile users use whatever app is labeled as "Internet" on their phones and tablets. Only savy users get to install Chrome.

Third, anyone using an Android system older than Lollipop won't get WebView updates.

So on those devices a Chrome update is indeed an OS update.

[brazzledazzle]

>Google doesn't want to force OEMs and providers to provide updates

I think you're assuming a lot about the relationship's power dynamics and what contracts are at play that may have been written quite a while ago. Also forgetting that more often than not it's the telco that's blocking or bottlenecking updates. The reason Apple was able to do what it did is because they provided the software and hardware and were able to leverage the demand for it against the likes of Verizon (probably the most notorious blocker of updates no matter how critical they might be).

[pjmlp]

I used to work for a famous Finn company with seat in Espoo.

[brazzledazzle]

Wink, wink. I suppose that's about my first point though. What about the second?

[pjmlp]

They just needed to change the license how licensees are allowed to use Android.

If OEMs or Telcos would loose the legal right to ship phones with Android if the updates weren't provided within a specific SLA, then they surely would comply.

As an example how to put telcos in line, in the early days that mobiles started shipping with wlan support, Vodafone tried to sell N95 with wlan and VoIP support disabled on their firmware. Eventually they had to provide a full working N95, if I remember correctly.

I doubt that nowadays they would go back to develop their own OSes.

[ocean3]

How does reverse engineer affect security?

[pjmlp]

Allows to expose security flaws in existing code?

[ocean3]

But you can exploit even if you don't know the source right? Harder i suppose.