Secure Invite Links by default

Feature Proposal
1

Could we crack down on ensuring that its easy to keep invite links secure?

Currently:

  • Easiest way to add somebody is via invite link to their profile
  • Unless you manually reset the QR code, no real way to differentiate people. Especially because we just trust their name as declared

Safer:

  • Generate invite link per contact. When creating the link, user should specify name.

This is something that SMS actually gets pretty corrrect. Incoming messages have opaque number until user decides on name. Sender shouldn’t get to choose their name.

1 Like
2

After convrsation is established via invite link ot othervise, you can change contact’s name in your DC app; it will be visible only for you.

3

Didn’t know that, thanks for the info! That is a good feature, but any optional step is going to be skipped 99% of the time.

Whereas introducing a 5-second required step gets you “why does Bob say he is Alice” alarm bells, which are potentially quite important.

4

This I can’t understand. Can you explain your idea in another words?

5

When somebody consumes my invite link and starts messaging me, I would like their name to be the name I assigned them when I created the invite. Especially if I sent the invites to multiple people and they consumed them over a few days.

RE: "why does Bob say he is Alice”

This means that if I see my chat with “Bob” has the first message saying “Hi its Alice”, I get suspicious. The problem with current behaviour is that anybody I send invite to can choose any name they want.

Its less of a customization thing and more of a preferred secure default so that one can recommend the software to others out of the box.

6

I agree that the invite links can be made more secure. There is also discussion about this in this thread:

I made some suggestions here that address your concerns and @link2xt described here generating unique QR codes that let you add a “context” which would solve the problem you described:

I think this would be a good feature for Delta Chat to have.

Not really. If you give somebody your number and they send you an SMS later, then you arrive at the same situation where you can’t be sure it’s from the same person just because there is an “opaque number”, unless you already know that person’s number in advance. And you really shouldn’t trust the sender’s number anyway because SMS spoofing lets anyone trivially change the “opaque number” to anything they want. SMS is not a good example of security in this context or any other context I can think of.

For what it’s worth, a Delta Chat account is linked to an email address and an identity key. The app normally hides these details from users for reasons but you can still view a contact’s email address and fingerprint if you want to, and I think the app warns you if a contact’s email address or fingerprint changes, but you would need to ask the experts about this.

The problem is not that anybody can choose whichever name they want, but the limitation of only being able to use one QR code/invite link at a time and not having a way to add a “context” to a QR code/invite link.

An alternative approach to address the problem you described would be if both contacts scan each other’s QR code, instead of just one person scanning the other’s QR code, although the developers don’t favor this approach.

1 Like
7

An alternative approach to address the problem you described would be if both contacts scan each other’s QR code, instead of just one person scanning the other’s QR code, although the developers don’t favor this approach.

I think this is a great solution for desktop “lets both send each other a link” scenario. But for in-person a simpler solution might be to just have the QR code only be valid while ur showing it to peer (as double QR scanning seems a bit annoying, and u have the benefit of being able to just enforce super short timespan anyways)

8

Mobile network coverage is far from 100%.
And there are other factors.
User should have the ability to save QR invite and use it anytime later.

9

In-person phones don’t actually need the mobile network to swap contacts. I’ve successfully exchanged contacts over the LAN on a Pinephone with Bluetooth off and the cell modem airgapped.

A single-use or expiring QR code would be useful, but QR codes that last forever are also useful. Perhaps, instead of rendering QR codes unusable, we should just default to non-reuse, and warn of reuse.

For in-person scans, perhaps the QR code could be single-use by default: that is, once an in-person contact is established, that QR code is not displayed again, and it is recorded against the contact. If someone is later introduced to you by that contact, the UI can say whom they’re being introduced by.

When you make a QR code, the UI could ask you to either make a single-use code to scan right now, or to name the code to make it persistent (example names: “QR for Alice” or “Bob’s 2025 keysigning party”). Then you see the QR name when deciding whether to accept the contact.

