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.
Your proposal is already covered by the regular QR scanning when using my proposal. If a user checked “I scanned this code in person” then no additional verification is ever needed. If a user didn’t check it, then your additional verification-in-retrospect proposal might come in play, but instead they could just meet up and repeat a regular QR scan but then check “I scanned this code in person”.
I really like the idea of making the information a social narrative. This makes the whole key-exchange thing into an exchange of social information. Humans understand secondhand social information and how to assess its trustworthyness.
Another concrete suggestion, possibly nonsense:
The are basically two types of contacts; verified in person, and verified indirectly (via a common friend, a bot, a public QR code hosted on a dodgy website controlled by an authoritarian government, etc.).
There are also dyadic chats and group chats.
Could a chat be labelled verified if everyone in it is linked by in-person verification? So if Alice and Bob, Bob and Carlos, and Carlos and Dongling each have a verified-in-person link, a group of all four of them is verified (you have to trust all the members of a group anyway, since they can all copy the discussion to anyone). But a group of Alice, Bob, and Dongling is not verified (Carlos could have done an MITM attack to gain clandestine access; the membership of the group might not be as it appears).
Unverified chats display their unverified links in narrative form, as previously suggested. Example: Alice sees “Bob said that Carlos said that this is Dongling” (details could be clickthru). This makes it clear to Alice that if she trusts Carlos, the verification of Dongling is trustworty.
When scanning in person, parties should be asked how they are sure of a person’s identity (“I’ve known her since we were both five years old” or “I looked at his Hungarian drivers license and it looked real, but I couldn’t read it”). They should be allowed to include a photo of the person, taken on the spot.
…oh, and obviously one should be allowed to mark an in-person scan contact as indirect, via a thing or a person: “Carlos, identified using a Hungarian driver’s license I couldn’t read”, or “I scanned this code in person; Bob identified the code owner as Carlos and said they’d worked together for over a decade”.
Finally, I think we need a convenient fully-automated key exchange system which is no harder to set up than regular mail.
I trust open-source devs to design something more secure than the ad-hoc solutions end users often come up with.
I realise that this is what Autocrypt and keyservers and so on are about. Allowing such less-secure contacts only for insecure chats, or only for dyadic chats, might encourage scanning.
