b7b1382ea9bd -- 4mo The key detail you might be missing is that NostrPass executes in a Worker, not in the main page context. So in NOstrpass it goes client -> vault -> worker. The worker has it's own context and isn't callable from the extension. replyThe key detail you might be missing is that NostrPass executes in a Worker, not in the main page context. So in NOstrpass it goes client -> vault -> worker. The worker has it's own context and isn't callable from the extension.
thread · root 6b4bdc7b…6045 · depth 6 · · selected 010d8f15…f484
thread
root 6b4bdc7b…6045 · depth 6 · · selected 010d8f15…f484
#AskNostr #Nostr 👀 WebWorkers and iFrame isolation with window.nostr.signEvent(), as if it were using any NIP-07extension, represent a great move in the right direction. I recommend that Nostr developers pay attention toOPFS capabilities versus IndexedDB where possible. OPFS avoids metadata leakage and is now part of the Baselinein all browsers. 🔏https://primal.net/e/nevent1qqs8tqf99ddes0jh4lngxaaxjm3r39kc3xvqeh2xjxg7pjmwd87q68qnrcn50nostr:naddr1qqsxummnw3e8qctnwvkkgetrv4h8gunpd35h5ety945kgetww35hg7gpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgq3qk7cnst4fh4ajgg8w6ndcmqen4fnyc7ahhm3zpp255vdxqarrtekqxpqqqp65wuvt8qe
What stops a rogue extension from accessing the OPFS using navigator.storage.getDirectory() by injecting a<script>? Wouldn't any ext have access in that manor?
That is a good question, It is bound to the origin binding: OPFS storage is origin-private. Even if an extensioninjects code, the storage it accesses is scoped to that origin. It cannot cross into another site’s OPFS. So ifyou’re on NostrVault.tld, injected code can only touch NostrVault.tld OPFS, not NostrClient.com’s or a rogueextension.The rogue extension would have to have host permission to access the Origin Private File System (OPFS) andeventually our goal goal is to encrypt the data at rest with OPFS with an OpenPGP cert from the NFC card so arogue extension wouldn’t know how to interpret it or what to do with it, if it got access to it.
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 contentscripts 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 browserexecutes it as if NostrVault.tld served it. There's no origin check that fails because from the browser'sperspective, 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 encryptedand 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.
I’m trying to wrap my head around the differences between using IndexedDB, OPFS, and SQLite in your scenario.I’ve been researching the idea of running an isolated iFrame on client.com for vault.com and passing databetween the two origins via postMessage. In that setup, is there anything in NostrPass that prevents rogueextension <script> injections from compromising the page context?
The key detail you might be missing is that NostrPass executes in a Worker, not in the main page context. So inNOstrpass it goes client -> vault -> worker. The worker has it's own context and isn't callable from theextension.
What stops a rogue extension from accessing the OPFS using navigator.storage.getDirectory() by injecting a <script>? Wouldn't any ext have access in that manor?
df739a4c91de -- 4mo [parent] | reply [1 reply]That is a good question, It is bound to the origin binding: OPFS storage is origin-private. Even if an extension injects code, the storage it accesses is scoped to that origin. It cannot cross into another site’s OPFS. So if you’re on NostrVault.tld, injected code can only touch NostrVault.tld OPFS, not NostrClient.com’s or a rogue extension. The rogue extension would have to have host permission to access the Origin Private File System (OPFS) and eventually our goal goal is to encrypt the data at rest with OPFS with an OpenPGP cert from the NFC card so a rogue extension wouldn’t know how to interpret it or what to do with it, if it got access to it.
b7b1382ea9bd -- 4mo [parent] | reply [1 reply]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.
df739a4c91de -- 4mo [parent] | reply [1 reply]I’m trying to wrap my head around the differences between using IndexedDB, OPFS, and SQLite in your scenario. I’ve been researching the idea of running an isolated iFrame on client.com for vault.com and passing data between the two origins via postMessage. In that setup, is there anything in NostrPass that prevents rogue extension <script> injections from compromising the page context?
