Comment by LoganDark
13 days ago
To trust an Android device, I need to have ultimate authority over it. That means freedom to remove functionality I don't like and make changes apps don't like. Otherwise, there are parts of practically every Android that I don't approve of, like the carrier app installer, any tracking/telemetry, most preinstalled apps, etc.
I recently moved to Apple devices because they use trusted computing differently; namely, to protect against platform abuse, but mostly not to protect corporate interests. They also publish detailed first-party documentation on how their platforms work and how certain features are implemented.
Apple jailbreaking has historically also had a better UX than Android rooting, because Apple platforms are more trusted than Android platforms, meaning that DRM protection, banking apps and such will often still work with a jailbroken iOS device, unlike most rooted Android devices. With that said though, I don't particularly expect to ever have a jailbroken iOS device again, unfortunately.
Apple implements many more protections than Android at the OS level to prevent abuse of trusted computing by third-party apps, and give the user control. (Though some Androids like, say, GrapheneOS, implement lots that Apple does not.)
But of course all this only matters if you trust Apple. I trust them less than I did, but to me they are still the most trustworthy.
>to protect against platform abuse, but mostly not to protect corporate interests
What do you mean by this? On both Android and iOS app developers can have a backend that checks the status of app attestation.
"App attestation" means different things for Android than for iOS. On iOS, it verifies the app was installed from the right place. On Android, it tries to check if the device is tampered with, or hasn't been fully certified by Google, or etc... Android's far more finicky because Google uses this process to crack down on OEMs and hobbyists, while Apple implicitly trusts itself.
Also, "checking the status of app attestation" is the wrong approach. If you want to use app attestation that way, then you should sign/encrypt communications (requests and responses) with hardware-backed keys; that way, you can't replay or proxy an attestation result to authorize modified requests.
(I believe Apple attestation doesn't directly support encryption itself, only signing, but that is enough to use it as part of a key exchange process with hardware-backed keys - you can sign a public key you're sending to the server, which can verify your signature and then use your public key to encrypt a server-side public key, that then you can decrypt and use to encrypt your future communications to the server, and the server can encrypt its responses with your public key, etc.)