Nostr Web Client

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.

JOE2o 2w ago

And by way of example:

I’m in a group with 2 normies. They trust each other. I’m the baddie here.

There is something being discussed that involves them paying me.

I send a payment address (or URL, or whatever) as a message. What I actually did was I used a malicious client to send one address to Normie 1 and a different address to Normie 2. Nobody is aware of this but me. The two normies both think I have sent one single address to the chat group. As pretty much any normie would assume.

I then send a praying hands emoji.

Normie 1 says: “Done, it worked, appreciate it!” (This is a new message)

Lucky me! I just needed Normie 1 to do the payment first. This instils confidence in Normie 2, which was my goal all along. It was a 50/50 and I won!

Of course there’s something not right with the address or URL for Normie 2 (use your imagination). Perhaps if Normie 2 was more on guard they’d clue in while paying and then unlocking whatever it is. But I’ve used Normie 1 to bring Normie 2’s guard down.

Normie 2 pays to the address or URL or whatever it is, but sadly for them [insert whatever bad thing happens as a result].

This way of scamming (split view attack) would just not be possible on WhatsApp, Telegram, Signal, etc.

And even after Normie 2 clues in that something that should have happened didn't happen, there'll still be much confusion. Normie 1 and Normie 2 would basically have to screenshot the chat and compare screenshots to figure it out. So even after the scam I can potentially continue to gaslight Normie 2 using the success of Normie 1.

Reply to this note

Please Login to reply.

Discussion

JOE2o 2w ago

I think this scam example is a good one to measure solutions against, as most people would (I hope) agree that the baddie should not be able to get away with this in a modern chat app.

And perhaps a sister example with the same scam but two baddies vs. two normies. (The two baddies are working together, tagging each others fake events and fake-tagging the normies real events.)

But one baddie to start.

The simple methods like "just hit reply" don’t work.

The slightly more complex method of tagging the last seen message at time of compose/send is easily thwarted by the praying hands emoji.

So then the more complex options.

Caveat, I suspect they all end up in the uncanny valley between NIP17 and MLS, where you’ve lost the simplicity of NIP17 and haven’t gained the functionality of MLS. But open to some solution if it's out there.

The e-tag all/some past messages option (Batman The Dark Night master view option) I did game out before and remain ambivalent about it. Depends how far you take it. Security-wise is it a good idea to have an event ID history in every single new message? And for clients to detect a mismatch they'd have to basically traverse a DAG every time a new message arrives, and often on cheap mobiles. For both those reasons you’d seemingly be pushed towards a small sliding window to save on client-side computation and avoid too big of an ID map in each message. But go too small and the baddie can bury the scam. Maybe there’s a sweet spot. But the biggest issue for me about this one is false positives. If this produces a warning two or three times a day due to lag and just general nostr jitters the user will start ignoring those warnings pretty quick.

False positives for the invisible receipts method would be pretty extreme too, I think.

My gut is still that NIP17 one-to-one is a big win, best to go hard on that. NIP17 groups feels like getting greedy and paying the price, and harming the one-to-one use case in the process.

But I’m open to there being some tweak of, or combo between, what’s on the table (Dark Knight mode, invisible receipts, bloom filters, multisig, ring signatures, a few ZK things I've looked at and not mentioned yet) that won't blow interop to smithereens and that doesn’t end up deep in the uncanny valley.

For this use case what would you say is the most efficient solution that doesn't result in a detrimental amount of false positives?