Oddbean new post about login | logout nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzfmhxue69uhkummnw3e82efwvdhk6tcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz8rhwden5te0wdshgetvd35hgefwdpa8yep3xsujucm0d5hsqgpxdq27pjfppharynrvhg6h8v2taeya5ssf49zkl9yyu5gxe4qg55la0jnz I'm releasing an update now that will disable DM decryption by default until you explicitly enable it
Thanks for fixing it so quickly. its an annoying part of nostr, but I cant login to most other web apps because they crash my computer with decryption requests
doing a ECDH derivation seems like a low hanging fruit for native code inside extensions though, has anyone considered this? or even pushing out the entire thing to native code? why is it, anyway, that javascript engines still don't have a native sha256 hash function? or an AES (rijndael) hash function? this seems like a really simple problem yet because they still treat browsers as dumb presentation engines while constantly overloading it with GUI logic nobody bothered to provide a fast path for this
It's less related to this than that 1. some people like to approve every request 2. some signers don't properly implement "approve always", and 3. nip 46 signers are remote and it can be hard to deal with the latency on both client and signer side
My complaint is that almost all apps presume the user will always sign everything, and they usually crash or are buggy when the user does not give the app access to everything
this is because most front end app devs have ZERO understanding of cryptography, not even the distinction between actual encryption and signing the media has not helped this at all, by calling signatures "asymmetric encryption" bullshit. the encryption requires you to do a little computation but signatures are not encryption they are authentication, really big difference
signing is a more expensive operation by like factor of 4 or more than deriving a decryption secret and making a cipher block stream not wanting to see messages that have been encrypted to you is quite retarded, i mean, i don't even know how to express how retarded it is to not want to spend the cheapest amount of crypto compute on seeing what people send you signing stuff, that's a different issue because implicitly you are also sending that out, there should be a clear delineation between actions that are secret and actions that become public or at least move to private across the connection i admonish you guys to do some more study on cryptography and signals intelligence, please
look, put it this way, if someone has already breached your system, they can see all yoru encrypted messages and you are whining because the signer asks you to derive a shared secret????
deriving shared secrets out of a message from your nsec should not require permission at all. at all. if someone is already inside your browser or computer that's a whole separate problem to signing stuff and sending it out, i really hope you get the distinction
Shared secrets gives you something durable that clients can quietly exfiltrate to spy on users later. Not a good idea IMO, but others disagree
if they can get at the shared secret they probably can get at the nsec, how far separated are those two things?
hint: you can't derive the shared secret without the secret. it's one step. one. security of the nsec and derived secrets is almost unity the actual data it decrypts, that's your computer it's on, it's not being SENT ANYIWHERE ffs guys, please, get some fucking realism in your threat models if you can't trust the computer, why you use the computer? oh yeah, because it isn't a leaky sponge like you are trying to make it out to be, yet somehow it is secure in other ways no, fuck you. decrypted messages are adjacent to the fucking nsec