Add verified 1:1 chats

[Hocuri]

The issue description here is a living document where I record all the ongoing discussion. Below we can have an "unordered" discussion.

User Testings

Core PR, Followups: #4538, #4539, #4542

Android preparation PR, Android main PR

FAQ PR

Motivation

Today only group chats can be verified.

This makes verified chats annoying to use in 1:1 communication, and almost nobody actually uses them. This is probably biggest reason for not using verified chats.

You also don't land in a verified chat after scanning the verification QR code, which can be surprising.

Proposed solution

After lots of discussions between various people, this seems to be the general consensus now:

After scanning a QR code (note that no user choice is required):

• Get into a chat (this already is the case today)
• mark the 1:1 chat as "verified"
• Show a very big info message with a verification symbol and an explanation text

When an unverified message comes in:

• Mark the chat as non-verified
• Show a very big info message with a crossed-out verification symbol and an explanation text.
• Show a dialog instead of the input bar, similar to a contact request. I'm going to call it "input-bar-dialog".

Rationale

• The info messages scope which messages are verified and which ones are not (except for outgoing unencrypted messages)
• The input-bar-dialog prevents this "race condition":
  • The user enables chat verification
  • They start typing a message
  • Just before they hit 'Send', an unencrypted message comes in
  • -> they unintentionally send it unencryptedly

Alternatives

• Alternative 1: Don't mark the existing chat as verified, but create a second chat that's verified. All encrypted, signed & verified messages go into there. Keep the opportunistic 1:1 chat for other messages.
  • Upside: Telegram also uses this UX for their "secret chats"
  • 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
• Alternative 2: Don't introduce verified 1:1 chats. Just ask people to create a verified group with 2 participants, or do this automatically
  • Upside: Very easy to implement
  • Same downside as Alternative 1
  • Another downside: A group has to be called the same for both sides, i.e. if Alice creates a group "Bob verified" with Bob, then it will also be called "Bob verified" on Bob's device. So, the group name has to be "Alice & Bob verified".
• Alternative 3 (Protected Chats): Mark 1:1 chats as verified as I propose it here, but change the behavior when an unverified message comes in: Don't show the message content & continue sending messages with the verified key. Ask the user whether to disable verified-ness.
• Alternative 4 (from @iequidoo below): On a receipt of unverified message, let the user to make a choice: "Downgrade to non-verified" and "Move new unverified messages to a new chat".
  • Upside: A chat can't just suprisingly downgrade to unverified - if we go for my proposed solution, @iequidoo would like a text like "Now the chat is verified, but it can can downgrade if... If you want a chat that never downgrades, then..." when a chat is upgraded to verified.
  • Upside: User can postpone their decision on which chat type to use
  • Downside: A lot more work.
  • Downside: There is a user choice, where many users won't know what to select.

Wordings

• In the info message after a verification: "Messages are guaranteed to be end-to-end encrypted from now on. Tap to learn more."
• In the info message: "Bob sent a message from another device. Tap to learn more."
• In the input-bar-dialog: "Bob sent a message from another device." and two buttons:
  • "Learn more"
  • "OK"

Rationale

• The wording is as short as possible (if it should turn out in user testing that more words are needed, we can still add them)
• This only describes the effect on the user, nothing technical. E.g. users don't know what "verifying the end-to-end encryption" is.

Alternatives

My original proposals:

