E2EE Synced Data

[trymeouteh]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

When using Ferdium servers or a self hosted server, data is not encrypted.

Proposed Solution

Add E2EE on all data and metadata

Alternatives Considered

None

Additional Information

No response

[SpecialAro]

Hello @trymeouteh, it is true that the body of each request is not encrypted. Nevertheless, we use HTTPS with SSL encryption (which is the general good practice on the web) - SSL will encrypt all data between the client and the server, preventing man-in-the-middle attacks.

Can I ask what are your takes on this issue?

[trymeouteh]

I always use services that store the data at rest with encryption and allowing only the user to be able to decrypt the data. This prevents the server provider from seeing the users data at rest.

[SpecialAro]

Huum... I see, but how do you suggest the data is stored?

In the server side we store the user data in a database. If we encrypt in the client side and only store the encrypted data in the server this would need extra complexity to ensure the user doesn't lose access to it's encryption key (for instance, if they break their computer, when connecting back to the Ferdium Server we would be able to send the data back to the client but he wouldn't be able to decrypt it).

I know this is a common practice with some apps (e.g. WhatsApp, Worldcoin, etc) that account the user for its own data. Do we really want to add the extra complexity to the Ferdium Server? If a user is concerned about privacy, he can self-host the server or use Ferdium without server nevertheless.

[SpecialAro]

Don't get me wrong, I think that end-to-end encryption is really important and it's why it is taking me so long to achieve the sessions sync across different devices (as I said in another issue) - I want to ensure that the data is only access by the user in the end, and that this data is not stored by any server whatsoever.

For the general public that is reading this, I'm talking about a "sessions sync" feature that is yet to be implemented in Ferdium and that I've been working on. This is NOT IMPLEMENTED yet. And once it is, I can assure you that the data will be synced across two different clients only, using a control server that will never be able to decrypt the data that is transferring from one client to another (Client 1 generates a public and private key (RSA Key pair) > sends the public key to the control server > control server sends public key to Client 2 > Client 2 generates a key (AES Key) and encrypts its own data with that key > Client 2 encrypts its own AES Key with the public key > sends both encrypted key and encrypted data to the control server > control server sends it to Client 1 > Client 1 uses its private key to decrypt the AES Key and then uses the decrypted AES Key to decrypt the sessions data)

[trymeouteh]

The key/password will need to be remembered or backed up by the user. It can simply be the account password which will require the user to have a strong password for strong encryption.

[SpecialAro]

The key/password will need to be remembered or backed up by the user. It can simply be the account password which will require the user to have a strong password for strong encryption.

Hum, and if the user forgets the password/wants to recover it somehow? We wouldn't be able to recover the data.

I mean, something like this could be achieved if other maintainers want to chime in and give their opinion. I guess that it would add complexity and a total system re-design (even though it would increase security - in the sense that the server won't be able to decrypt the data), so I'm not sure if we should follow that.

Let's see what others think about this 😁

[trymeouteh]

and if the user forgets the password/wants to recover it somehow? We wouldn't be able to recover the data.

I am fine with this as most E2EE services operate like this

Even if E2EE is optional were usere can choose to have E2EE but not have password reecovery as a tradeoff is better than nothing.

[vraravam]

Though I understand what E2EE is, I fail to understand what data we might store on the server-side (irrespective of whether its the accountless, self-hosted or public-hosted servers) that need E2EE.
Is it that the services and workspaces that a user has configured - is that considered sensitive such that E2EE is being requested?

One more tangential item is that even if we develop this capability, we cannot control how the Franz and Ferdi servers will store the data. So, essentially, for users in those servers who use the Ferdium thick client, they will not be able to use this capability. And for those pre-existing users who might not want to opt-in for this, then we will have to have some kind of different handling.

From my current work-related project, we have achieved E2EE by encrypting the whole database - rather than at a row-level. @SpecialAro can confirm if this is how the hosted Ferdium server is also setup.

[SpecialAro]

From what I can see, Ferdium Server is setted up in a way that the database itself is not encrypted. It is an SQLite database, and encryption/decryption at each request will, for sure, impact on performance.

I agree with @vraravam on the data sense... Do we consider them to be sensitive? We only store: email, password (hashed, of course), recipes, workspaces and settings. Nothing more... Is this considered sensitive? Well, if so, we provide the "self-host" option in that case.

[trymeouteh]

I consider the services and workspaces data to be sensitive since it shows what a users uses for services.

I understand if E2EE cannot be implimented for users using Franz and Ferdi servers and it is only available on Ferdium servers.

[vraravam]

We welcome contributors @trymeouteh for implementing this or any other feature. Would you be willing to contribute?

[trymeouteh]

I could contribute but not for awhile. And I am not familiar with Typescript. However with that being said I do not expect this feature to come into existence any time soon.