Russians have the best sense of humor

nostr:nevent1qvzqqqqqqypzq2vsfhqacvgptqdg0nxjkt34m7s8hu4m4l3wrlh28yy3dlcnx2gsqyg8wumn8ghj7m3wda4nqtn0wfnj7qfqwaehxw309a3xjarrda5kumtp0p5k6ctvd9ehguewdahxc6twv5hsz8thwden5te0vd58ymmwd93kcefwv3jhvtnww3jkx6pwd96z7qg4waehxw309ajxjar5duh8qatz9aex2mrp0yq35amnwvaz7tmdv4khyetvv9ujuemfwf5kumewdaexwtcqypnp3d7azqy6gm0nn79dsrlpxf9j7fe0ps3kf6mnxl5c822n8m8rxpjv9j5 

 Building an onboarding process without touching user keys with the current state of remote signing is like fighting with both hands glued to your face 

 Just found out my Coracle vulnerability made RHR as "breaking news" 🫠 

 Here's a quick postmortem on the Coracle vulnerability from this morning. If you haven't heard about it, please see below.

nostr:nevent1qvzqqqqqqypzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqyw8wumn8ghj76r0v3kxymmy9e3k7unpvdkx2tn5dahkcue0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uq3gamnwvaz7tmpd3nk7tn4w3ux7tn0dejj7qpqx953gmpz6nwhtm5ys6hadgtre90xx9t8984hdj5nkzud93rq36nsvj9r8a

First off, the offending line of code was incredibly stupid. It only took a glance to realize that something was incredibly wrong. I went back and git-blame'd the line, and discovered that it was the result of a refactor, where a local variable named `session` was replaced by an imported variable with the same name. The former was a random string (in keeping with my attempts to anonymize users). The second was a user session object, complete with private key.

This leads me to my first observation, which is that no one is auditing nostr apps (just as no one is auditing most software out there). In many cases, there isn't even a code review step, because many of us are solo devs. Just because something is open source doesn't mean you can trust it. Just because you wrote something doesn't mean you can trust it! My key was leaked right along with those of my users.

Code review aside, there were some mistakes I made that resulted in the incident being worse than it could have been:

1. I used analytics and error reporting.
2. I did not self-host my analytics and error reporting.

Because I was using a hosted error reporting service, their servers were implicated in my mistake. Had I been self-hosting, I could be more confident that the data I have deleted is actually gone (even if my users don't have the same assurance).

Action item number one: analytics and error reporting are important enough to being able to develop Coracle that I'm not planning on getting rid of them, but I am moving immediately to self-hosted options. If you want to opt-out of that data collection, there is a setting for that within Coracle.

Another mistake I made is that I trusted myself to safely handle my users' private keys. This is more than just my mistake; despite the growth in use of remote signers, it's still very common for nostr applications to offer private key login or generation. But after this incident I'm of the opinion that no one should be handling unencrypted private keys, except for signers.

Applications should not generate private keys or allow users to sign in with them. Period. In fact, I propose we sunset the term "nsec" entirely. There's no need to make a friendly encoding for something that users should never see. Instead, users should be asked to export their private keys in the password-protected ncryptsec format only. This prevents clipboard attacks or poor key management from compromising users.

This is action item number two: I've already removed private key login from Coracle, and will shortly be re-working my onboarding process to redirect users to set up a remote signer instead of generating a key.

This will have implications for UX, and might make things more difficult for new users in the short term. But as nostr:nprofile1qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpz9mhxue69uhkummnw3ezuamfdejj7qgkwaehxw309ahx7um5wfjkc6t5v4ejummjvuhszxrhwden5te0wfjkccte9e38yctev3hkutnrdakj7qf9waehxw309askycmyv4nxwv3sxg6rqvfsxserqdf5xqczu7re0ghhvvf0waesqgqml8ernh9pvds5n0p08lpngpm6a9v749s8et8eghhclzajylw9uyzh4qru  pointed out, the longer we allow users to treat keys like passwords, the longer they're forming poor habits for keeping their keys safe, because the two are categorically different. Removing support for private keys will cause pain in the short term, but will force us to improve our integrations with remote signers, improving security and UX in the long term.

That's all I've got for now. Thank you to everyone for your graciousness, I appreciate all the support. I'm honestly glad this happened, and I hope it will galvanize all of us into action to continue to improve nostr's security. 

 **Security Update**

I've got some bad news for you guys. This morning, as I was adding error handling to flotilla, I discovered that Coracle has been sending user session objects to bugsnag when reporting errors.

Who is affected: Users who triggered an error in Coracle while signed in with their private key, since December 5th 2023.

What I've done:

- I immediately released a new version of Coracle, both to web and to zap.store
- I have deleted the affected apks from my releases
- I have deleted all my error data from bugsnag
- I have deleted my bugsnag project and rotated my api key, so lingering error reports will be dropped
- I have audited my code for use of the session object to ensure nothing else like this is happening

What you should do:

- If you're logged in with your private key, log out
- Hard refresh the page to ensure you have the latest version of Coracle

The bottom line is that if you signed in to Coracle with your private key, it has been shared with me and with bugsnag. In practical terms, your keys should still be secure, since they were sent over TLS, and have been deleted. But there is no guarantee I can offer that they are in fact gone.

I take my users' privacy seriously. My error reporting implementation doesn't record user IPs, it redacts identifying data, and it allows users to opt-out. I also warn the user when they attempt to enter an nsec into a text field. In this case, I simply screwed up, and I sincerely apologize. Reply to this note if you have any questions. 

 test 

 Sveltekit is so buggy 

 Two of my favorite projects lately are nostr-editor by nostr:nprofile1qy28wumn8ghj7ctvvahjuat50phjummwv5hszythwden5te0dehhxarj9emkjmn99uqsuamnwvaz7tmwdaejumr0dshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyd8wumn8ghj7un9d3shjtn8v46xzmrz0yhxxmmd9amrzqpqcesrkrcuelkxyhvupzm48e8hwn4005w0ya5jyvf9kh75mfegqx0q7duqk9  and nostr-signer-capacitor-plugin by nostr:nprofile1qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qg4waehxw309ahx7um5wghx77r5wghxgetk9uqsuamnwvaz7tmwdaejumr0dshsqgxda62rewcec5dts3axd4whwsmn420k8558y34mtxcgyla9ucm5qq6vgqeu . Both projects provide high-quality solutions to specific, difficult problems that application developers can use to significantly improve their UX without reinventing the wheel. Looking forward to more of this kind of thing. 

 Counterintuitive wisdom from "Design for Community":

"Go to the front door of your site and start clicking. Take the most direct path to the post button—the button that a user would click to commit his post to your site. Count the clicks it takes to get from start to finish. The more clicks it takes, the better the posts will be."

We are so trained to "reduce friction" wherever possible. But the implicit tradeoff is toward quantity, rather than quality. The author also talks about leading users through existing content before they are prompted to contribute their own. This encourages people to internalize the community's culture before disrupting it with their own untempered perspective. 

 Here's an idea for relay operators, particularly for communities: you could create a public relay that prevents spam by allowing people to post only after they have a certain amount of activity. If they're not AUTHing, or REQing, they're likely spam. Ask them to engage more with existing content before posting. 

 # stuff