I joined a group chat via somebody’s invite link, but I got this invite link through an extremely insecure connection. Now this person and everybody they know shows up as verified. But the link could have been tampered with in infinite ways or have come from anybody impersonating the person I merely hoped it is, and I wouldn’t know. Therefore I’m quite unsure what the “verified” could even possibly mean or guarantee in that situation.
My apologies if I’m just missing something, but there seems to be the assumption that if I got the link somehow that it was through a verified channel. Maybe one way to solve that would be after clicking or entering the link, Delta Chat could ask me if I got the link through an encrypted and verified source and I want to trust it. Sorry if I’m just being confused about this one and missing something.
I think it’s best to have different profiles for different areas of your life.
For example, one profile for friends, family and people you trust the most, one for colleagues and another as a “public” profile for public groups. DC has a good profile switcher that makes it very easy to switch between these profiles. You can also create new chatmail accounts very quickly and anonymously.
The invite links are simply used to establish an encrypted chat.
If you want maximum security, you have to meet your contacts in person to scan the QR codes. This is the only way you can be sure that the right person is behind a name. Everything else is inevitably less secure. But even then, you can never be 100% sure that someone else might have access to your contact’s device. This is the case with every messenger.
Thanks for your input, you seem to be possibly agreeing with my assessment then. Sadly, Delta Chat the app doesn’t seem to. That is why I hope there can be a user prompt about a link’s trust to handle this, rather than the app treating it as maximum trusted always.
Would it help if I suggested a UI design? Last time the devs seemed to hate my concrete UI suggestion though, which was fair in retrospect so perhaps somebody already has a cool idea that would beat mine on how to solve asking the user about how much a link should be trusted.
I realized this invite link issue is bigger than I thought, and also goes both ways:
If I make an invite QR code for a random public chat group for e.g. tech chatting, where I have no idea who’ll scan, I don’t want them verified since I don’t know them.
If somebody scans my invite QR code for a random public chat group on some random website, they don’t want me to be marked verified either.
No-trust QR codes seem vital for public groups. These codes should still establish e2ee so chatmail user can join, but without the visual trust mark.
I was asked to put some ideas here. My current ideas for this were:
QR codes could have a new setting whether I trust who scans it, if disabled then neither I nor the other person should get the Verified checkmark when scanning it. It could be placed inside the QR code scan box at the top, and default to enabled:
Groups could then have a setting whether they’re public and for strangers, in which case such “no trust” codes become available for this group. This would perhaps best default to off. The setting could be put here, either that button or right next to it:
For private groups, the above QR code setting should then perhaps either not appear, or be forced to on. For public groups, it should appear and default to off. And for personal codes, as suggested above, it should default to on but remain toggleable.
This is merely a random idea of mine of how to make it work. I’m sure others have improvement suggestions.
I generally agree, however the absence of any visual mark makes it harder for users to identify when chats are encrypted or not, and what type of encryption is being used. There should be some way to clearly distinguish between the different setups:
No encryption
Encrypted but without guaranteed E2EE
Guaranteed E2EE but unverified identity
Guaranteed E2EE and verified identity
Traditional PGP/GPG software typically issues a warning if the contact’s identity hasn’t been verified, though it still handles the encryption and signature verification fine. It would be good to translate those same ideas into easily understandable terms and an intuitive visual language for Delta Chat.
For example, in the context of a different (but related) discussion, I suggested using gray checkmarks for unverified contacts as opposed to green checkmarks. Admittedly this isn’t the best solution, since it could disadvantage people with color blindness, though I see it as a step in the right direction.
If you wanted to differentiate unverified PGP, a simple lock icon might work. However, I would consider it acceptable if unverified PGP looked the same as no PGP. For public strangers chat groups, I don’t think it makes a huge difference either way.
In addition to public chat groups, there are also contacts established via mutual contacts to consider, whose identity isn’t personally verified. Currently these contacts also show up without the “verified” symbol, though there could be value in visually indicating the E2EE status.
I think the suggestions @ell1e made above look good, though with regard to word choice, I am not sure that all users will understand that “I trust this person” means “I have verified this person’s identity”.
One way to make the current QR code system more powerful and more flexible would be to allow the creation of multiple QR codes which are simultaneously valid, and allow the user to asign each outstanding QR code:
a “trust level” (identity verified or not)
an optional personal annotation
an optional expiry time
an optional maximum number of uses/scans allowed
This would allow users to asign a “trust level” to each QR code. For example, a user could post a “no trust” QR code in a public place (such as on a personal website) and at the same time let contacts they meet in person to scan a “trusted” QR code.
Another use case would be if a user meets multiple people at an event such as a party, business meeting, etc. but doesn’t have an internet connection at the time. The user could generate a separate QR code for each contact, noting the contact’s name in the “annotation” field and setting “maximum number of uses/scans” to one. When the user later connects to the internet, Delta Chat could display the information in the “annotation” field for each new contact. This system promotes greater confidence in identity verification, helps to avoid potentially confusing different contacts, and reduces the risk of impersonation.
Obviously this system would necessitate a “QR code manager” to generate and keep track of outstanding QR codes, it would involve additional complexity, and it would require significant developer effort to implement, so it probably wouldn’t be a top priority, but I think there are many advantages to such a system in regard to identity verification and I would welcome people’s feedback on this idea.
The previously used cog wheel might work for such advanced settings. Such that normal users aren’t confronted with them, other than the basic trust one that is probably vital enough.
I think this screenshot is a great illustration how the current trust design seems to downgrade strong end-to-end-encryption to basically plain old TLS. Or how would I know that the mail provider of that person hasn’t simply intercepted everything, signed it with DKIM and replaced the PGP key, and is impersonating them now? Sorry if I’m missing something.
A fix might be a “strong encryption” lock vs a true “I fully verified this person” checkmark that I control. I should be able to downgrade a “fully verified” to a “strong encryption”.
And what do you think about creating an account just to share publicly a qrcode but when people add you, then share your other official account with them in a private chat directly on deltachat?
This way, anyone can contact you, but only you can decide with who you want to share your official account with.
sometimes you can also delete that unofficial account because it is only used to get in touch.
I don’t think introducing “trust levels” is a good solution to the problem.
This implies that third-party introduction is worth nothing
and at some point you have ultimate verification of the contact
because you met in person and verified the contact identity,
like in the PGP key signing parties
where everyone is supposed to bring two government-issued IDs.
Signal has this kind of binary verification where contact is either
verified or not, but this does not solve the problem of contacts
changing their non-cryptographic identity (name and avatar) later
either because they actually changed their name
or because they want to impersonate someone.
You may later end up in a group chat with
such contact that changed their identity after verification
and need to decide which information you trust the chat participants with.
Signal attempts to solve this by showing you warnings
about someone having similar name as someone in your contact list
or multiple group members having similar names in the group.
It does not compare avatars and it is not clear what
the user is supposed to do when presented with this warning.
If one of your contact changes the name,
all other contacts are free to take their old name
without this change resulting in a warning.
The user has already “fully verified” both contacts
and has “strong encryption”, but apparently it is not enough.
When you go to a contact profile to see
if you want to trust this contact with some information,
what matters is not the “Verified” checkmark,
but if it’s actually the correct contact.
You can determine this by your chat history,
by this contact being in other groups
related to some events and places etc.
Sometimes someone being introduced
into multiple groups by your existing contacts
is a better proof than someone approaching
you on a conference, claiming to be someone
and scanning a QR code.
Signal will mark such contact as “Verified”,
but you still may not know who they are.
Instead of dismissing the introduction by InviteBot
and waiting for some final full verification,
we could show a history of
“this contact was introduced by InviteBot in this group on 2025-01-01,
and by Alice in the “Fediverse” group on 2025-01-10,
and scanned your QR code labeled #fosdem on 2025-02-02” etc.
This was also discussed here:
My apologies, but I believe this downgrades E2EE to TLS due to e.g. a malicious mail server issuing QR codes MITM, like I wrote above. That seems severe enough for a custom marker.
I don’t even see any mention of the server in this thread before this message. And if you are scanning a QR code issued by the server, it can MITM you in any case.
so perhaps somebody already has a cool idea that would beat mine on how to solve asking the user about how much a link should be trusted.
