[tbiehn]

This is exactly my point - the available controls are not sufficient (plus immature). Providing a control that lets you create trusted client code lets you (comprehensively) cover the risk of code introduced 'after build time'. This would be obviously difficult to deploy - but it isn't without precedent, most clients (that aren't web) are already protected by signatures at build time, and orgs where that really matters (Signal, GPG, etc) get to pursue signing on air-gapped computers, with ceremonies and deterministic build processes. Preventing the implanting of client code has been deemed so important that even when updates go out over TLS, their signatures are double-checked by the recipient. I do not see how our use of the web-browser as a client becomes more trivial over time, it is clear that eventually the exposed capabilities, and desired use-cases, will eventually mandate assemblies verifiable in this manner.