NIP-46: It's not obvious to the end-user that optional secrets are not temporary

[alopatindev]

Consider the following flow:

1. Uncle Normie (UN) initiates a direct connection using Amber signer by generating a bunker:// URI with optional secret
2. UN is aware it's a secret, but not that it's not a temporary secret

• UN might think that the entire URI is something like 2FA auth token, just too long to type manually

3. UN transmits it over untrusted proprietary messenger to his PC and pastes into a non-type="password" wnj input field and successfully establishes connection after clicking on Amber notification
4. Amber doesn't show the URI anymore, so it appears to UN that the same URI is not designed to be used multiple times, it's probably impossible
5. Stranger uses the same URI to connect their application and sign their message

• Stranger succeeds because UN clicks on the granting notification again because it's not clear what's the normal behavior. UN might think that he received the notification because:
  • it was a requirement of permission for new kind of event he was about to sign
  • or perhaps it's because client recreated a session due to who knows what, IP change for instance, and for some reason signer requires granting this session again
  • or perhaps it's a result of some client/device bug UN got used to.

That's unlikely, but perhaps UN has actually read entire NIP-46 multiple times and he carefully reads every mobile notification. But even then he could accidentally click on the malicious notification if it appeared just before attempt to click on some other one.

Ideally I'd never want to see any signer notifications if Stranger tries to establish a new session using the same URI with the same optional secret key. I just don't expect it; I expect a single endless session for a single app I granted for the single device. Perhaps "app" is the wrong concept here, it's actually a session (and "secret" is actually a token).

If it's not possible, at least I expect a signer implementation requirement for explicit warning that the long line of the copied text is not safe to transmit over untrusted channels.

[alexgleason]

This seems like an implementation detail of Amber. In nak (and ditto) the optional secret is one time use.

[alopatindev]

That sounds good. I believe that should be required for all signers implementations.

[alexgleason]

I agree, I think it should be updated in the NIP.

[mikedilger]

Optional secret is consumed and one-time in gossip. So I concur.

[pablof7z]

same with nsecbunker; one time only.