Nostr Web Client

You can propose always tagging the last message automatically and checked my receives in the nip. Super easy fix.

Also security theatre though, best avoided. A false sense of security is always worse than just being on your guard all the time.

First you have to have some notification for Person B if the most recent message seen by Person A (at the time that person A was composing) isn't seen (yet) in the history of Person B, and these notifications will be flooded with false positives. (If you don't have a notification then the gaslighting attack, which could easily be real-time in nature, goes through.) I'd imagine most peole would hate it.

Second, the attacker just sends an emoji immediately after the gaslit message and done. Person A's client only does this auto-tag for a new message, but by the time Person A is composing this new message the gaslit one has been buried under a clean one. So the auto-reply checks out.

And then if you start going down the multiple past messages array or Merkle route paths, you're basically attempting to recreate Marmot/MLS from the ground up.

Unless you meant some other way, not background-replying to the most recently seen message as I understood it there?

Reply to this note

Please Login to reply.

Discussion

Vitor Pamplona 2w ago 💬 2

Multiple simple things have been suggested already to fix this but in the end no one saw it as that important for users. But it can be super simple because users just need to know that one other user is gaslighting everyone and kick him out. Tagging all IDs at least once in the conversation on new DMs can make a complete record of what the user has seen. Bloomfilters of messages in the past month/week can also help and fully solve it. It's not just theater.

After all, it is possible to apply the same gaslighting tactics in every single nip in nostr. The simple fact that we can create content in the past can be used to gaslight everyone. They don't need the DM spec for it.

JOE2o 2w ago

NIP17 groups are the only space in Nostr where this is code red. Both technically and socially.

Technically other Nostr kinds are more transparent, have *some* exposed metadata handles, are not fanned out one by one, etc.

But most importantly socially. Few people are going to get conned or socially engineered in kind1 threads or discord style NIP28 chats or whatever else. A closed Signal-style chat group, and one boasting best-in-class privacy, is a totally different risk space. If you're an attacker looking to expose this nostr gaslighting quirk, then NIP17 groups are straight where you'd head.

Vitor Pamplona 2w ago 💬 2

Again, it's an easy fix if what you saying truly matters. But something tells me you are not interested in fixing it.

Other nips are not "more transparent". You can literally do the same thing in almost all of them with the same level of metadata. I know because I have debugged things like that in almost every nip Amethyst implements.

Right now, my friends gaslight me on Signal and Whatsapp by editing and deleting messages as well or playing with push notification timing attacks. So, not even Marmot actually solves this.

JOE2o 2w ago

Believe me I looked at this top to bottom, and top to bottom again. There is no easy fix.

All of these easy fixes you're proposing, none of them come close to being either a fix, or easy, or both. This is a solved problem and you need one of the refined solutions we already have.

And to say this is in the same category as editing and deleting messages on Signal is kinda disingenuous.

Vitor Pamplona 2w ago 💬 2

You were the one calling it "gaslighting". Gaslighting is gaslighting, regardless of the stack.

I don't know exactly what you want solved since many of the things you cited in this thread are indeed solvable by the simple solutions I cited. I not only looked at them, but I actually coded and tested some of them. And they do it just fine. They just add more complexity for minimum gains, IMO.

JOE2o 2w ago

Which solution specifically?

The "remember to hit reply" solution doesn't work, clearly.

The "hidden reply to last-seen message at time of compose" does not either.

Your bloom filter one, if you’re saying every new message can include tags for every ID of every message the client/user has received, in the whole history of that group (or to some length back), and bloom filters on top, not sure where to start (also not sure that's what you're suggesting).

What are the other simple solutions?

Vitor Pamplona 2w ago 💬 2

Again, I don't really know what you are actually trying to solve. If the goal is to just highlight to users that a person is the group is fucking them over in the last messages, all you need is a quick check on the last messages. You can add the e tags for as many messages are need to fix for the time wanted. Or you can do bloom filters. There are new kinds that were proposed to mark as seen each message, like a NIP25 reaction would be. There are other proposals that "summarize" things because really only the current messages matter. There are proposals that build a full chain of event IDs from the beginning to end of the chat. There were summary events discussed in the past. There were even MuSig and even ring signature authentications for everyone in the group. There are dozens of options for the things you mentioned. All of them have pros and cons. The more complex ones solve the most amount of issues related to this that you didn't even mentioned, but they all come at a cost of complexity.

JOE2o 2w ago

Trying to solve is this:

Reduce the chance that normies, thinking this works like Signal, WhatsApp, everything else they've ever used, get scammed here. By way of a gaslighting attack that is unique to NIP17 groups, and, if undertaken with skill, could be very effective. Assuming there comes a time when normies start to use this, which I'm hoping there will.

This kind of gaslighting risk in closed-group ultra-private messengers is not normal, you have to admit that. Name me any other messenger in the category of ultra-private messaging that carries this risk? I'm open to the fact that one might exist out there, and if so curious what the UX is for this, but I haven't found any.

For solutions, what I'm saying is the only solutions you're touching on that actually have wheels are really complex. It's a solved problem and all existing solutions are really complex too, so that only stands to reason. There are no simple fixes that don't end up as security theatre in some way.

Vitor Pamplona 2w ago 💬 1

Can you define what you mean by gaslighting? Gaslighting can be a lot of stuff (the word is VERY broad) and it does happen in signal and what's app too. So, if you want to keep debating this, you will need to define it better. Just "protecting normies from scammers" won't work because scammers don't need this flaw to scam people. Even if you fix it, they will still get scammed. You need to define what exactly you want solved.

I think you are just dismissing actual solutions because they are not perfect. Nothing will ever be perfect. They can only help solve the things that were more appropriately specified. If they are specified then we can measure how well each solution works to solve it for the cost of implementing and pick the best one.

JOE2o 2w ago 💬 1

Sure happy to define it.

- Person A, Person B and Person C are all “up to date” (seeing the same most recent message).

- The history of Person A can contain one or more messages that are not in the history of Person B *in any form*, not a deleted-message tombstone, nothing, no trace whatsoever. And the reverse. And the same for Person A-C, B-C.

- Additionally the history of Person A can be missing messages that appear in the history of Person B, again with no tombstone, no trace, no indication whatsoever that something is missing.

-These "He sees it, she doesn't" messages can be sent simultaneously, so at the same time (and with a malicious client) Person D can send a separate message to Person A, a separate message to Person B, and a separate message to Person C. (or send to all but A at the same time).

Also I'd add that any detection method cannot result in a false positive and is therefore explicitly trusted.

The above combination of factors enables a level of social engineering that you can't really compare with what an attacker could achieve on Signal, WhatsApp, Telegram, etc. Yes of course people will get scammed anyway. Scammers love Telegram, and Telegram's serer ensures the above can't happen. What I'm arguing is that after getting scammed on Telegram it's fair to say (if cruel) that they have themselves to blame. For this case, if you game theory it out, I don't think we can say that they do fully have themselves to blame. It's a very unique attack vector.