Minor complaint \ stacker news ~meta

pull down to refresh

1283 sats \ 30 comments \ @siggy47 14 Oct meta

I know friction is a big thing with SN, so I have to express a bit of a whine.

We know that attaching a send wallet is more annoying than a receive. There is less incentive to attach one to start with, obviously, and they are easily disconnected.

I find it to be a giant pain in the ass not having a choice to unlink mobile and desktop instances. I have a need to clear browsing history frequently, and it is a giant pain in the ass to retrieve my pass phrase when I do. At the beginning I would re-create a new one each time, which was of course even more annoying.

I realize I might be among the few who use SN on mobile and laptop frequently, and I also know that as I age I am becoming less adept and tolerant.

Still, it might be an important point of friction in getting and keeping stackers to attach wallets.

view all related items

109 sats \ 10 replies \ @k00b 14 Oct

Tagging @ek so he doesn't miss this.

I don't think we considered someone clearing their browser history frequently. I'm not sure if we can persist the key when this happens, but perhaps there's something we can do to better handle this situation.

248 sats \ 4 replies \ @Wumbo 14 Oct

I don't think we considered someone clearing their browser history frequently

It has become part of my daily routine to reconnect wallets when I boot up devices in the morning.

36 sats \ 3 replies \ @k00b 23h

oh no not good

36 sats \ 2 replies \ @Wumbo 23h

Personally, it is not a big thing for me as I have to re-login into everything else also.

I was just adding my data point that @siggy47 is not the only user who deletes cookies/history/session variables.

10 sats \ 1 reply \ @ek 5h

do you use a password manager?

0 sats \ 0 replies \ @Wumbo 4h

Yes, I create the phase phrase on my phone and then save the value on password manager on desktop (where I often clear history)

147 sats \ 2 replies \ @SimpleStacker 14 Oct

Can users set their own pass phrase? Then they can decide how easy or secure they want to make it

30 sats \ 1 reply \ @ek 5h

No, at least not currently.

The reason the passphrases are generated is so we don't have to worry about spending wallets with weak encryption that we or a hacker could crack if they ever gained access to our database.

But I think I was mostly biased against user-generated passwords because I'm sure some will pick weak ones and I'm not sure in what position this puts us. The obvious solution would be password rules but I was also biased against them because most of the times their UX sucks. But maybe our UX doesn't have to suck? Mhh

I also thought about PINs:

However, maybe a PIN chosen by the user would be even better?

Since we're trying to make it easy to unlock the wallets, and this is currently only possible by entering the passphrase, a user-chosen PIN should be even easier than entering a (custom) passphrase, right?

The issue with that is that encrypting the passphrase with a PIN for easy unlocking is very insecure unless the encrypted data is deleted after a few failed attempts. However, since the encrypted passphrase is stored in our database, we cannot actually enforce a limit on the number of attempts by anyone who has access to the database.

But as you can see, I don’t see how we could implement PINs without compromising too much on security.

0 sats \ 0 replies \ @SimpleStacker 2h

I can see how it puts you in a tough situation. Even if it's the user's fault, you don't want to be caught up in any issue regarding stolen funds.

0 sats \ 1 reply \ @ek 5h

but perhaps there's something we can do to better handle this situation.

see #1256607 for some thoughts

0 sats \ 0 replies \ @ek 4h

Next to PINs, another idea was to seed a PRNG with a device fingerprint and generate a key pair from that. This would mean that the device can always regenerate the same key pair without any user input required.

The first device would generate the passphrase as usual, but then encrypt it with its own public key.

New devices would then be approved by a previously authorized device to also gain access to the passphrase¹ and, therefore, to the wallets.

This is essentially a scheme to sync the passphrase that would only require user interaction when adding a new device.

However, I’m really not sure about using device fingerprints to seed a PRNG for cryptographic key material, lol.

So this still doesn’t solve how to deterministically derive a key (pair) on the client device with minimal friction for the user.