• In the info message after a verification: "Verified bob@example.com. All messages here are now guaranteed to be end-to-end encrypted. You can be sure that even example.com and <own email server> can't read them."
• In the info message: "Bob's encryption key changed. The security of your end-to-end encryption is not verified anymore". (@link2xt: this sounds like it might also affect previous messages [e.g. all your messages in this chat might be leaked], should be e.g. "The end-to-end encryption of the following messages is not verified").
• In the input-bar-dialog: "Bob's encryption key changed, likely because they reinstalled Delta Chat or changed devices." and two buttons:
  • "Downgrade Encryption" (Alternatives: "Accept Encryption Downgrade" or "Accept") (@link2xt: "Downgrade encryption" sounds like it's permanent, while the encryption will be automatically upgraded as soon as a message signed with a verified key comes in. "Accept" is better.).
  • "Verify" -> Opens the QR code show activity.

What @hpk42, @r10s, @link2xt and me came up with after a long discussion on 2023-05-07:

• In the info message after a verification: "Messages are guaranteed to be end-to-end encrypted from now on. Tap to learn more."
• In the info message: "Messages may not be end-to-end encrypted anymore. Tap to learn more."
• In the input-bar-dialog: "Messages may not be end-to-end encrypted anymore." and two buttons:
  • "Learn more"
  • "Accept"

In the user testings, "Messages may not be end-to-end encrypted anymore" turned out to sound way more dangerous than intended. Also, to one of the users "Accept" sounded as if they are going to actually change something with accepting (and should have the opportunity to not accept), as opposed to just dismissing the dialog.

The "tap to learn more" text when the verification was broken:

End-to-end encryption cannot be guaranteed anymore, likely because Bob reinstalled Delta Chat or sent a message from another device.

You may meet them in person and scan their QR Code again to reestablish guaranteed end-to-end encryption.

There is also going to be a link to the FAQ with even more information.

Concerns

• After the user testings, I believe that the warning message sounds "too scary". Users seem to think that there is no encryption at all anymore.
  • I have the idea of rewording the message to "Your chat partner sent a message from another device. Tap to learn more", because the icon already looks quite scary, so we need a non-scary message. Plus, it was always meant to be more of an info than a warning: 1. This happens all the time 2. There is no point in making it sound scary, because an attacker could circumvent the warning by creating an unverified 2-member-goup.
    • @hpk42 likes the idea, also because it actually tells the user what happened (in almost all cases), and is something users can understand.
    • @link2xt argued that this doesn't really tell what is wrong: The problem is that the chat partner didn't restore a backup / transfer the account. We couldn't come up with a better wording, though. link2xt would still be OK with the reworded text because of the "Tap to learn more".
  • Now that I changed the message to "Bob sent a message from another device. Tap to learn more", a user told me that they don't like that this might be wrong, and it should instead be "Bob likely sent a message…".
    • However, @hpk42 didn't like the idea of adding "likely" there, so let's keep it like this for now and see if this also disturbs other users. -> No other user mentioned this.
• @hpk42: If one of my verified contacts regularly sends me classical emails, maybe to multiple recipients, then this will create quite some visual noise every time.
  • Solution 1: If a contact sends a classical email to a chat that is not the 1:1 chat, then keep the verification (i.e. don't downgrade to unencrypted).
    • Solution 1.1 (@iequidoo): Additionally, if a contact sends a classical email, always create a 2-member ad-hoc group. This means that classical emails can't downgrade verification anymore. (That's similar to Alternative 4, but without the user choice.)
      • Downside: Now, the 1:1 chat may never drop do unencrypted after someone uninstalled DC. -> We'll need some 'manually force unencrypted' option.
  • Solution 2: Reduce visual noise in some way. Disadvantage: This also makes MitM attacks easier.
  • I implemented Solution 1. We'll see whether this is enough in practice.
• @hpk42: A "verified" button in the input-bar-dialog doesn't add much value for the user, since it's really unlikely that the chat partners are currently standing next to each other.
  • Solution 1: When there is a DC message, there could be a notification-style message at the top of the chat that says "XY reinstalled Delta Chat. You can minimize the chances that someone reads your messages by scanning a QR code." with a button "Verify".
  • Solution 2: Instead, put the "Verify" button on the info message (or write "Tap to verify.", and then a tap leads to the QR scan activity).
  • Solved by not putting a "Verify" button onto the input-bar-dialog.

Unresolved questions (in the rough order in which we should resolve them)

I checked all the checkmarks where we have some answer, of course we can still change the answer later.

• After verification was downgraded, should a small crossed-out verification symbol stay permanently (or for some months) in the title bar?
  • Pro: A verification downgrade might mean that there was an active attack, a remnant of this should stay.
  • Contra: The chat is now in exactly the same state as a regular chat. It's difficult to explain the different chat states (unencrypted, opportunistically-encrypted, verified) to a user, anyway, adding one more makes this worse.
  • -> We tend to say no, no permanent crossed-out verification symbol
• Should there be a way to keep the chat "verified" and keep sending to the old key?
  • At least for a keychange, this doesn't make sense, if there is an active attack then they won't let messages to the old key through. For a drop-to-unencrypted, it could make sense, but we can add it later if there is actually a need for it.
• What about unencrypted outgoing messages?
  • Probably we should just show them without any warning.
• Do we want to show a red exclamation mark on messages with the wrong key?
  • Probably not, the info message should be enough (and code-wise it wouldn't be trivial to remove the exclamation mark after the drop-to-unverified was accepted).
• What should happen if a message from another sender is assigned to the verified 1:1 chat "by reply"?
  • Option 1: Just show it inside the verified chat. Pro: It looks quite different from the other messages with the ~ before the name and so on, so it should be clear to the user.
  • Option 2: Just don't assign it to the verified chat, but to the 1:1 chat with the actual sender. Pro: Assigning to a chat "by reply" is meant for other use cases, anyway, and we shouldn't weaken the property that "all the messages in this chat are verified". I implemented this option, look for the comment Just assign the message to the 1:1 chat with the actual sender instead in the code.
• The exact wordings
• Is it clear how to scan the QR code from another device after the verification was dropped? We should user-test this.
• Should the 1:1 chat be downgraded when a message is sent to a group?
  • If the message was sent with a classical MUA: Probably not. There are people using both DC and a classical MUA, and it'd be quite some visual noise to downgrade and upgrade the chat everytime, and the chat would be confusing since when looking at the 1:1 chat, the down- and upgrading would be without any apparent reason (since the messages that caused it are in another chat).
  • If the message was sent with DC: It would make sense to downgrade it, because it's quite unlikely that the chat partner still has the old key. Note that this also applies to verified groups: If the chat partner sent a message with a new key, then it's unlikely that they can still be part of any of the existing verified groups.
  • In the current implementation, it's not downgraded.
• Should 1:1 chats also be marked as verified for bots? And if yes, should the chat also be set to "protection broken" for bots?
  • @link2xt says, 1. maybe (doesn't matter that much), 2. no (would lead to too many bugs). I agree.

Prior art

Signal:

FAQ: https://support.signal.org/hc/en-us/articles/360007060632

WhatsApp:

Threema:

Mastodon:

"Protected chats" (#1968) would have introduced verified 1:1 chats (but they were abandoned deltachat/deltachat-android#2099).

Future

• Update FAQ
• When our chat partner's encryption key changes, all verified groups with them are probably broken. AFAIK, even after a QR code scan, the new peerstate is not gossiped to the chat partners. Should we add a way to remove them from all verified groups?

---

See also:

• List of possible verified chat improvements
• Chromium removes the padlock for https because users don't understand its meaning properly

Implementing this in Core and Android is going to be my Bachelor's project, so, please nobody rush to implement it :)

[iequidoo]

I have a verified contact who sometimes uses another MUA which sends unencrypted unsigned messages. So, just dropping the verification always is not good even with appropriate warnings. But generally people don't use several keys to sign their messages, so i think we can drop the verification on a receipt of a message signed with another key. But if it's not signed at all, it's probably from another MUA and it's me who should decide whether to drop the verification (peer's key) or not. So, in the latter case i'd want to have a capability to "not accept" and continue to use the existing verification.

EDIT: Better no dialogs at all. Just show a warning with a button "Downgrade encryption" and continue to use the existing verification until a user presses the button and enters the confirmation code (to be on the safe side). Intrusive dialogs/confirmations break the usual UX.

EDIT: Smth like "It's not guaranteed that ur messages can be read by the peer anymore. Downgrade encryption?"

EDIT: And also when forwarding messages, there are two buttons now -- CANCEL and OK -- the same message with a button "Downgrade encryption" should be added.

EDIT: Btw, the solution we choose here also may (i think even should) be used for the encryption droppage in unverified groups. I'd prefer that the same warning with button to appear there if we can't encrypt for all peers anymore.

[hpk42]

On Mon, Mar 20, 2023 at 13:45 -0700, iequidoo wrote: I have a verified contact that sometimes uses another MUA which sends unencrypted unsigned messages.

Am skeptical supporting this use case of mixing cleartext and verified 1:1 comms. To begin with, an attacker can just send an unencrypted/unsigned message and you would believe it as legit so the value of the original verification is limited. In the issue summary's suggestion, your 1:1 chat would degrade to opportunistic and i think you should keep it at this -- if there is a real need for verified encryption (say for transfering credentials/logins/other things) then better create a dedicated two-member verified group chat and keep the 1:1 chat just opportunistic. The key thing here is that 1:1 chats will be special wrt verification in that they can downgrade to opportunistically-encrypted. Verified group chats never downgrade.

[iequidoo]

@hpk42, thanks for the explanation, now i got the idea. But then maybe after a contact verification auto-create a verified two-member group and show a message explaining how it's better? Otherwise it will not be clear for users that 1:1 chat can downgrade. It wasn't clear even for me when i tried it the first time :)

EDIT: Maybe not auto-create, but just suggest to create, and if a user presses "Move to the verified chat", create it and focus/select it for further messaging.

EDIT: Considering that verification is a bg process, we can display this "Move to the verified chat?" suggestion message in the 1-1 chat upon the verification completion with two buttons "Move me" and "Dismiss".

[Hocuri]

But then maybe after a contact verification auto-create a verified two-member group and show a message explaining how it's better?

That's Alternative 2 when you click on "Alternatives" in the original message. Downsides:

• 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
• A group has to be called the same for both sides, i.e. if Alice creates a group "Bob verified" with Bob, then it will also be called "Bob verified" on Bob's device. So, the group name has to be "Alice & Bob verified".

Otherwise it will not be clear for users that 1:1 chat can downgrade.

That's why the "proposed solution" above makes it really obvious when the 1:1 chat downgrades

[iequidoo]

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

Then not auto-create a verified 2-member group, but add a good explaining message with two choices: "Move to the verified chat" and "Dismiss". And i think "Alice & Bob" (in ab order) is ok for naming. Maybe even w/o a word "verified" because the verification mark is displayed at the end of chat name (at least on Android).

That's why the "proposed solution" above makes it really obvious when the 1:1 chat downgrades

Yes, making that obvious is the must, but it's too late -- maybe a user would prefer to switch to a verified group in advance if they understand the difference. So, i suggest to show an explanation message after a contact verification. Better with the two choices described above, but even just a message would be good.

[hpk42]

On Tue, Mar 21, 2023 at 10:09 -0700, iequidoo wrote: > 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 Then not auto-create a verified 2-member group, but add a good explaining message with two choices: "Move to the verified chat" and "Dismiss". And i think "Alice & Bob" (in ab order) is ok for naming. Maybe even w/o a word "verified" because the verification mark is displayed at the end of chat name (at least on Android). > That's why the "proposed solution" above makes it really obvious when the 1:1 chat downgrades Yes, making that obvious is the must, but it's too late -- maybe a user would prefer to switch to a verified group in advance if they understand the difference. So, i suggest to show an explanation message after a contact verification. Better with the two choices described above, but even just a message would be good.

Let's see what makes sense text/recommendation wise but up-front choices we generally avoid unless there is an overwhelming need. In the current top issue description interaction/decision from a user is only forced when/after the chat degrades but not for the "happy path": - show/scan qr - get into a chat (with a verified sign which you can ignore) - start chatting It's fine to add an info "this chat is now end-to-end encrypted ..." message a bit like WA does but there shouldn't be a user choice in this "happy path" unless there is an overwhelming need. Later on, we could think about offering something special when the chat degrades but please don't forget that we want to be super-economical about causing extra UI work currently.

[Hocuri]

FTR, I added more info about "After scanning a QR code" to the issue description.

[iequidoo]

Finally i think that just adding an explanation message after a successful verification is ok. Smth like "Now the chat is verified, but it can can downgrade if... If you want a chat that never downgrades, then...". But just in case -- there's also possible an Alternative 4 similar to

Alternative 3 (Protected Chats): Mark 1:1 chats as verified as I propose it here, but change the behavior when an unverified message comes in: Don't show the message content & continue sending messages with the verified key. Ask the user whether to disable verified-ness.

Instead, on a receipt of unverified message we can let a user to make a choice: "Downgrade to non-verified" and "Move new unverified messages to a new chat". Pros:

• No initial explanation message that i requested is needed
• User can postpone their decision on which chat type to use (i think postponing decisions / late forking is often good)

Cons: more work, UI-wise also (an extra button)

[Hocuri]

I'll add this as an alternative, but I'm afraid it's really a lot of work, because currently all the UIs (that is, at least Android, but I assume also the others) rely on the fact that there is only one 1:1 chat. Of course, that's also a downside of the other alternatives that introduce a second chat.

"Now the chat is verified, but it can can downgrade if... If you want a chat that never downgrades, then..."

I'm a bit sceptical because as the text becomes longer, fewer users will read it. We can defer this discussion to after I implemented the UI part, though.

[iequidoo]

I'm afraid it's really a lot of work, because currently all the UIs (that is, at least Android, but I assume also the others) rely on the fact that there is only one 1:1 chat.

We can leave it as is -- if a user chooses "Move new unverified messages to a new chat", we can move new messages to an unverified 2-person group chat and name it using the Subject. Or, if messages have different Subjects, to multiple new chats. This will solve the problem with using another one MUA that doesn't encrypt. Also if we detect that unverified messages are sent using DC (but the peer's key was reset), we can reset the verification in the 1:1 chat. Maybe we even don't need to ask a user for the described choice then -- even if a peer lost access to DC and is now using another MUA, the conversation will be continued in a new unverified group chat.

[Hocuri]

This would actually be one possible solution to hpk's first concern, I'll add this as "Solution 1.1".

[iequidoo]

Solution 1.1 (@iequidoo): Additionally, if a contact sends a classical email, always create a 2-member ad-hoc group. This means that classical emails can't downgrade verification anymore. (That's similar to Alternative 4, but without the user choice.)

Downside: Now, the 1:1 chat may never drop do unencrypted after someone uninstalled DC. -> We'll need some 'manually force unencrypted' option.

I think we/user shouldn't make the decision on our side, the user couldn't know if the contact uninstalled DC or not. Also if we downgrade the chat to unverified, the user will see the full message history while the peer -- only new messages in their non-DC MUA (minor for me, but not sure as for others). And we shouldn't drop the peer's Autocrypt key -- we just shouldn't encrypt in chats where our peer doesn't use it. Looks like it's somewhat a dark area of the Autocrypt standard -- how to deal with multiple MUAs that can be used for communication in different threads for whatever reasons. So, maybe better instead of dropping the verification drop the concept of the special 1:1 chat and make dc_get_chat_id_by_contact_id() return the 2-member group chat where we sent the last message? Then any of such chats is verified if the peer's key is verified and used for signing messages in the chat. And a chat is downgraded to unverified only when the peer's key changes (and a new verification hasn't yet done).

And i'd prefer for messages w/o the Chat-Group-Id header to come different per-thread (per-Subject) group chats.
Sorry for this mindflow, but maybe there are some new ideas :)

