Android has a similar architecture with the 'keystore' service (for keys rather than files though). Crashing SystemUI will 'unlock' the phone, but none of the keys in the keystore will be usable. Unfortunately, no apps use the keystore in practice because it's unusably badly designed. You're vanishingly unlikely to notice if you're using a phone with a locked keystore.

That's the point: what you can access is not encrypted, but lots of stuff are on iOS9: photos, mail, etc. I'd say the difference in what you can access is staggering.

How can this be, if they are encrypted while the phone is locked?

Contacts need to be accessed to display a caller's name when the phone is ringing.

Since it's possible to take a photo with the phone locked, the whole photo database may be accessible.

The idea of having a security architecture with different classes of data still remains, so a third party app can quite easily leverage this, for instance. Unfortunately there doesn't seem to be a comprehensive list of protection classes that each app uses for its files.

Is there any reason this can't be fixed by just copying iOS in this regard ??? I guess the question I'm asking is, this bug is entirely fixable right ???

Not trying to diminish the seriousness of it. It sounds pretty horrible. Just saying that if Android's architecture will allow you to do something like iOS does, but it's simply unimplemented currently, that's one thing. It would be quite another thing if Android's architecture would NOT allow you to do something like iOS does. As I said... I'm not a security expert... but it SOUNDS like you can implement a fix that would mirror the protections provided in iOS ???

Is that true ???

Right now it seems the low hanging fruit for Android would be to encrypt devices _at all_ (by default). Different classes of encryption is a luxury.

iOS encrypts, even if you don't set a passphrase or something and their security white paper does mention having dedicated hardware to make it seamless.

Of course. The problem android has had in the past, though, is that actually getting security updates to users could be incredibly convoluted - with every vendor and network having their own, slightly tweaked (and heavily branded) versions of android.

We still haven't heard anything about it being re-enabled in Android M again (or ever). Also, I remember reading about Android <4.4 (optional) storage crypto being seriously broken as well.

It's unfortunate because many people probably still believe they are getting default storage encryption. Heck, all the new stories on encryption and the FBI still (falsely) mention how Android is encrypting the storage by default. It reminds of media sites saying Skype is P2P and secure against eavesdropping years after Microsoft announced it changed its infrastructure to a centralized wiretap-friendly model, just like everyone else.

The gap between iOS and Android in terms of security (and privacy, too) seems to only be increasing every year. If they keep this up I may finally switch to an iPhone after years of being an Android-only user.

https://medium.com/@FredericJacobs/apple-ios-9-security-priv...

And that's even without mentioning the horrible update problem that Android has. I've just learned to live with that by installing custom ROMs after my phone stops being supported a year into its life-cycle, which is obviously not ideal in terms of security nor is it something I should have to do to get better security.

Security is hard. Really profoundly hard, not just superficially hard.

And despite the fact that nominally I'd expect to get upvotes for stating what you'd think would be the groupthink consensus, my observation is that in the field, even engineers explicitly tasked with security still often think it's really easy and they're really good at it, so there's no great need for them to budget lots of time for it. This turns out poorly. I do not toss this around lightly because it's become cliche to just fling it around without much care, but there's a lot of real, no-foolin' Dunning-Kruger effect operative in this area.

(Your test for Dunning-Kruger on this matter is: If you're told you need to secure something and you're going to be personally responsible for its security, do you A: Say "Oh, that's easy, I'll 'just'..." followed by pretty much any series of words, or B: get the cold flop sweats, regardless of how easy it may superficially seem?)

Indeed. There is an army of naked celebrities dancing around the internet today because of an "iOS" hole that didn't even involve the device OS at all.

Picking on specific features to announce "Apple is more secure" is very much missing the point.

That said, yeah: I'm not a big fan of Android's security architecture either, though it has been improving rapidly.

This is an important factor, and maybe the fatal flaw in android's carrier relationships. Google is always very fast to push a fix out, but the carriers always drag their feet in getting the fix to the actual devices.

Having a better security architecture works (to stretch the metaphor) like immunization: past a certain adoption level you reach a "herd immunity" state where the marginal benefit to an attacker of a specific flaw drops rapidly to zero even though there are still "old" devices out there in the market in small numbers.

Basically, the market refresh cycle is still at something like 18 months, so even given that OEMs are slow new Android releases are reaching the public in large numbers fairly promptly.

It would be beneficial if carriers could come up with updates faster however. I've seen Verizon drag its feet on more than one occasion, especially with phones that are a generation or two behind.

Are you referring to the year-ago iCloud “hacks” or is there a really surprising twist to the whole XCode Ghost thing that I haven’t heard about? :)

Given the scale and complexity I would say Google's done an acceptable job at Android security, but I do think they need to be even more serious about it. And it's not like iOS (remember lock screen bugs) or Mac OS X (remember password less logins succeeding?) haven't had their fair share of issues.

Well... but Android is a year long (8 years since the first beta) effort backed by Google (55k employees) and companies like Samsung (490k employees). They might spare a few people coming up with a scheme for data encryption that works?

