I’ve got a draft of a post asking questions about nip-46. When i provide an app the bunker url they’re able to then sign content on my behalf with the bunker without my ability to revoke access. I don’t see where bunker’s provide an audit log of which apps are using the bunker, lettting me see what they’ve done and revoke them. I can do this when i use oauth to authorize apps on github or twitter.
There doesn’t appear to be a round trip process for authorizing requests. I think nsec.app does but as far as i can tell the new nstart.njump.me stuff just kind of has you jump through all of these hoops with random nsecrypto strings which aren’t explained, FROST servers, etc… only to give you a bunker url to copy around, which provides no more security for a normal user than asking them to share their nsec…..
I just don’t get it. What’s the point of all this security and layers of confusion. I mean to a user, what’s the difference between pasting around an nsec string and bunker:// string? Both provide irrevocable permanent access to everything you’ve got on nostr and to do anything on your behalf.
With your thing @Terry Yiu it kind of goes the other way, make the user jump through a whole series of 2fa auth steps for each and every action they want to do on Nostr. Are either of these better than an auth server provided by google/microsoft/okta/apple where you oauth in to apps?
If you ask users too many security questions, they just hit the ok button until the popups go away. If you make a system that has unrevokable access then that’s in every way worse than a custodial auth system. I don’t see how the bunker system is better than a server that holds nostr keys, lets the client apps login via normal web login using oauth, and then lets the user see what apps are authorized so they can track which actions were done by what app and remove the authorization token.
Login to reply
Replies (2)
That’s not my understanding of how NIP-46 remote signing works. Revocation is supported. All that needs to happen is for the user to tell the bunker to revoke access to the client-pubkey.
Bunkers can and do keep an audit log. It’s not mentioned in the spec but there’s no reason why it can’t.
The bunker can also refuse to respond to requests from the client depending on the user’s permission settings.
Passing nsecs around and passing connection strings around are not equivalent. Connection strings are single use as the secret is single use.
I think remote-signers do effectively solve security concerns around misuse of user-keypairs as long as the user trusts the remote-signer. My criticism of them is the required server round trips leading to increased latency, and increased difficulty in onboarding and UX. nsec.app and Amber seem to work decently under the circumstances, though.
I will look into adding NIP-46 integration into my signer, but I’ll have to be creative because iOS makes it difficult due to sandboxing, limiting seamless cross-app communication.
FROST signer just doesn't have proper permission management yet. Nsec.app does, and has a log of access, and list of permissions that can be revoked.