after working on Damoose (safari extension), it seems nostore is pretty insecure because it exposes your private key to the javascript environment.

Since we store your key in the iOS keystore, we can just access this from the plugin background process instead of the browser's javascript runtime environment.

We can sandbox the plugin process to disable outgoing networking connection, so it can only send messages to and from the browser, so it should be way more secure than what nostore was doing.

https://cdn.jb55.com/s/93bf3c58285fb23a.png


Oh.

*Deletes Nostore from loaner iPhone*


Even nip-07 extensions like Alby do this #yolo


Is this out already?


yeah I'm not sure if you can make an isolated and secure browser extension outside of safari ?


wow. good to know.

nostr:nevent1qqs96t58lszflzkevzswdwyz2ts8s8x5ymgz8l3w3y6wv8pyqdgdxzcpz9mhxue69uhkummnw3ezuamfdejj7q3qxtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsxpqqqqqqzkpfk6h


orly. well that's a bad time.


Good question. Maybe through some wasm?


Apple Problems as usual
nostr:nevent1qqs96t58lszflzkevzswdwyz2ts8s8x5ymgz8l3w3y6wv8pyqdgdxzcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpjuxp8vd29p6ancknaztql3eajk52y8xkppfn7au7elkw9c68zg5psgqqqqqqs54t4hr


eeek

eeek


Thank goodness it’s open source.
Now we are all certain we have no nsecs 😅


HELLO 👋 GUYS, I RECENTLY PUT OUT AN INVESTMENT WITH $1000 AND GOT $6K IN LESS THAN 6 HRS, IT'S SO FAST AND PROFITABLE GUYS, HONESTLY IT'S BLEW MY MIND. HIGHLY RECOMMEND IT AND SUGGEST Y'ALL GO GIVE IT A TRY, SEND DM TO MY COACH nostr:npub1wj92aqu96a2wmjd47e0w8ptanyxqfh74x9h42x0hmhxegeuy4r9ql3kj56


damn this hard af


For reals. I can’t stop playing it. 🤣


Yes. I think most people misunderstand how this works.

A bit of JS code is injected that takes the nostr.* calls communicates with the extension that is in an isolated context (AFAIK with postMessage). The extension then checks permissions or does popups.

:/ please do some research


yeah its slightly more isolated, but its still floating around in the process space and js env. I would just feel more comfortable with runtime.sendNativeMessage to an app with no network access and shared keychain access with Damus


makes sense, but you probably have bigger problems if there’s a safari ACE vulnerability


Could you share the lines of codes (on Github) where Nostore saves the nsec in the JS runtime env? 🧐


well you paste the nsec into the plugin interface which is js. a better thing would have been you put the nsec into the native app interface, right now that just says "open safari to configure".


That always confused me. If I’m installing the app, why not manage everything there.

But I thought there was a technical limitation.


I mean they are both theoretically secure, one is just more secure than the other, so I don't know why it was done that way. maybe I will run into a technical limitation, but it doesn't look like it so far.


Can’t wait to test.


one is more secure than another in a very specific edge case that involves zero-days that would not be wasted on an nsec, I guess


Or you could stop using appple just a thought


just doing signing in a sandboxed env with no networking is just defensive programming. it's also just practical for us because sending the nsec from native code into a js browser extension just seems wrong.


yeah. I expect browser extensions to be sandboxed just as well as websites, though.


We don't get out of bed for less than $100k and if you want to make money follow nostr:npub1apuvpy5dge425rhsq2hedyhlgstkm2q70wv3657zrnkcyv09h7jq4z7jxs he's ALWAYS right.


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


That’s exactly how my contact list got nuked.


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


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


after working on Damoose (safari extension), it seems nostore is pretty insecure because it exposes your private key to the javascript environment.

Since we store your key in the iOS keystore, we can just access this from the plugin background process instead of the browser's javascript runtime environment.

We can sandbox the plugin process to disable outgoing networking connection, so it can only send messages to and from the browser, so it should be way more secure than what nostore was doing.

https://cdn.jb55.com/s/93bf3c58285fb23a.png


How can I get this extension?


gotta build it first


This is going to be amazing 🤩