But if we can assume that a user doesn’t lose their key on all devices at once—so there’s always at least one device left to approve a new one—then just the “approve device” part of the scheme could make entering the passphrase much less frequent.

(We talked about this before, so this isn't really a new idea except maybe the part about using device fingerprints as seeds.)

We could probably just store another copy of the passphrase encrypted with the new device’s public key ↩

36 sats \ 4 replies \ @kepford 14 Oct

Do you not use a password manager for the pass phrase?

132 sats \ 3 replies \ @siggy47 OP 14 Oct

On my home network, but not my graphene mobile.

100 sats \ 2 replies \ @kepford 14 Oct

Man, that must be a pain.

Don't get me wrong. I have a stupid master password and 2FA on my phone along with it being Graphene. But it would be annoying to type out all my passwords on mobile.

70 sats \ 1 reply \ @siggy47 OP 14 Oct

I don't use many on mobile. I don't sandbox google apps or do any banking or normie stuff on mobile anyway. The few that I do I have memorized.

36 sats \ 0 replies \ @kepford 14 Oct

Good for you man.

36 sats \ 5 replies \ @justin_shocknet 14 Oct

I had a few small UX suggestions through the CLINK integration since I switch between a lot of devices myself, but it sounds like the lack of password manager on graphene would be a blocker even to those...

Debits from a service key would solve it, and CLINK caters to that, but SN wants to avoid service-level spending ability...

Do you have a wallet installed on the phone that can grant access? A deep link authorization might solve it if so... I could conceive of logging into SN and your wallet popping up a simple accept/deny, sort of like LNURL-auth but not dependent on it.

17 sats \ 4 replies \ @siggy47 OP 14 Oct

Sorry. I don't think I made myself clear. I have no problem logging into the mobile SN wallet. The problem is that I also use my laptop, and the two wallets are linked. If one of the send connections are broken (usually when I clear my browsing history), the wallet is locked and cannot be unlocked without a passphrase. That wasn't the case until the synching of the wallets became mandatory.

Edit- wait, were you proposing a solution to that?

36 sats \ 3 replies \ @justin_shocknet 14 Oct

Yea I follow, the extra passphrase is suboptimal... but do you have the same external wallet on both devices?

What I'm thinking is if your wallet is available on both it could be used directly instead of a password manager to populate the debit string on both devices without the passphrase.

0 sats \ 2 replies \ @siggy47 OP 14 Oct

Right now I'm using alby hub connected to my own node on both.

36 sats \ 1 reply \ @justin_shocknet 14 Oct

Iirc they have an app called "go" that connects to it as an app from devices, using that?

0 sats \ 0 replies \ @siggy47 OP 14 Oct

Yes, I use that on mobile. Obviously I connect directly to SN on both through NWC on the SN dedicated app.

36 sats \ 0 replies \ @OT 21h

I wouldn't put too much weight into that pass phrase. Just save it on both your phone and computer in a password manager.

Also think about using a different browser that's for SN only.

230 sats \ 0 replies \ @0xbitcoiner 14 Oct

Looks like it’s a hassle 'just' to keep our sovereignty, by holding on to the encryption key on our PC/mobile.

36 sats \ 2 replies \ @zapsammy 14 Oct

there shud be more cowboy credit maxis, retrievable sats are for the global south, whom the north is subsidizing in time of strife;

38 sats \ 0 replies \ @DarthCoin 14 Oct

17 sats \ 0 replies \ @siggy47 OP 14 Oct

Somebody has to zap them real sats

105 sats \ 0 replies \ @grayruby 14 Oct

Never thought of this. I so rarely clear my browsing history.

40 sats \ 1 reply \ @SimpleStacker 14 Oct

I'm one of those people that honestly wouldn't mind if SN moved back to custodial. I don't know what the legal implications for them are, and I do appreciate their efforts to make non-custodial as easy as possible.

0 sats \ 0 replies \ @DarthCoin 11h

Footnotes