🆕 Software Suggestion | Delta Chat #859

New Issue

jonah · 2019-04-13T00:20:12Z

lupine commented

2019-04-13 00:20:12 +00:00

(Migrated from github.com)

Basic Information

Name: Delta Chat
Category: IM / Instant Messaging
URL: https://delta.chat

Description

It's instant messaging, but using SMTP to send messages, IMAP to read them, and Autocrypt to encrypt them. Mature desktop and android clients exist; there is an experimental iOS client.

Privacy characteristics depend on the mail provider more so than delta; it can be used with an existing gmail/etc account (worst, most convenient), or you can run your own email infrastructure (best, least convenient).

I'm not a member of the project, but am involved in building a libpurple plugin for delta, to bring it to pidgin, finch, librem, etc.

From the website:

Delta Chat is like Telegram or Whatsapp but without the tracking or central control.

Delta Chat doesn’t have their own servers but uses the most massive and diverse open messaging system ever: the existing e-mail server network.

Chat with anyone if you know their e-mail address, no need for them to install DeltaChat! All you need is a standard e-mail account.

## Basic Information **Name:** Delta Chat **Category:** IM / Instant Messaging **URL:** https://delta.chat ## Description It's instant messaging, but using SMTP to send messages, IMAP to read them, and Autocrypt to encrypt them. Mature desktop and android clients exist; there is an experimental iOS client. Privacy characteristics depend on the mail provider more so than delta; it can be used with an existing gmail/etc account (worst, most convenient), or you can run your own email infrastructure (best, least convenient). I'm not a member of the project, but am involved in building a libpurple plugin for delta, to bring it to pidgin, finch, librem, etc. ### From the website: Delta Chat is like Telegram or Whatsapp but without the tracking or central control. Delta Chat doesn’t have their own servers but uses the most massive and diverse open messaging system ever: the existing e-mail server network. Chat with anyone if you know their e-mail address, no need for them to install DeltaChat! All you need is a standard e-mail account.

👍 4 ❤️ 3

jonah commented

2019-04-13 00:51:11 +00:00

How does encryption work if they don’t also have the client? Does it just not? Or does it use something standard like GPG?

lupine commented

2019-04-13 10:50:32 +00:00

(Migrated from github.com)

@JonahAragon autocrypt is based on GPG, plus a negotiation layer: https://autocrypt.org/

It's opportunistic encryption, more or less. When you send an IM to someone new through delta, it goes out as an unencrypted email with a header that says "I support autocrypt and this is my public key". Replies can then be encrypted (and have a header that says "and this is my public key for further chat).

Some non-delta clients are growing support for autocrypt too, and if they share keys with delta, that allows you to read your encrypted messages in (say) your standard email client too, and make encrypted replies that delta can understand.

Transport encryption depends on the mail servers, since you're doing SMTP+ IMAP. The state of that is a lot better than it was, but still quite variable, of course.

The absolute security definitely suffers for convenience - if you're sending IMs to someone who doesn't have an autocrypt client, they appear as a series of perfectly readable, unencrypted emails, and their replies will also be unencrypted. It does provide a neat way for you to progressively move your friends over to delta, though - if they complain about lots of itty bitty emails, you say "just install delta then". Very good success in my experience ^^

@JonahAragon autocrypt is based on GPG, plus a negotiation layer: https://autocrypt.org/ It's opportunistic encryption, more or less. When you send an IM to someone new through delta, it goes out as an unencrypted email with a header that says "I support autocrypt and this is my public key". Replies can then be encrypted (and have a header that says "and this is *my* public key for further chat). Some non-delta clients are growing support for autocrypt too, and if they share keys with delta, that allows you to read your encrypted messages in (say) your standard email client too, and make encrypted replies that delta can understand. Transport encryption depends on the mail servers, since you're doing SMTP+ IMAP. The state of that is a lot better than it was, but still quite variable, of course. The absolute security definitely suffers for convenience - if you're sending IMs to someone who doesn't have an autocrypt client, they appear as a series of perfectly readable, unencrypted emails, and their replies will also be unencrypted. It does provide a neat way for you to progressively move your friends over to delta, though - if they complain about lots of itty bitty emails, you say "just install delta then". Very good success in my experience ^^

jonah commented

2019-04-14 03:45:12 +00:00

