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...