Thread

Replies (5)

↩ replying to elsat
No worries. Also here are some potential mitigations that tend to get suggested in these contexts but that are problematic:
JOE2o's avatar JOE2o
Issues with potential mitigations that don’t expose metadata on the relays. [Forcing every new message to be a reply to an older message and then hashing the in-reply-to message and putting the hash in the rumor, then having the client display some warning like “this person may be responding to a message you haven't received” if the message corresponding to the in-reply hash is not known to the client.] Doesn’t work because it’s a flat space. You cannot force every new message to be a reply to an older message. If people want to explicitly reply to an older message they can, if not then not. (Mostly they won’t.) Also a malicious actor can selectively omit the "parent" message for one specific user. [As above, but hash of the last-seen message for that sender instead.] You’ll be drowning in false positives. People talk over each other all the time. And then there’s latency issues, drafts composed offline, etc., messages will arrive to clients out of order constantly. Security warnings are useless if there are 1,000 false positives for every genuine case of detection. Not only that but the context injection attack still works, the attacker just needs to have one “clean” message before the elicited response. So they drop a clean emoji right after the dirty message and done. (And then it’s even more dangerous as the lack of a warning gives an explicitly false sense of security.) [As above, but a previous-hashes array going back quite far, so vector-clock ish] Many of the same (or similar) issues as above and now every event has a map of the conversation history. Also, you're well on the way to Marmot here. TLDR, keep it in the rumor, relays stays blind, good for privacy, but relays cannot enforce the order and so the attacker is always free to lie to different people simultaneously. As for potential mitigations that do expose metadata on the relays, not sure those are worth exploring, given that the slightest toe-hold always leads to the next toe hold.
View quoted note →
↩ replying to elsat
I don't think it's practical to be honest. This is a flat messaging space, that's more email logic. It would only catch out an attack if (a) everyone who makes mission-critical replies goes through the UI motions to actually select the message they're replying to and choose "reply", and (b) if the thing being replied to is split across multiple messages and amongst those are dirty and clean messages then people don't reply to a clean message, and (c) the fact that false positives are appearing all the time doesn't just cause everyone to turn these gap warnings off. And other things. And then you have variant attacks which involve purposely not sending messages to certain people, and these attacks can't be caught out like that (selective omission attacks), there is no gap to detect. The main thing though is that this is not a case of general protocol inconsistency. This is a case of deliberate and potentially high-cost attacks, depending on the chat context. It's based on legitimate user expectations in 2025. With WhatsApp, Signal, Telegram, Slack, etc., the guarantee is that anyone else that has ‘loaded’ to the same point in the conversation as you will see the same history as you. If they are not at that point yet (have been offline, etc.) when they get there they’ll see the same history. This is deeply ingrained. With NIP17 groups, it’s entirely possible that a group of x people all loaded up to the same point (all seeing the same most recent message) each have very different (and in these cases *purposefully* different) histories as a result of this. In Kind 1, a missing parent is an annoyance. But we're not talking missing parent annoyances here, we're talking con jobs. You could in theory pull of a con like this in Kind1, but given the full transparency of kind1 it'd be orders of magnitude harder, if possible at all. In Kind 1, the source of truth is the relay's public feed. In NIP-17, it's a collection of individual envelopes addressed to specific people and with no exposed metadata beyond the recipient pubkey. So yeah, it's the deliberate attack risk vs. general protocol inconsistency risk. I just don't think NIP17 groups are feasible in 2025 outside of small clusters of trusted friends with developer backgrounds. NIP17 one-to-one is fine though, it fills a genuine gap and is elegant in its way.