The following sequence can in my understanding happen:
A friend contacts you in real life and says they contacted you on some web forum via direct message via a QR code no 1 and says “hey that was me”.
You go to the web forum and open and scan the QR code no 1. However, the owner of the web forum was contacted by some evildoer to replace the QR code 1 image on the server. This evildoer accepted the QR code 1 themselves and then made the owner of the web forum replace it in your inbox server side with their own new QR code 2. (This might be a common thing governments do in this way.)
You scan QR code 2.
The attacker uses some bot to forward any message from your friend gained via QR code 1 automatically to you who scanned QR code 2 and back.
Neither you nor your friend are aware you got a MITM.
People do it all the time. As a receiver I have to play along.
What about:
Receiver side: The scan dialog should contain a check box “I scanned this code in person” that defaults to UNchecked.
Sender side: The create code dialog should contain a check box “I plan to show this code in person ONLY” that defaults to checked.1. Codes created with this UNchecked will on the receiver side hide the “I scanned this in person” and force it to be unchecked. 2. Codes with this checked are single use and expire after 2 hours.
Only checked on both sides will lead to a verified checkmark, otherwise a basic lock icon.
If I scan a more trusted code checked on both sides later, it’s upgraded to a verified checkmark.
If I go into the profile of a user and click some “I found out I received a tampered QR code from this person” button, it is downgraded to a basic lock on both sides.
Both lock icon and checkmark will track and alert of sudden crypto key changes anyway.
this is not a valid argument, then if people use weak passwords with their birthday or don’t put them in a safe place or directly provide them to a scammer doing fishing, lets remove passwords all together because then it is the password’s fault???
the problem could be lack of communication, recently we put a “only share it with people you trust” but then “people don’t read” so if people are bound to do whatever and you can’t expect them to respect any basic rule, can you really solve the problem? they can also give the account backup to someone
but in general I think the whole “super secure” verification topic is overblown, and adding more signals would only over-complicate the app, then yes, it would be a nice app for some crypto nerds that just send memes in the end, but not for most users which would start finding it too overwhelming
This cannot be implemented because this does not translate to anything in securejoin protocol, there is no way to know if the other side has checked “I scanned this code in person” and you don’t have a secure channel to transmit it. If you add the preference of the inviter to the QR code, it can be modified when published on Mastodon. Bob/joiner/scanner has no secure way to learn the inviter preference.
Even if this somehow works, in the end you will not be able to join the “protected” group because members without green checkmark cannot be added there and adding members to such groups is introducing them to existing members so they will get a green checkmark.
I think that’s okay, because if you want to be safe, don’t check it on your end go handing out the QR code online. It’s impossible to prevent every misguided action.
As for groups, I think they should always default to lock icons. (The current “weak” E2EE.) Only if I scan a user directly outside group context, should it show verified for me.
