I don't think you can disable networking in the js env though, the background plugin process is its own process with its own sandbox. the js plugin is likely running in the safari process while interacting with websites.

It would be weird if safari executed the js plugin in the native safari plugin background process, not even sure how that would work, but I guess it's possible if they are running a js runtime and communicating to it via postMessage... I will test it to see if I can do a fetch from the js env with the sandbox on.

in either case it looks like nostore is not network sandboxed. 

 to be honest, network sandboxing makes no difference for attacks

the nsec could be sent outside the sandbox just like a signed event for example

but may as well 

 if you don't think having a key isolated in a separate process without networking is much better than having it floating around in the safari's memory space, I can't help you.

ideally key stored in:

hw device > sandboxed process > browser plugin > webpage

saying I'm misrepresenting the problem is just not true, this is an obvious improvement short of hw device signing.

I guess it just comes down to how much you trust browser engineers to not fuck things up. 

 it is objectively an improvement, but for most users it doesn’t matter that much

we should probably also focus on other attack vectors: decryption permission is all-or-nothing, the user can be fatigued into granting unprompted sign permissions to an app etc 

 that is the biggest thing that annoyed me about nostore, most people happily corrupted their data. Mainly because it wasn't ever clear what you were signing. It should try to tell the user what is happening instead of showing a giant scary json blob. I also want to do validation and checks to actively stop signing harmful events like nuking contact lists. nostore never helped with that.

the decryption one is interesting problem, haven't thought about solutions to that yet. 

 it won’t be fully fixable until we make a better NIP-44 that includes kind and source info, because an app can take an encrypted blob and sign a message containing it to make it look like an outbound message, then ask to decrypt it 

 not sure what you mean 

 an approach to limiting decryption access is per kind

but a problem is that you can take an encrypted blob and make it look like something else by putting it in a different kind and with the p tag of the sender to make it appear like it’s an outgoing message + asking the ext to sign

the only solution is indicating the kind and sender in the encrypted blob 

 That’s exactly how my contact list got nuked. 

 working on some new solutions for that, which is why I partially am writing my own relay impl