[Hocuri]

So, let me put what you said in different words to see if I understood it correctly:

Email doesn't know the concept of "1:1 chats", it just knows threads, where every email that isn't a reply to an existing email starts a new thread. So, you propose to remove the concept of 1:1 chats, and instead whenever someone starts a new email thread, start a new group. The thread subject maps nicely to the group name. If the user clicks on a contact to start a chat, just give them the 2-member group chat where we sent the last message.

Additionally, you propose to make it possible for verified groups to drop to unverified when someone's key changes.

Independently of this, you propose to scope the peerstate encryption-preference per-chat-and-contact instead of per-contact as it's currently done. I.e. if we get a non-autocrypt message in one chat, continue encrypting in other chats.

Did I understand you correctly?

[iequidoo]

... every email that isn't a reply to an existing email starts a new thread

Not sure however that we should create a new 2-member ad-hoc group if there's no InReplyTo, because several groups with the same Subject and peer may be confusing. Maybe just use Subject. And only if there's no Chat-Group-Id.

Additionally, you propose to make it possible for verified groups to drop to unverified when someone's key changes.

Not sure also that we should mix it with the existing "verified groups". Afaiu, in this issue you suggest to just make it possible for 1:1 chats to be "opportunistically verified", but that doesn't make them "verified groups" in the current wording. Instead, i'd suggest to make it possible for the current unverified groups to be "opportunistically verified" and drop 1:1 chats. So, verification can be dropped for such a group if the peer's key has changed to not yet verified.

