How this term is used Open attested runtimes appear in the interview with Alex Komoroske as part of his proposed alternative to assuming privacy requires local-first software. He argues local-first is architecturally hard (peer consistency, sync) and inconvenient (devices go offline), so the better path is confidential compute in the cloud — secure enclaves with fully encrypted memory — combined with open attested runtimes [^bb2c42aa-478f-5c9a-ac26-e83a54c63127@851]. What they enable With an attested runtime, a user can remotely verify, via hardware-signed attestation, that they are talking to an unmodified, private system — one running exactly the code it claims to run, with no one snooping or tampering [^bb2c42aa-478f-5c9a-ac26-e83a54c63127@1945]. Komoroske stresses the open part matters: the verification becomes a coordination primitive, because many people can all check that the server does only what it says. In his broader argument, open attested runtimes are one of the tools — alongside contextual flow control and confidential computing — for breaking the iron triangle (a safe system can have only two of untrusted code, sensitive data, and network access) and escaping the aggregation caused by the same-origin paradigm. - Open attested runtimes pair confidential compute in the cloud (secure enclaves, fully encrypted memory) with hardware-signed attestation. - They let users remotely verify they are talking to an unmodified, private system — without needing local-first software. - Because anyone can perform the verification, they act as a coordination primitive: many people can confirm the server does only what it says. - In the interview they are one of the architectural tools for breaking the iron triangle and countering data aggregation.