As @bencan says, this very much ties in to @ell1e’s Trust design: perhaps an invite link shouldn't always be trusted (maybe it's a good idea to ask the user?).

10

I like that. I’d like to propose to expand it:

  1. “Secure single-use code for instant use”. Should expire in under an hour, and users who are connect this way are marked verified.

  2. “Lenient multi-use code”. Shouldn’t expire unless revoked, can be named, and users connected this way will not be marked verified.

This would mirror the common uses and add in my trust model idea.

11

I like that model. For the multi-use code, one might also want a slight guard against a huge message request influx in case of leak. At least some sort of easy way to say “clear all message requests”. Which preferably are sectioned off UX-wise anyhow.

Also on this topic – open invite chats should probably block media etc. until user upgrades it.

1 Like
12

I like these ideas. If multiuse codes MUST be named, a menu of named codes could allow requests using a code to be silently blocked (if the code has been deleted) or bounced with a message.

Single-use codes could expire when used or 30 minutes from creation, whichever comes first.

Are you suggesting media blocks to avoid Rickrolling and the like? If so, initially putting the media behind a “Alice has sent a jpg, [see media from Alice]” would work.

1 Like
13

Are you suggesting media blocks to avoid Rickrolling and the like? If so, initially putting the media behind a “Alice has sent a jpg, [see media from Alice]” would work.

yeah that’d be good. The real motive is to block really bad / illegal stuff. But yeah rickrolling is a less disturbing variant to think about that has pretty much the same semantics.

1 Like
14

Yeah, if Deltachat is used for large group chats, the moderation tools generally needed for large group chats will be needed (most of them offtopic here). In a large enough group, some people will behave badly.

1 Like
15

There are already setting in ‘Chat and Media’, setting limit on auto-downloadin messages by size. Maybe it’s enough?

How do you want DC app to decide what is really bad, and what is just illegal? B-)

16

Totally agree. Network coverage is not perfect, and also not everybody has mobile data 100% of the time, if you design an app based on the assumption users have constant internet access, you’re creating an app only for a privileged class of users.

I’ve also onboarded contacts who saved my QR invite before they even downloaded Delta Chat, who preferred to download apps on an unmetered connection or research the app before downloading it, sometimes they didn’t connect until many days later.

Therefore I oppose enforcing super short time spans for single use invite links. If you can add a context to invite links so that you can see who scanned the code and when, then you can anyway decide yourself if you think the connection can be trusted and you can always expire the QR invite manually if you want.

2 Likes
17

(1) IMHO when creating QR in app, user should have options like ‘expire in 2 hours, more secure’ and ‘expire in a year, less secure’ options.
There should be string ‘issued for …’, and (?)-like link to the short tip explaining why one needs to fill this ‘issued for’ field.

(2) In advanced settings there should be a possibility to change default short time and long time validity periods.

(3) And there should be a table somewhere (in very advanced settings) with all the issued QRs, issue time, were they properly ‘consumed’ or not, adjustable expiry time, etc.

For more compact UI, options from (2) may be accessible for modification as ‘default’ rows in table from (3).

18

Physical presence of the two mobiles is needed to scan QR codes, and mobile network presence is not. Defaulting to single-use and a short expiry time makes sense, but I agree these limits should be obvious and easy to change in the UI.

19

This is similar to the idea I described here

That’s correct, but that’s more of an argument against short expiry times, not the opposite!

I think defaulting to short expiry times could potentially cause more unintended problems than it would solve (“why didn’t you ever write to me? - I tried to as soon as I had time but your QR code was broken!”)

1 Like
20

QR codes that expire should say exactly when they expire in a caption (with an adjacent “extend” option). Possible problems with incorrect system clocks.

I think ceasing to record consumed or expired QR codes would be reasonable.

And, again, having labels like “QR for Alice” “Bob’s 2025 keysigning party” would to a great extent provide single-use and expiry-like functionality.