Skip to content

Instantly share code, notes, and snippets.

@Hocuri

Hocuri/verified_group_improvements.md

Last active November 20, 2023 14:31
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Hocuri/29839ad9c205a3fb89bf525dd1574e06 to your computer and use it in GitHub Desktop.
Save Hocuri/29839ad9c205a3fb89bf525dd1574e06 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
verified_group_improvements.md

For each problem, I listed one or multiple possible solution(s), and sometimes I added in brackets where I got the idea from, e.g. "(Signal)".

Usability problems with verified chats

  • Possible attack: Change the display name to "Bob ✅" to make Alice think that this account is verified.

    • Solution: Forbid some characters in display names and groups, e.g. ✅, ✔️, ☑️, 🔒, 🔓, 🔓, 🔏, 🛡️, 🔑, 🗝️, ⚿, 🔐, ㊙️, ㊙ (japanese for 'secret'), 🟢, 🔵, 🟩, 🟦, 🔷, 🔹, 🛡, ✓, ✔, ☑, 🮱, 🗸, 🗹, 🗝, ⚿

  • People don't know what verified groups are

    • There once was the idea of renaming them to "protected" groups (see "History" below), but it was not sure whether this improves things
    • Solution: Add better help texts

  • Possible attack: Eve can just change her displayname to "Bob", and Alice's device will show the messages as coming from "Bob"

    • This is made worse by the fact that it's possible to send an email "To:" the whole group, but "rcpt to:" only one member, and there is no way for Alice to know that the message wasn't sent to the other members.
    • As long as anyone in a verified group can introduce anyone else as "verified" (see next attack), that's kinda hard to fix
    • Solution 1 (WhatsApp): Require the user to add all chat partners as contacts, for all non-contact chat partners show a "~" before the name.
    • Solution 2 (Signal): When Eve changes her displayname, add a system message "Eve changed her name to Bob" to all chats with Eve.

  • Possible attack: If Eve and Alice are in a verified group together, Alice can add a fake Bob (bob@evil.com) to the group & Alice will regard him as verified.

    • Solution 1: Show who verified whom ("verified by") - already partly implemented
    • Solution 2: Add different levels of "verified": Verified by me, verified indirectly, unverified. For presenting to the user: Threema shows a security level as 1 (red), 2 (yellow) or 3 (green) dots.
    • Solution 3 (Protected chats): Make transitive verification only valid for the origin group
    • Solution 4 (Signal): Show a warning if two members have the same display name

  • Possible attack: If Eve has Alice's QR code, she can create any verified chats with her

    • Solution: Could put a timestamp into the QR code, and if it's too old, then only do one-way verification
      • Problem: one-way verification is hard with verified groups UX wise - you'll have groups that are verified for some people but not for others
    • Solution: Could ask Alice "Do you want to create a chat with Bob?" -> if the activity is already closed, only do one-way verification

  • It is impossible to get in unverified members to a verified groups

    • Solution 1 (Protected Chats): Add possibility to downgrade a verified group
    • Solution 2: Add a way to "Clone Group"

  • It's not easily possible to retroactively detect a MitM attack

  • When we receive a message with a new (unverified) key in any chat, it is unlikely that the chat partner still has the old key. We may want to mark the 1:1 chat as protection-broken and warn in group chats that the contact can most probably not read the messages.

  • Possible attack: QR codes leak online status

Solved

  • No verified 1:1 chats

    • Problem: You don't land in a verified chat after scanning the verification QR code, which can be surprising
    • Problem: This makes verified chats annoying to use in 1:1 communication, and almost nobody actually uses them.
      • Probably biggest reason for not using verified chats.
    • Solution 1: Create a second chat that's verified, then all encrypted, signed & verified messages go into there. Keep the opportunistic 1:1 chat for other messages.
      • Downside: It's going to be confusing that there are 2 chats, and not clear if people get suspicious just because an unsigned (evil) message appears in the wrong chat
    • Solution 2: Just ask people to create a verified group with 2 participants, or do this automatically
      • Upside: Very easy to implement
      • Downside: That's even more confusing, and the group has to be called the same for both sides
    • Solution 3: Mark the 1:1 chat as "verified" (this is the favorite solution of many people)
      • To decide: What happens with messages that are not signed/encrypted/verified?
        • Solution 3.1 (Protected Chats): Don't show message content & continue sending messages with the verified key. Ask the user whether to disable verified-ness.
        • Solution 3.2: Accept peerstate change & unmark the chat as verified. Add an info message to the chat & require the user to confirm, similar to a contact request.
          • To decide: Do we want to show a red exclamation mark on messages with the wrong key?

  • The 2 options "Create group" & "Create verified group" are confusing

    • Solution: Postpone the decision whether to make the group verified

History

There was an attempt to rework "verified groups" as "protected chats": deltachat/deltachat-core-rust#1968, but it failed: deltachat/deltachat-android#2099

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment