The origin binding you're describing is real, but there's a gap in the threat model around DOM injection.
When an extension has host permissions for your site, it can run content scripts. You're right that content scripts run in an "isolated world" and can't directly access the page's JavaScript context or OPFS.
But content scripts can manipulate the DOM. And that's the problem.
That injected <script> tag doesn't run in the extension's context. It runs in your page's context. The browser executes it as if NostrVault.tld served it. There's no origin check that fails because from the browser's perspective, it is code running on NostrVault.tld.
The origin boundary isn't being crossed—it's being entered.
Your encryption approach with the NFC card is the right mitigation for this. If the OPFS contents are encrypted and the key never touches JavaScript (stays on the card), then the injected script gets ciphertext it can't use. Just be careful about the window when decrypted data exists in memory—that's still accessible to injected code.
When an extension has host permissions for your site, it can run content scripts. You're right that content scripts run in an "isolated world" and can't directly access the page's JavaScript context or OPFS.
But content scripts can manipulate the DOM. And that's the problem.
That injected <script> tag doesn't run in the extension's context. It runs in your page's context. The browser executes it as if NostrVault.tld served it. There's no origin check that fails because from the browser's perspective, it is code running on NostrVault.tld.
The origin boundary isn't being crossed—it's being entered.
Your encryption approach with the NFC card is the right mitigation for this. If the OPFS contents are encrypted and the key never touches JavaScript (stays on the card), then the injected script gets ciphertext it can't use. Just be careful about the window when decrypted data exists in memory—that's still accessible to injected code.