To hack an Android phone, just type in a really long password

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.

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

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.

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.

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.

[+]: 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.

  All cars must be able to be driven in reverse by the driver at any time during the Event.

Security is not an absolute, and there is no such thing as "really/totally/completely secure". The different locking methods allow you to strike a balance between security and convenience that's appropriate for you. All of these are useless against a determined attacker, for a given level of 'determined'.

Amount of hardware is same as in any laptop. Is Android missing some driver framework or what?

So in this case "patched" is pretty meaningful.

When they activate paste, I guess copy is active to ... (but I don't own such a phone)