And really, I don't claim it's easy, and I don't claim that I personally could come up with something even halfway resembling Apple's solution. But Android seems, unfortunately, to not even be trying.

Android users seems to care more about benchmarks them security. The fact that Google removed the encryption by default was after all the bitching that people made after some releases showed that Nexus 6 was faster without encryption. However, there is no proof that this had any significant impact on performance, and I think Google put this restriction after a careful study that encryption by default, even on pure software implementation, did not impact usability on devices. OEMs do like benchmarks and likes to be lazy ("no encryption by default means I don't need to create a module implementing encryption that my hardware already supports! less money to spend, more profit!") because this makes people buy more phones, so they probably pressured Google to remove default encryption because encryption "makes performance looks worse" (on paper, not in real life).

If I was part of the midia, I would do a blind test running Nexus 6 with both encryption enabled and disabled. This would show if the performance impact was significant. But the majority of midia prefers the easier way using benchmarks, so we had all these Android users crying rivers that they lost performance. Serious, wtf.

I'm not sure if hardware acceleration is enabled in Nexus 6, but the hardware is certainly capable of acceleration. I now have an encrypted Nexus 6 and the performance is fine. My previous Nexus 4 was also encrypted and after encryption the performance hit was noticeable when booting up, but after boot it performs fine.

30 seconds to switch an app that's stale sounds like there's something really wrong either with your device or with the Cyanogenmod version you've got installed, judging by those specs at least.

Even without AES-NI, this processor is doing more than 100MB/s of encryption. Mobile storage is a lot worse than this (like less than 50MB/s in sustained sequential writes), and you have to remember this would be the worst case (since the majority of writes for common users is small files instead of big files).

Just to put in perspective: my Moto X can write around ~20MB/s when transferring files by USB 2.0. And it can still write the same ~20MB/s with encryption on.

Considering the industry Android is in is essentially only iOS and Android, that makes them the worst in the industry...

Or you only encrypt your phone and leaves your notebook unecrypted? This would be silly.

Android needs an 18-24 "gap" period of re-engineering everything they rushed, but at that point you might as well just write a new OS. I suspect there is a secret 2nd version of Android that isn't virtual machine based, doesn't use Java, but has whatever backwards compatibility needed to work with the existing applications. If things get too hot from Oracle, then that will be the next version of Android. Switching to ART seems to suggest that Google has some portability chops here. Incremental updates like they're doing now is the path of least resistance, but considering how much more polished iOS is, I really doubt Android will ever be on that level. Its always going to be a little quick and dirty and I think if you buy an Android product you have to accept that.

I switched to the Nexus products from my 3GS. I knew Android was a step down in a lot of ways, but I wanted the hardware flexibility it offered. Now that I can get a big Apple phone with a swype keyboard AND it works with Android smartwatches, it seems the Android value proposition keeps getting weaker and weaker.

Add to that forgetting a month in a calendar and an Alarm that rings for one second and stops

Almost justifies the extra price for the iPhone

What can you expect from a company that names its version releases after chocolates, candy and ice cream? That's literally the level of maturity with which they view their own product. So no wonder security is an afterthought.

For example, jwz's XScreenSaver separates the graphical process (more complex and bug-prone) from the daemon. If you manage to crash the password input screen (or the screensaver itself), the daemon will just restart it.

The password input screen uses only low-level X11 calls (and not a higher-level GUI toolkit) in an attempt to reduce the library dependency list and therefore the possibility of crasher bugs. But if you do indeed manage to find a crash bug in libX11 (or a dep) that you can trigger from xscreensaver's password entry box, that will indeed unlock the screen.

Now, the xscreensaver configuration panel is written using GTK, which is indeed a separate process, and a crash in the config panel won't affect the screen locker.

Still, Android doesn't run X, and since they control the whole OS, it shouldn't be too hard to avoid having input "pass through" the lock screen.

But I'm genuinely curious, maybe someone here on HN knows: Which of the other mobile phone systems (Windows Phone; Firefox OS; Ubuntu for Mobile; Tizen; Blackberry; ...) have a halfway decent security architecture, similar to iOS?

The whole point of Symbian OS S60 3rd Edition (aka Symbian OS 9.1) release was to introduce DRM support and a security model based on certificates for API sets.

Many, included myself, were disappointed that they didn't took the opportunity of such breaking change in the programming model, to throw the Symbian C++ dialect out of the window.

[+]: technically, it generates a new AES key, encrypts the message under it, encrypts that key under a key derived from ECDH over Curve25519 with the system public key (whose private key is encrypted and inaccessible while locked) and saves the encrypted file and the wrapped key somewhere to be decrypted when it gets unlocked and gets rid of the AES key.

This also only really works for software specifically designed for this mode.

EDIT: it can actually be mostly secure if the client public key is sent before locking and then the encryption is done by the server: the attacker would only learn the number and timing of new messages and their size (assuming an ad-hoc protocol and very carefully implemented software).

It's also sort of possible to do it with generic software by simply dumping HTTPS TCP traffic to disk and decoding it once the system is unlocked (although it allows a MITM to fill up your disk unless the ciphersuite allows authentication with a key that doesn't allow decryption).