There is a generalized over reliance on plain text application specific data published by Nostr clients, which is really concerning. Loads of apps publish this data every time you read notifications, set settings, check your home feed, or manage a premium subscription, among other things. All of this is normally published in plain text to your relays. This data is quite revealing, and the current default behavior of some signers is to sign these events by default, so they get published without the user noticing it. I don't know if you realize this, but it's pretty leaky. I would say it's even worse than centralized platforms collecting data because all of this information is public and in plain text. It's a privacy concern that exposes usage habits and other metadata to everyone, and all of this data can be used by anyone. Are you interested in the last time someone checked Nostr, or profiling an user? Just query for their latest events with kind 30078. This has to improve. Developers should be conscious of how this harms user privacy, and users should recognize how exposed they are. The first thing you can do if you care is go to your signer and disable signing these events automatically. The apps you use might feel a bit broken, and you'll have to sign these events manually, but at least you wouldn't be publishing these leaky events automatically. Now, I'm going to share a little list of what you can find out there... for free
- YakihonneAppSettings
- store-settings
- seen_notifications_at
- ride_request
- routstr-chat-api-keys-v1
- plebs/watch-history
- plebs-settings
- Primal-Android-App
- Primal-Web App
- Primal-Web App | get_app_settings
- Primal-Web App | get_membership_status
- nym-settings
- nym-shop-active
- lumi-settings
- ghostr-publish-history
- ghostr-processed-submissions
- fanfares/purchases
- AmethystSettings
And this is just some of them. If you want to inspect this yourself, you can use and modify this `nak` command:
```sh
nak req -k 30078 wss://relay.nostr.net wss://relay.damus.io wss://relay.primal.net wss://nos.lol | jq -r '.tags[] | select(.[0] == "d") | .[1]' | sort -u
```
Replies (26)
they should always be encrypted wth. i've seen this and constantly scratching my head "why isn't this using an application specific data wrapper with encryption?"
Definitely, or even obfuscated with a derived key. It would be nice if signers came with a 'derive' method so that apps could request derived keys. Of course, this is nuanced and would require the user to set some policies, but in general terms, I think it could be interesting for obfuscation.
the second key used for ECDH with ASD is a one shot only need its secret while generating it, the public key in the prefix with the nonce lets you decrypt the message if you use a key you have the secret for as the second key. PKI based encryption is confusing at first, but you can always encrypt to yourself using a one shot second key, if you have the private key from the other half.
Hey, that's interesting. I've never heard about this one-shot ECDH. I was digging a bit and thinking about how apps can respect user privacy more. AFAIK, the one-shot approach generates a new derived key each time, which is great. However, for app-specific data where a long-term relationship is expected and it should be possible to recover data without knowing the previous key used, for example, while jumping between different platforms in a multi platform app, this approach might not be ideal.
So, maybe something interesting is that users and apps can generate a stable 'channel' to use for this kind of thing. One initial idea is to use DH where the app exposes a public key, for example, the same one used to sign NIP-89 events. Then, the user, each time the app needs to persist settings or whatever, derives the key using DH and publishes the encrypted data using that key. In this case, the DH secret can be taken as the secret key, and the public key can be derived from it. The only entities capable of knowing where the key comes from are the user and the app.
However, this might work but present some limitations. Instead of a pure DH approach, it could be a deterministic KDF. This way, the app itself can have a stable identifier and use it as a salt, so the user can generate a key pair deterministically without requiring the app to maintain a stable public key.
I don't know, just rambling here, but I think it's a topic worth exploring.
yeah, no one cares.. I stopped giving a fuck about what other clients do and try to call them out long ago. focus on your stuff, make it good so you have a better alternative when someone comes looking for it
I noticed that it doesn't even get overwritten for the same app, so the relays are also wrong
You are right, but I cannot avoid sharing this, as users might not know and it impacts their privacy directly.
it's what is used with giftwraps, a one time key used for creating the encryption with a fresh private key, with your pubkey as the other half, and then labeled with the one-shot pubkey so it can be used to make encryption that you can decrypt because you have the pubkey (it's addressed to you).
i'm pretty sure it's how the encryption works for DMs and application specific data and private mute lists and so forth.
i used it with indranet for the packet encryption, the key was known for one side, who will receive it, and used a key generated only for that packet, as the message isn't intended to be read by the sender, only by the receiver. also, with giftwraps, idk why nobody ever really seems to explain it but in order for this kind of "one party only is mentioned" scheme it means when you giftwrap a DM, you have to send a copy to yourself, which is a pretty distinctive timing pattern. nip-04 doesn't do this and IMO it's pointless as far as adding any security goes (since probably both copies are going to have the same timestamp.
anyhow, yes, you can encrypt data using ECDH using an ephemeral message key, which you don't need to remember because the message contains the public key, and is encrypted to your private key, ECDH isn't just for shared secret negotiation, it can be used with a key pair to encrypt as well.
Whenever I see people promoting Nostr for privacy, I do my best to explain that it is not.
Just because you don't go through KYC does not mean a service/platform/protocol is private. It CAN be made to be private, if you go through your own set of procedures and practices, using other software, etc.
Nostr is a cryptographically confirmed public identity system.
The more that users understand this, the sooner we can get privacy methods to be built-in inherently.
btw, TCP/IP is one of the issues. I think increasing the software titles that use Reticulum would be a lower fulcrum for leveraging privacy.
Gzuuus
There is a generalized over reliance on plain text application specific data published by Nostr clients, which is really concerning. Loads of apps publish this data every time you read notifications, set settings, check your home feed, or manage a premium subscription, among other things. All of this is normally published in plain text to your relays. This data is quite revealing, and the current default behavior of some signers is to sign these events by default, so they get published without the user noticing it. I don't know if you realize this, but it's pretty leaky. I would say it's even worse than centralized platforms collecting data because all of this information is public and in plain text. It's a privacy concern that exposes usage habits and other metadata to everyone, and all of this data can be used by anyone. Are you interested in the last time someone checked Nostr, or profiling an user? Just query for their latest events with kind 30078. This has to improve. Developers should be conscious of how this harms user privacy, and users should recognize how exposed they are. The first thing you can do if you care is go to your signer and disable signing these events automatically. The apps you use might feel a bit broken, and you'll have to sign these events manually, but at least you wouldn't be publishing these leaky events automatically. Now, I'm going to share a little list of what you can find out there... for free
- YakihonneAppSettings
- store-settings
- seen_notifications_at
- ride_request
- routstr-chat-api-keys-v1
- plebs/watch-history
- plebs-settings
- Primal-Android-App
- Primal-Web App
- Primal-Web App | get_app_settings
- Primal-Web App | get_membership_status
- nym-settings
- nym-shop-active
- lumi-settings
- ghostr-publish-history
- ghostr-processed-submissions
- fanfares/purchases
- AmethystSettings
And this is just some of them. If you want to inspect this yourself, you can use and modify this `nak` command:
```sh
nak req -k 30078 wss://relay.nostr.net wss://relay.damus.io wss://relay.primal.net wss://nos.lol | jq -r '.tags[] | select(.[0] == "d") | .[1]' | sort -u
```
View quoted note →
How do I modify the command? I replace the d with my pubkey?
Is there a way to improve it?!
Is nostr actually just a psyop to make us share our opinions uncensored along with all of our other information so that it becomes easier to hunt down people they see as a threat?
Or is this just Devs not actually caring about users privacy?
I already dox myself with photos and using my real name but for people trying to be anonymous on here, most clients just leaking your data publically.
View quoted note →Probably the latter but suspiciously looking at the former...
Yes, as I mentioned, reject signing these events. The good part about Nostr is that users retain agency; no one can get a signature out of you if you don't allow it.
No, no, the command already works without modification. It gets the 'd' tag from the events with kind 30078, which is normally used as an identifier, so the semantics reveal what they are being used for. If you want to see the events published by you, you have to add an '-a' flag with your npub, like 'nak req -a your-npub ...'
The latter. The former is a possibility, but the only way to achieve that is to control the relays where the users publish. So, if you run your own relay and adopt privacy measures, no one that you don't want would be able to psyop you.
they should use private note storage spec for things like this
Provably yes, what's that spec, is just giftwraps?
Nip 37?
Draft wraps? Maybe
no its not giftwraps, giftwraps are more complex
Thx!
Ok. From today I reject everything.
But I guess this is and should be an temporary solution.
This is a solution on the user side.
Would be a solution on the dev side be possible?
