[candiodari]

The problem with the argument from Apple is that they control code that can decrypt the information. That code can do whatever it wants, with or without your approval (they can change the code on the frontend without your approval). This "end-to-end encryption" are a commitment, a promise on their part, nothing more (and I might add, this is a bit of text on a PR page, it is not even a contractual obligation to you, a very important difference that I assure you is not an accidental oversight on the part of Apple's management. Not that a contractual obligation would protect your data from subpoenas).

So this still requires you trust Apple, and any organization that can compel Apple to take action, to not break your security. This, of course, includes any organization that can subpoena Apple, which due to international cooperation includes quite a few organizations.

The ONLY person that can be entrusted with information and be legally protected from subpoenas is you yourself, and your lawyer (and even then technically only when actually representing you, although I don't think that line has ever been crossed), and even that only applies within the US. I agree that Apple does seem to have had some success with this information, has not released such info -so far- in a public request (there are, however, a number of non-public channels for subpoenas).

If I were to ask you to enter your bank information on a website with javascript that encrypts the information, then sends it to the server under my control, end-to-end encrypted (the server does not know - independently of the frontend - the encryption keys. Of course the whole system still does know the information), would you trust that ? Of course not, as I control the frontend and the backend, and therefore I can still decrypt it. I can change the frontend code to send me the unencrypted information (or worse - the encryption key the backend does not know - as that would give me access now and access to any future updates), same trick as with LVM encryption.

Maybe I even need you to visit the site before I'd be able to decrypt it, but I hope you can see that I can still access the information if I control both, and when you decide to entrust information to that you should still decide if you trust me, and anyone who can subpoena information from me. The only difference is a few extra steps for me when I want to access the information.

So far Apple's argument is that it would be unreasonable ("onerous" I believe is the legal term) to demand they actually execute those steps. We don't know if that argument held up in the non-public channels (there does seem to be a compromise made [1])

People think that if you have LVM encryption on a disk it can't be copied without having access to the encryption key. That's wrong, of course I can copy it, I just can't read it unencrypted at that point. If I then install a boatloader that uses a side channel to send the encryption key to me (the 128 bytes of the key, not the actual data on the drive) and from that point on I have access to the information I copied earlier. Note that "protected boot" doesn't actually protect you either. I simply install a bootloader that looks exactly like the official bootloader on screen, you enter your password, it simulates an update or whatever, replaces itself with the official bootloader again, and reboots. Presto, I now have access to all your drives and you're none the wiser, and the only thing I needed was physical access to the information (in other words, only the exact same thing I would need if it wasn't encrypted at all).

[1] https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_d...

[grzm]

There's a number of straw men here: I understand the difference between being able to copy and decrypt data. You're the one who brought that up. The FBI case is about unlocking a device (which make the keys available), not decrypting data at rest when you don't have access to the keys. You brought up specifically accessing contact data available to specific apps, and those were the points I addressed.

So, only software you compile yourself, and never storing data on servers you don't own? How about hardware, including chips, from third-parties? Trusting encryption algorithms others have certified? How far does your trust extend? Is it reasonable for others to have different levels of trust than you?

[candiodari]

Nope. You do not require that you only use software you compile yourself. Software that only uses local storage, for obvious reasons, does not need that.

That's why I'm saying that you only need to be watch out for cloud software. Local contact storage is of course fine.

It's just that neither android nor Apple/ios has that.

[grzm]

I don't know what the options are on Android, but you aren't required to use iCloud on iOS for Contacts (or at all, for that matter, though there are likely feature limitations such as some syncing between devices if you don't have it enabled).

[candiodari]

I'm not sure why it is so terribly important for you to defend Apple here, but let's just say that I'm pretty sure I would just avoid using a smartphone all together for anything important.

Contacts has code in it that is explicitly designed to expose this info (to provide features found useful by many Apple customers of course). And we know that the safety guarantees are somewhat noncommittal (and I would argue at least a bit misleading).

And that's enough, if you want to avoid giving out this info, I'd use other tools to communicate.

[grzm]

> "I'm not sure why it is so terribly important for you to defend Apple here"

Only that it appears you're misrepresenting the situation. I would ask the same of you as to why it's important to continue to rail against Apple and Google to make incorrect claims and build straw men when those claims are pointed out. Here, you again shift your position. Initially you talk about cloud storage for contacts, and it's not an option to not use the cloud for storage. When I point out that that's wrong (at least for Apple), you retreat and now only talk about contacts in general. If I'm wrong about anything I've said, please point it out. If I knew more about Google and Android, I'd fill in those details, too, but I don't.

> "let's just say that I'm pretty sure I would just avoid using a smartphone all together for anything important."

If your point is you don't think using a smartphone for anything important, that's fine, and I completely agree that, depending on your threat model, smart phones may not be a good option. But you don't need to make false, misleading, (or perhaps just uninformed) claims about specific features. That just undermines your point. If you're coming at this from an op-sec perspective, that requires a particularly calm and dry-eyed look at the situation, as any misrepresentation likely has severe consequences.