The container identity is derived from the certificate identity in Windows.

Now, you could say that's wrong and it should be derived from the public key instead. That's how Android does it. It means self-signing works. But, Microsoft want the ability to make malware bans stick, and that means tying apps to something expensive to forge yet cheap to produce one or two of, and which can be used to inflict real world consequences for online actions (malware). Real-world identity does that.

Public keys have another problem: people lose them. Google had to give up on letting developers manage their own keys eventually. The OS still understands that, but most apps are distributed through the Play Store and when you do that Google re-signs your software with server side controlled keys. This ties apps to Google accounts instead of private keys, which is much safer for the developer (in availability terms).

MSIX identity has a similar problem - sometimes companies change their names, and sometimes CAs disagree on how a name should be formatted. Windows has a mechanism to let people migrate between names, but it's badly designed and basically unusable. Conveyor provides its own system that's more robust.

> There are too many significant downsides to commercial code signing certificates for individuals, like cost, loss of anonymity, certificates getting revoked for bogus reasons like antivirus false positives, and the slow creep toward more things requiring EV (like maintaining reputation).

Microsoft will sign your software for you if you ship via the Microsoft Store, and charge you a one-off $19 fee. So that's basically ~free. Conveyor can make MSIX packages and upload them to the store for you, and can do so from Linux or macOS, so cost is no longer an obstacle to being signed (although you do have to meet the Store policies).

Certificates don't get revoked for AV false positives. Apple doesn't care what AV vendors think and on Windows certificates are actually never revoked, not even if used unambiguously to sign malware. They're working on changing that at the moment but it's slow going due to the need for precise policies; it will certainly not be so trigger-happy as to be caused by AV false positives.

You can't be anonymous in any software distribution platform meant for end users. Even on the web, you need to buy a domain name and that means tying your name to a payment system that is required by law to verify your government-issued identity. All apparent anonymity on the web is simply having other people stand in your place and agree to take the bullets on your behalf, which can be done with code signing as well.

The exceptions are platforms meant only for software developers (Homebrew, Docker Hub, NPM etc) which I think don't do any ID verification, but they are also centralized and expected to police the packages they ship by their users. Arguably they don't and this is blowing up in the industries face, usually this is called the supply chain crisis. It's possible that code signing will come for libraries at some point too if we don't figure out in-process sandboxing and make it ubiquitous.

> The majority of the time, the only actual trust I have in an application and its developer is from past history

That's exactly what code signing is for: allowing you to develop a trust in the reputation of a developer. But it has to be ignited by something. If you don't have that then you can never install any newly developed software, which is infeasible and so you probably do install software from developers with unknown reputation.

I think a better argument against the way code signing works is that it should accept a domain name as an identity, like the web does. The code PKI system assumes that trust accumulates into individuals or companies, but on the internet trust mostly accumulates through social networks and links, which go to domain names not companies.