Why not generate the key on the device and store it in a secure piece of hardware? That's been a pretty standard solution for a while now. I kind of imagined Android would also do the same.

iOS has encrypted most of its data most of the time already and iOS has not had significantly worse battery life than Android in the past. What's the crux here is not the addition of encryption, it's the location of the encryption key.

Already the industry is realizing what it needs to do.

First, no one said anything about being angry. Second, no one said anything about "Hollywood" always getting history wrong in favor of the Americans. Third, gnasher719 and I are two different people.

What gnasher719 said about American movies rewriting history is true. My point was propagandists have used fiction to sway the masses and it appears to have worked: gnasher719 was responding to a common misconception that Americans broke German codes in WWII. A misconception perpetuated by Hollywood.

I have no gripe with Hollywood, but I do support people like gnasher719 who go out of their way to correct misconceptions others have because a Hollywood movie twisted history. You pointing out that it was not a documentary doesn't make the misconception any worse nor gnasher719's attempt to correct that misconception useless.

No one is saying fiction can't bend the truth, if that's what you thought.

Documentary or not, his point that American movies have re-written history was true. Would you feel the same way about a Russian fictional movie that portrayed the moon landing as being a Soviet accomplishment?

You're right! We should do nothing now! Why would we want to change something we don't like. Oh, that's right, it's too late.

What a defeatist attitude.

Only if it is the only government in the world. Plenty of people move to live under a different government due to being unhappy with their current one.

Yes, but it's between your MUA and your server. S/MIME, as far as I know, does not do server-to-sender public key exchange. If I send a signed message to you, then you have my public key and can encrypt messages to me, yes, but you can't get my public key from the server.

Frankly, S/MIME is really the best solution available today. It works with gmail (not web-mail but using a MUA). Most MUAs support it. It's easy to get a free personal S/MIME keypair from a CA. Google, Apple or whoever you use for mail never sees your private key and can't read your messages.

The subject of the photograph does not have zero thickness. The camera focal point could be along the plane of the front of the subject, which would make it *not* along the plane of the rear of the phone.

Imagine I am standing long the plane of the front of a building, am I also standing along the plan of the rear of a building? Am I looking at the building at a flat 90 (whatever that means)?

Even better would be a system such as:

You generate a key pair, give Apple the public key. You manage your own private key.

Then, for each email:

Apple receives the email as plain text from another server (likely via SSL), encrypts it with your public key and stores it on their servers. When you connect to retrieve your mail they send you the encrypted blob that you decrypt via your private key.

Problems are this: first, Apple has a plain text copy of each email you receive and could be asked (nicely or forcefully) to record this somewhere before proceeding with encryption and storage. Second, replies are not encrypted.

Much better for users to manage their own keys and use S/MIME. That's what I do with my friends and Google (my email provider) never sees unencrypted messages from me to any of my friends and vice versa.

Which makes sense as most email clients out in the wild don't encrypt messages, so even if Apple were to encrypt messages stored on the server, they'd be doing it with *their* key, not the users (unless the user used S/MIME or PGP or GPG or what have you). If they want to interoperate with other email providers, they need access to the emails as that's how email works.

iMessage and FaceTime are technologies Apple designed and implemented, and they chose to do it in a different way than e-mail. E-mail uses a plain text protocol and is stored in plain text. While the transport can be encrypted, if one were to encrypt the data on the server it was stored on, one would use a symmetric key, and one would have access to that key. iMessage and FaceTime can be implemented using asymmetric keys and one would not need access to those keys. It makes sense if you as a company want to minimize how much data you hand over to a government: you let devices generate keys that your servers never see.

It would all depend on the unit of time. If I got 4Mb per pico second I'd be one happy fish.

I mean runs sufficiently to play Minecraft. It does so on many distributions of Linux out-of-the-box. That's more than just Windows and OS X. Java runs to other degrees on other platforms as well, but for the topic at hand (Minecraft's future), Linux distributions are what I'm referring to here.

A company without competitors need not be competitive.