I think the actual implications wouldn't be too different in production. Those are the main scenarios where Binary Transparency might be of use: 1. An applic

I think the actual implications wouldn't be too different in production. Those are the main scenarios where Binary Transparency might be of use: 1. An application developer's private key gets compromised (either through a breach or an inside job). Binary Transparency would allow the developer to monitor the log server for any unauthorized binaries and, once detected, investigate the source of the attack, rotate keys and possibly blacklist the affected binary (not sure if a mechanism like that exists at the moment, but it would make sense with Binary Transparency). 2. The application developer is coerced into signing a binary including a backdoor. Binary Transparency would guarantee that there's a public record of a modified binary being released. This alone would probably make any adversary think twice about doing this, especially if they want to stay unnoticed. In addition to that, gossip protocols and dedicated auditors could allow users to detect odd releases even if the developers were gagged. This might very well result in the app being effectively revoked because users stop trusting it. Both scenarios would at the very least allow the backdoor to be reverse-engineered. Ultimately, I'm afraid you're probably right and the limitations and complexity of this approach probably won't make it viable for a long time. Maybe the thinking will change if we see some high-profile cases where apps are backdoored - that's what got the ball rolling for Certificate Transparency, after all.