My main concern was vendor lock-in more than absolute security. Can it be read in any other client that supports GPG, say Thunderbird with the same private key imported that Delta is using? If you’re able to leave Delta easily if necessary and switch to just GPG or something like that I’d be fine with it.

lupine commented

2019-04-14 11:03:00 +00:00

(Migrated from github.com)

@JonahAragon you can, yes. Under the hood, autocrypt is just exchanging regular GPG keys. You can extract them from delta and use them to decrypt existing messages if you want to.

👍 2

blacklight447 commented

2019-05-06 17:20:13 +00:00

(Migrated from github.com)

How is on the metadata side?

ghost commented

2019-06-11 16:34:37 +00:00

(Migrated from github.com)

How is on the metadata side?

The same as email. :) they are actually emails.

Delta Chat doesn’t have their own servers but uses the most massive and diverse open messaging system ever: the existing e-mail server network.

The thing I don't like about this program though is you give up PFS as you cannot have ephemeral key exchanges.

PGP isn't really great for instant messaging when we have better things like double-ratchet and OMEMO, otr4.

> How is on the metadata side? The same as email. :) they are actually emails. > Delta Chat doesn’t have their own servers but uses the most massive and diverse open messaging system ever: the existing e-mail server network. The thing I don't like about this program though is you give up [PFS](https://en.wikipedia.org/wiki/Perfect_forward_secrecy) as you cannot have [ephemeral key exchanges](https://en.wikipedia.org/wiki/Diffie_hellman). [PGP](https://en.wikipedia.org/wiki/Pretty_Good_Privacy) isn't really great for instant messaging when we have better things like [double-ratchet](https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm) and [OMEMO](https://en.wikipedia.org/wiki/OMEMO), [otr4](https://en.wikipedia.org/wiki/Off-the-Record_Messaging).

Mikaela commented

2019-06-12 12:03:18 +00:00

(Migrated from github.com)

I thought we had an issue about it already or discussed about it somewhere and had conclusion to not do it, because of the issues inherent to email and lack of E2EE unless your contact happens to be using specific email client (or also Delta chat)?

blacklight447 commented

2019-08-09 17:48:32 +00:00

(Migrated from github.com)

Considering the amount of metadata email leaks, the lack of PFS , I would not include delta chat myself, and if i would, it would be a worth mentioning at most. unless anyone has something else to bring in, this issue will now be closed.

hpk42 commented

2020-02-18 16:25:26 +00:00

(Migrated from github.com)

@blacklight447-ptio @Mikaela @tya99 Why does Delta Chat not fit next to Matrix in the privacytools real-time federated section? Matrix servers see the metadata of who communicates with whom, mail servers are not worse, are they? Also Delta Chat has e2e by default and offers "verified groups" which are safe against active attacks and easy to handle for users, see here for some more info: https://delta.chat/en/help#which-standards-are-used-for-end-to-end-encryption -- FWIW Delta Chat developers have good relations with Matrix folks, and we are sympathetic to each other efforts.

@JonahAragon @lupine please note that GPG is a command line tool and typically linked to using keyservers, uploading your social graph, and complicated, rightfully complained about, key management UX. By contrast, PGP is an IETF standard that does not mandate using keyservers and in fact https://autocrypt.org does not use keyservers at all, and takes a UX-driven approach. There are a growing number of Autocrypt-enabled mail clients, all of which Delta Chat is interoperable with.

@blacklight447-ptio @Mikaela @tya99 Why does Delta Chat not fit next to Matrix in the [privacytools real-time federated section](https://www.privacytools.io/software/real-time-communication/#federated)? Matrix servers see the metadata of who communicates with whom, mail servers are not worse, are they? Also Delta Chat has e2e by default and offers "verified groups" which are safe against active attacks and easy to handle for users, see here for some more info: https://delta.chat/en/help#which-standards-are-used-for-end-to-end-encryption -- FWIW Delta Chat developers have good relations with Matrix folks, and we are sympathetic to each other efforts. @JonahAragon @lupine please note that GPG is a command line tool and typically linked to using keyservers, uploading your social graph, and complicated, rightfully complained about, key management UX. By contrast, PGP is an IETF standard that does not mandate using keyservers and in fact https://autocrypt.org does not use keyservers at all, and takes a UX-driven approach. There are a growing number of [Autocrypt-enabled mail clients](https://autocrypt.org/dev-status.html), all of which Delta Chat is interoperable with.

👍 2

r10s commented

2020-02-18 18:33:45 +00:00

(Migrated from github.com)

wrt leaking metadata, i think, the information one has about email are sometimes a bit outdated. eg. with new methods as https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ (formerly memoryhole), that are supported by Delta Chat, the amount of metadata are more comparable with other tools.

moreover, email addresses are much easier to get and leak much less privacy information as needed to get eg. an Signal account that, due to the phone-number, is bound to real-life identity in most countries. but, of course, this is known by privacytoolsIO - just saying because eg. Signal is a recommendation (or at least mentioned :)

also, there are thunderbird, k-9 and others in the privacytoolsIO-database - i do not see why Delta Chat cannot be accepted then (in whatever category :)

wrt leaking metadata, i think, the information one has about email are sometimes a bit outdated. eg. with new methods as https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ (formerly memoryhole), that are supported by Delta Chat, the amount of metadata are more comparable with other tools. moreover, email addresses are much easier to get and leak much less privacy information as needed to get eg. an Signal account that, due to the phone-number, is bound to real-life identity in most countries. but, of course, this is known by privacytoolsIO - just saying because eg. Signal is a recommendation (or at least mentioned :) also, there are thunderbird, k-9 and others in the privacytoolsIO-database - i do not see why Delta Chat cannot be accepted then (in whatever category :)

👍 1

dngray commented

2020-02-24 12:32:36 +00:00

(Migrated from github.com)

@blacklight447-ptio @Mikaela @tya99 Why does Delta Chat not fit next to Matrix in the privacytools real-time federated section? Matrix servers see the metadata of who communicates with whom, mail servers are not worse, are they? Also Delta Chat has e2e by default and offers "verified groups" which are safe against active attacks and easy to handle for users, see here for some more info: https://delta.chat/en/help#which-standards-are-used-for-end-to-end-encryption -- FWIW Delta Chat developers have good relations with Matrix folks, and we are sympathetic to each other efforts.

The main criticism I have of Delta Chat being added is the fact that PGP cryptography doesn't have forward secrecy. If users are not using U2F there's quite a high danger that their private keys could be stolen resulting in the catastrophic decryption of all prior messages.

With email you don't have much choice because a message is usually being sent from the cold without any kind of prior negotiation. We do have an email section, and encourage people to use PGP, for compatible inter-provider email communications. We also recognize email is often necessary for initial communication.

However, we encourage people to use proven forward secrecy cryptography such as the Double Ratchet or OTR for long term communication.

@JonahAragon @lupine please note that GPG is a command line tool and typically linked to using keyservers, uploading your social graph, and complicated, rightfully complained about, key management UX. By contrast, PGP is an IETF standard that does not mandate using keyservers and in fact https://autocrypt.org does not use keyservers at all, and takes a UX-driven approach. There are a growing number of Autocrypt-enabled mail clients, all of which Delta Chat is interoperable with.

Yes we are aware of the various methods of key distribution, WKD, Autocrypt, OPENPGPKEY etc.

That email clients page is going to be redone soon as a part of https://github.com/privacytoolsIO/privacytools.io/issues/1707. We aim to make a criteria there and really only recommend modern and mature email clients. The page will later get an update when Thunderbird 78 is released.

wrt leaking metadata, i think, the information one has about email are sometimes a bit outdated. eg. with new methods as https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ (formerly memoryhole), that are supported by Delta Chat, the amount of metadata are more comparable with other tools.

I am really glad to see Protected Headers for Cryptographic E-mail, but I don't think it makes the case any better for Delta Chat.

Additionally if you look at the spec there, it only protects the subject:

This document only explicitly contemplates confidentiality protection
for the Subject header, but not for other headers which may leak
associational metadata. For example, "From" and "To" and "Cc" and
"Reply-To" and "Date" and "Message-Id" and "References" and "In-
Reply-To" are not explicitly necessary for messages in transit, since
the SMTP envelope carries all necessary routing information, but an
encrypted [RFC5322] message as described in this document will
contain all this associational metadata in the clear.

moreover, email addresses are much easier to get and leak much less privacy information as needed to get eg. an Signal account that, due to the phone-number, is bound to real-life identity in most countries. but, of course, this is known by privacytoolsIO - just saying because eg. Signal is a recommendation (or at least mentioned :)

Signal is a recommendation and it is quite good at keeping metadata secret. However we don't encourage anyone to use it with parties that they are not comfortable sharing a phone number with. Signal was never designed to be used random people on the internet, in the say way that Matrix or IRC might be.

I would say users would be better off using Matrix if they are concerned about sharing their phone number, or a P2P instant messenger if they are paranoid about metadata such as (who is talking to whom).

also, there are thunderbird, k-9 and others in the privacytoolsIO-database - i do not see why Delta Chat cannot be accepted then (in whatever category :)

Those are email clients. Delta Chat is a chat program. To participate in Delta Chat conversations, you do require that software, to do so efficiently.

> @blacklight447-ptio @Mikaela @tya99 Why does Delta Chat not fit next to Matrix in the [privacytools real-time federated section](https://www.privacytools.io/software/real-time-communication/#federated)? Matrix servers see the metadata of who communicates with whom, mail servers are not worse, are they? Also Delta Chat has e2e by default and offers "verified groups" which are safe against active attacks and easy to handle for users, see here for some more info: https://delta.chat/en/help#which-standards-are-used-for-end-to-end-encryption -- FWIW Delta Chat developers have good relations with Matrix folks, and we are sympathetic to each other efforts. The main criticism I have of Delta Chat being added is the fact that PGP cryptography doesn't have [forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy). If users are not using [U2F](https://en.wikipedia.org/wiki/Universal_2nd_Factor) there's quite a high danger that their private keys could be stolen resulting in the catastrophic decryption of all prior messages. With email you don't have much choice because a message is usually being sent from the cold without any kind of prior negotiation. We do have an email section, and encourage people to use PGP, for compatible inter-provider email communications. We also recognize email is often necessary for initial communication. However, we encourage people to use proven forward secrecy cryptography such as the [Double Ratchet](https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm) or [OTR](https://en.wikipedia.org/wiki/Off-the-Record_Messaging) for long term communication. > @JonahAragon @lupine please note that GPG is a command line tool and typically linked to using keyservers, uploading your social graph, and complicated, rightfully complained about, key management UX. By contrast, PGP is an IETF standard that does not mandate using keyservers and in fact https://autocrypt.org does not use keyservers at all, and takes a UX-driven approach. There are a growing number of [Autocrypt-enabled mail clients](https://autocrypt.org/dev-status.html), all of which Delta Chat is interoperable with. Yes we are aware of the various methods of key distribution, [WKD](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service), [Autocrypt](https://autocrypt.org/), [OPENPGPKEY](https://datatracker.ietf.org/doc/rfc7929/) etc. That [email clients](https://www.privacytools.io/software/email/) page is going to be redone soon as a part of https://github.com/privacytoolsIO/privacytools.io/issues/1707. We aim to make a criteria there and really only recommend modern and mature email clients. The page will later get an update when [Thunderbird 78 is released](https://developer.thunderbird.net/planning/roadmap). > wrt leaking metadata, i think, the information one has about email are sometimes a bit outdated. eg. with new methods as https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/ (formerly memoryhole), that are supported by Delta Chat, the amount of metadata are more comparable with other tools. I am really glad to see [Protected Headers for Cryptographic E-mail](https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/), but I don't think it makes the case any better for Delta Chat. Additionally if you look at the spec there, it only protects the subject: > This document only explicitly contemplates confidentiality protection > for the Subject header, but not for other headers which may leak > associational metadata. For example, "From" and "To" and "Cc" and > "Reply-To" and "Date" and "Message-Id" and "References" and "In- > Reply-To" are not explicitly necessary for messages in transit, since > the SMTP envelope carries all necessary routing information, but an > encrypted [RFC5322] message as described in this document will > contain all this associational metadata in the clear. > moreover, email addresses are much easier to get and leak much less privacy information as needed to get eg. an Signal account that, due to the phone-number, is bound to real-life identity in most countries. but, of course, this is known by privacytoolsIO - just saying because eg. Signal is a recommendation (or at least mentioned :) Signal is a recommendation and it is quite good at keeping metadata secret. However we don't encourage anyone to use it with parties that they are not comfortable sharing a phone number with. Signal was never designed to be used random people on the internet, in the say way that Matrix or IRC might be. I would say users would be better off using Matrix if they are concerned about sharing their phone number, or a P2P instant messenger if they are paranoid about metadata such as (who is talking to whom). > also, there are thunderbird, k-9 and others in the privacytoolsIO-database - i do not see why Delta Chat cannot be accepted then (in whatever category :) Those are email clients. Delta Chat is a chat program. To participate in Delta Chat conversations, you do require that software, to do so efficiently.

r10s commented

2020-02-24 12:59:09 +00:00

(Migrated from github.com)

Signal is a recommendation and it is quite good at keeping metadata secret.

well, the signal server and everyone who has access to it will probably know everything about "who with whom" - at a global scale, including phone numbers.

wrt pfs - while this is good to have for sure, i disagree that pfs rules everything else. eg. it is easy to create an email account - if you use this account temporary for one $thing, throw away everything afterwards - isn't this also a reasonable use case? and this is not really doable with eg. signal.

however, i agree, it is hard to put everything in well-defined boxes :)

> Signal is a recommendation and it is quite good at keeping metadata secret. well, the signal server and everyone who has access to it will probably know everything about "who with whom" - at a global scale, including phone numbers. wrt pfs - while this is good to have for sure, i disagree that pfs rules everything else. eg. it is easy to create an email account - if you use this account temporary for one $thing, throw away everything afterwards - isn't this also a reasonable use case? and this is not really doable with eg. signal. however, i agree, it is hard to put everything in well-defined boxes :)

👍 1

dngray commented

2020-02-24 15:35:15 +00:00

(Migrated from github.com)

Signal is a recommendation and it is quite good at keeping metadata secret.

well, the signal server and everyone who has access to it will probably know everything about "who with whom" - at a global scale, including phone numbers.

That's not possible with sealed sender. I suppose state adversaries could monitor which IP addresses are communicating with each other ie through a metadata retention system though. This would be an issue that really effects any kind of P2P pathway though. Signal only uses servers to facilitate contact lookup.

As for signal monitoring that data, well many customers are behind CGNAT on VPNs etc, so that data would not be available to the Signal servers.

wrt pfs - while this is good to have for sure, i disagree that pfs rules everything else. eg. it is easy to create an email account - if you use this account temporary for one $thing, throw away everything afterwards - isn't this also a reasonable use case? and this is not really doable with eg. signal.

Most people will not do that however. A technical solution to that problem that has zero risk to the user is a much better solution as it doesn't depend on them not being lazy or forgetting to rotate their keys. It also does not take into account if "one $thing" is actually a long term relationship with a contact.

> > Signal is a recommendation and it is quite good at keeping metadata secret. > > well, the signal server and everyone who has access to it will probably know everything about "who with whom" - at a global scale, including phone numbers. That's not possible with [sealed sender](https://signal.org/blog/sealed-sender/). I suppose state adversaries could monitor which IP addresses are communicating with each other ie through a [metadata retention system](https://en.wikipedia.org/wiki/Data_retention#Data_retention_policy) though. This would be an issue that really effects any kind of P2P pathway though. Signal only uses servers to facilitate contact lookup. As for signal monitoring that data, well many customers are behind [CGNAT](https://en.wikipedia.org/wiki/Carrier-grade_NAT) on VPNs etc, so that data would not be available to the Signal servers. > wrt pfs - while this is good to have for sure, i disagree that pfs rules everything else. eg. it is easy to create an email account - if you use this account temporary for one $thing, throw away everything afterwards - isn't this also a reasonable use case? and this is not really doable with eg. signal. Most people will not do that however. A technical solution to that problem that has zero risk to the user is a much better solution as it doesn't depend on them not being lazy or forgetting to rotate their keys. It also does not take into account if "one $thing" is actually a long term relationship with a contact.

5a384507-18ce-417c-bb55-d4dfcc8883fe commented

2020-04-12 00:51:17 +00:00

(Migrated from github.com)

I think this should be added within the e-mail clients section, not the instant messengers one, since it is that, basically. It is a good alternative for people who are not so tech savvy to make use of encryption keys themselves, and it is quite stable in all its platforms since it has been on development for some time.

I understand if you still decide not to list it, though.

I think this should be added within the e-mail clients section, not the instant messengers one, since it is that, basically. It is a good alternative for people who are not so tech savvy to make use of encryption keys themselves, and it is quite stable in all its platforms since it has been on development for some time. I understand if you still decide not to list it, though.

This repo is archived. You cannot comment on issues.