Independently of this, you propose to scope the peerstate encryption-preference per-chat-and-contact instead of per-contact as it's currently done. I.e. if we get a non-autocrypt message in one chat, continue encrypting in other chats.

Yes, i personally sometimes experience a dropped encryption for some of my contacts sending me unencrypted/unsigned emails from other MUAs. Then the same will be for the verification. Maybe we can step away a little from Autocrypt here.

And i don't suggest to do anything of this in the scope of the current issue -- just evaluate whether any ideas have sense and if yes, prevent implementing anything conflicting.

[Hocuri]

User-Testing Setup

This evolved over time, so, esp. in the first user testings, I didn't follow it yet:

• Make sure my smartphone camera is enabled
• Explain that DC is being tested, not the user
• Explain the scenario: You're an informant for a journalist, expect to have powerful enemies trying to spy on you, a bit anxious
• Ask about computer knowledge
• Tell them to Think Aloud
• Offer to translate English texts to their native language if necessary
• Write down the things the user says
• Ask to scan my QR Code
• Ask: How secure do you think this chat is?
• Write some messages
• Break verification by deleting my account, logging in again, and sending a message (don't say anything)
• Ask: How secure do you think this chat is?
• Ask: What would you do now?

---

User-Testing 1

Person:

• Doesn't know DC, but knows WhatsApp
• Low computer knowledge
• Age: 20-30

Results - with a grain of salt, the setup wasn't good yet:

• BAD: Was confused by the fact that it says 'not [...] encrypted anymore', but there still is a lock on the message
• BAD: Only noticed the ProtectionDisabled message when I asked about it.
• BAD: Directly clicked away the input-bar-dialog without reading it.
• Did notice the lock on the messages

---

User-Testing 2

Person:

• Knows DC
• Low computer knowledge
• Age: 50-60

Results:

• Problems to find how to scan QR code (didn't know that this icon resembles a QR Code; tried to click on the Plus button)
• Had the impression that both of us are new to DC, and we first need to access whether it's a good idea to use DC at all
• Reads the "Messages are guaranteed..." message, but isn't sure whether this it is trustworthy, or whether it might be written by an attacker
• It happened again that the 'Not guaranteed...' message is shown by accident (Edit: I fixed this bug in the meantime)
• BAD: Doesn't understand what 'Accept' means
  • PROPOSES to re-word: 'Accept' -> 'OK' or 'Understood'
• GOOD: Thinks about calling me
• PROPOSES to re-word: 'Scan their QR Code again'
• PROPOSES to mention that they should meet physically
• PROPOSES to re-word: 'If you want' -> 'If security is very important/a priority to you, we recommend'
• GOOD: Thinks that chat isn't secure anymore, we need to do something else

---

User-Testing 3

Person:

• New to DC, but knows Signal
• Age: 20-30
• "Normal" Computer knowledge, knows well how to use computers but no computer science knowledge

Results: Went good in general, but the downgrade message was 'too strong': "It's not e2e-encrypted anymore, and I need to meet them in person? But why can Signal do e2ee w/o meeting in person?"

Onboarding: Works fine, no problems

• Verification broken
• Clicks "More Info"
• "Is it only end-to-end encrypted when we're both online?" (strongly because of the design of the user test)
• "I'm confused: So, now it's not end-to-end encrypted anymore? And why?"
• "End-to-end encryption only works as long as my device is secure?"
• GOOD: If it's important that it's end-to-end encrypted, meet me
• BAD: Would think that it's not e2ee anymore; Doesn't feel secure anymore at all

---

I changed the "More info" alert dialog from Sometime in the past, you verified the security of your end-to-end encryption via a QR code scan. Therefore, the chat was secure even against an attacker who controls your e-mail server and manipulates messages to break the encryption.\n\nNow, %1$s probably reinstalled Delta Chat or sent a message from another device, so the encryption is not verified anymore. If you want, you can scan their QR code to restore the verification. to Can\'t guarantee end-to-end encryption anymore, likely because %1$s reinstalled Delta Chat or sent a message from another device.\n\nIf security is a priority for you, meet them in person and scan their QR code again to restore the verification.

---

User-Testing 4

Person:

• Almost new to DC, knows WhatsApp
• Age: 15-20
• "Normal" Computer knowledge, knows well how to use computers but no computer science knowledge

Results:

• "Why did the "Verified" only come now?" (the internet was bad, so it took a while, after we already wrote back & forth 2 messages)
• BAD: "Does 'verified' just mean that it's really you? Because for others, it's that it's a celebrity or a moderator or so"
• "So, before they weren't end-to-end encrypted?"
• Verification broken
• GOOD: "Clicks on 'More Info'
• GOOD: Now I'd definitely not write you anymore if I was a dude that's anxious
• BAD: "Gives me the vibe of everything being completely unsafe now"
• BAD: Finds the "Changed setup for hoc@testrun.org" message confusing (Context: When verification is broken, this is a second device message that appears in the chat, that existed for years in DC now - mabye we should remove it)
• BAD: "So, it's crossed out now. Is it because you aren't verified anymore or because it's not e2ee anymore?
• "Does the "Verified" mean that the app can't guarantee anymore that I'm really writing with you? Or what does it mean?"
• PROPOSES: Says that he would prefer a shield instead of the "twittery" verified symbol
• GOOD: Wants to meet me in reallife and scan the QR code again
  • This didn't work in the test, probably because of bad wi-fi, but I need to check if there is a bug

[Hocuri]

We did it!!!!! That was quite an effort, but verified 1:1 chats are finally release-ready, even though they aren't even called "Verified 1:1 Chats" in the UI anymore! I can still remember the day last winter/spring when @hpk42 and me stood in BB and talked about what my Bachelor Project could be and what we should propose to OTF, and decided for verified 1:1 chats. I already delivered what we had in Juli as my Bachelor Project Now, and afterwards went on my trip to Norway, and others jumped in. Now, after hundreds of hours of discussions, after multiple changes in how we call it in the UI, after many user testings, after looots of bugs, we're on the final meters to releasing it. I added the last open point to the end of https://gist.github.com/Hocuri/29839ad9c205a3fb89bf525dd1574e06 (because it's actually about verified chats in general, not verified 1:1 chats), and we don't need this issue anymore.

Thanks @hpk42 for leading and coordinating with me, thanks @link2xt for tireless fixing of bugs that crept up on the last meters, thanks everyone involved for the constructive discussions, and thanks everyone involved for completing this together!

[Septias]

Congratulations on this huge milestone @Hocuri

[r10s]

yeah, congrats! 🥳🍾

i was just skimming over https://gist.github.com/Hocuri/29839ad9c205a3fb89bf525dd1574e06 again - and, indeed, what a history, i mean the posts from 2020 were not even the first ones :)