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
yeah I'm not sure if you can make an isolated and secure browser extension outside of safari ?
Good question. Maybe through some wasm?
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
orly. well that's a bad time.
wow. good to know.
nostr:nevent1qqs96t58lszflzkevzswdwyz2ts8s8x5ymgz8l3w3y6wv8pyqdgdxzcpz9mhxue69uhkummnw3ezuamfdejj7q3qxtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsxpqqqqqqzkpfk6h
Apple Problems as usual
nostr:nevent1qqs96t58lszflzkevzswdwyz2ts8s8x5ymgz8l3w3y6wv8pyqdgdxzcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpjuxp8vd29p6ancknaztql3eajk52y8xkppfn7au7elkw9c68zg5psgqqqqqqs54t4hr
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 @coachalex0
We don't get out of bed for less than $100k and if you want to make money follow @thiefofsats he's ALWAYS right.
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.
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
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.
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
Or you could stop using appple just a thought
How can I get this extension?
This is going to be amazing 🤩
Oddbean new post about login | logout 