To be honest, I am concerned about the anonymity in Nostr. If you suddenly don't know, then when you view your account through the web version, then:

1) Every relay knows your referrer (site name)

2) Relay knows your IP address, and probably your npub (when there is a request to subscribe to a feed about a certain user - about you yourself)

Also, if you correspond with someone in a personal chat, everyone can find out with whom and how many messages (only they do not know the text of the correspondence). All this is quite dangerous for those who want to remain anonymous. For example, in totalitarian regimes it is very dangerous.

Reply to this note

Please Login to reply.

Discussion

3. Everyone knows with whom you're DM'ing with (and the length of the message and other meta data).

I wrote about this under point "2" but without number "3"

Yes - important that this is understood! The current implementations are not focused on privacy, but rather censorship resistance …

Given the specifics of Nostra, that it is impossible to delete data is even more dangerous. For example, you wrote to someone in private correspondence and anyone can then see with whom and when you corresponded. This is, in fact, public metadata in plain sight... I think in the future we will learn about more than one case when they were arrested for it (China, Russia, etc..)

If anyone wants to personally check - go to https://snort.social/, click "Login" and specify any npub* key - you will see everything as the owner of the public key would see, except that you will not be able to read the text of personal correspondence with anyone. It's not very nice to find out about it ;-/

Just imagine that any oppositionist of the government has a Nostr account. In this case, it is enough for the authorities to put in Login his well-known key, go in and see all the keys (nostr accounts) of those who wrote to him personally in correspondence. Next, it is a matter of technique to calculate the IP addresses of those who wrote to him. Especially if you deploy a network of fake relays in order to collect data.

I'm super curious if something like the signal protocol can be implemented on top of nostr... The private comms over nostr space is basically at day-0. The current DM scheme is basically a proof of concept from what I understand

Or another, simpler scenario. You are an oppositionist, and an undercover law enforcement officer sends you a personal message. You just go to watch, and your client (Android application or web version) automatically loads the image from the address specified in the message. Loads from the sender's server. And now your IP address is already known....

Any reasonably sane email client will not load remote content by default. Nostr DM clients need to behave similarly. Some email clients might load external content through a dedicated proxy. That is also problematic as it lets the sender know exactly when the email is opened.

Any website you visit the owner of the website knows your IP address.

Some best practices on Nostr:

Always use a reputable VPN.

Never enter your private key into a a web client. (Use Alby instead)

The Amethyst client on Android stores your private key locally on your phone and it's not transmitted to the app owner.

Use a VPN, period

And what about mobile devices? For example, if the Nostr client periodically loads feeds (for a certain npub through a "subscription")? Have a VPN enabled all the time? And if you need to turn it off sometimes? However, in Android, you can specify that certain applications go only through a VPN. But it's all complicated for the average user.

It seems to me that the best thing so far is for the client programs of Nostr to offer simple settings to go only through Tor, and in no other way. #[5] ?

Regarding referrer, browsers send the `Origin` header on WebSocket connections, revealing the domain name of the client app. Other resources can be loaded without referrer/origin through `Referrer-Policy`. This does not affect the WebSocket `Origin` header.

I did some testing and found a trick: Put the WebSocket client in a sandboxed iframe.

Demo here: https://sha.femtol.net/dev-tests/ws-origin/iframe-sandbox.html (use the browser's network console).

Tested and works on both Firefox and Chromium. It might not work on older Firefox browsers, though.