e2e encryption

[Lunatic83]

First of all many thanks for your effort, this is a very interesting project.

I know this is not easy and you have a big backlog, from what I can read this is the roadmap but could you please share when are you planning to implement?

Thanks, Gaspare

[or-else]

Here is our logic:

Encryption is used to prevent a third party from reading your conversation. The third party can gain access to the conversation (1) at the client, (2) in transit, (3) at the server.

1. We can't do much about the client
2. The transit is taken care by communicating over https. It's technically possible to gain access to https traffic by gaining access to root certificates but that's maybe possible for US government only.
3. That leaves access at the server. In case of Telegram, Whatsapp, etc the server is untrusted because the user cannot verify if the server is secure. That's not the case with Tinode. You can install your own server and you can secure it as you see fit. There are also more options of securing your own server other than e2ee, like not storing the messages at all: https://github.com/tinode/chat/issues/356

Having said that we do see value in e2ee but that's not a simple project. Realistically there are two options for e2ee: OTR and PGP. Both have advantages and disadvantages. OTR technically offers better security at the expense of reduced product features, such as difficultly with using multiple devices with one account or group chats or access to chat history.

So, we want to see a bit of adoption of Tinode and see how it's used in real life before building the encryption. We want to see demand for e2ee first.

[Lunatic83]

Many thanks for your reply. I'll probably fork your project to implement this and other features, I have good opportunity in healthcare business in Italy, potential customer requested to have a controlled self hosted environment for internal communications. Tinode is candidate for this solution

Unfortunately I have the same issue #360. I'm struggling to deploy docker container for local source code.

[or-else]

Sounds good. Let me know if you have questions.

All the issues in #360 are fixed in devel.

[Lunatic83]

many thanks.

[hialvaro]

Would it be possible to improve encryption with a OMEMO / MegaOLM / Any implementation of "Signa'ls protocol" Double Rachet Algorithm? OTR is good, but DRA is much better.

https://signal.org/blog/advanced-ratcheting/ (Note that the article is from 2013. Signal's protocol has now improved a lot.)

[or-else]

The issue is complex both technically and logistically. Also, it not obvious with respect to how Tinode is positioned on the market.

All of the e2ee features come with a usability cost. For instance, it becomes impossible to access message history from different devices, like using the same chat from webapp and mobile clients.

Signal released its implementations under GPL-3, while our clients are under Apache 2.0, so we can't use their code in our clients. If we are to implement some variant of their double ratchet we would have to write it ourselves which is pretty hard.

Implementing strong e2ee would create obligations for us under EAR https://www.bis.doc.gov/index.php/encryption-and-export-administration-regulations-ear. I would rather avoid that for as long as possible.

If you care about privacy of your communications then there is Signal already which is as secure as it gets. I don't think Tinode will ever be as secure as Signal. Should Tinode compete with Signal for the same market niche knowing that it will never be #1 in that niche?

Both WhatsApp and Telegram have some token e2ee options. We would probably go the same way as them as opposite to Signal.

[dzcpy]

How about borrowing some code from this project? https://github.com/nebula-chat/chatengine

[ice-myles]

Is there any planned release date for this feature? It is showed here in the planned section.

[or-else]

It's a lot of work for minimum gain. We are unlikely to work on it in the next year.