> There are obvious security advantages to app signing. But there are also negative implications for privacy and availability.
App signing exists elsewhere without sacrificing privacy. Most Linux packages, for example, are signed with GPG keys. The difference is that Linux only cares about installing trusted packages. It doesn't care about applications that are already installed after verification. Apple insists on having the ability to revoke something that's already installed. There are two issues here:
1. Is it reasonable to revoke permissions for an installed package? It could be argued that it will help stop malicious apps that were discovered after they were distributed. However, it could equally as well be that Apple wants more control over devices and hold developers to ransom. Their recent treatment of developers indicate that this concern is not at all misplaced. The least Apple could do is warn the user about a revoked certificate and ask if they still want to proceed (like how browsers do in the same scenario). However, it just refuses outright.
2. Apple chose a very bad method to implement online certificate revocation. OCSP is meant for server certificate validation. OCSP stapling is preferred over plain OCSP due to privacy concerns. Stapling cannot be used in this context. This method unfortunately ruins privacy and spill user information everywhere. They could have chosen some other more private method, like an updatable CRL.
> I’m pretty sure those who relentlessly focus on the possible downsides don’t know either.
As I said, there are more private ways to push revocation status. Apple always claimed that the device lockdown was to ensure privacy. This oversight shows how hollow that claim is.
Important part to notice is the false dichotomy of freedom vs security. The argument that negligent users will screw up if given freedom. This is wrong for two reasons:
1. Defaults vs restrictions: Keep the defaults secure and slightly hard to modify for normal users. But don't restrict those who need alternatives.
2. Security can be achieved without locking everything down and remote controlling it. See web browsers for example. We run JS from all insecure sources, but cannot access sensitive resources (like camera, file access etc) without users' permission. The same can be achieved on OS with sandboxing, microkernels etc.
> no one is held hostage or abused in this scenario
Abuse is not always apparent to the abused. User rights are gradually eroded away in the name of security, giving users enough time to get accustomed to it. There may be escape hatches now, but they are slowly getting closed. For example, we considered PCs that don't allow us to install another OS as abusive. However, we don't hold mobile devices to the same standard. Unfortunately, this normalization of abuse doesn't just affect those who accept it. The rest of us are left without a choice. That criticism is definitely valid.