Disroot and E2EE - Can this service read private messages?

I’d need some help for the reviewing of Service Disroot (ToS;DR Phoenix).

Disroot.org is a company providing multiple services, such as email, cloud and messaging (open source and licensed under GPLv3)
According to their privacy policy, they don’t use personal data for advertising nor marketing and don’t share it with advertisers or other third parties unrelated to the service.
They seem quite privacy-focused, and yet there is something ambiguous I wanted your opinion about.

Should there be a point linked to Private messages can be read for this service?

Their email service doesn’t use E2EE so they’d have the technicall means to access their content.

“All emails, unless encrypted by the user (with GnuPG/PGP, for example) are stored unencrypted on our servers” - Mail.disroot.org

However, as far as I know their agreements do not mention collecting the content of any private communication.

Moreover, other parts of the service do use end-to-end encryption, which makes the choice even harder on whether applying or not the case mentioned above:

“All files uploaded to the server are end-to-end encrypted which means no one with access to the server can decrypt/read the data” - Upload.disroot.org

“All files sent to the cloud are encrypted with a key-pair created based on the user password to add an extra level of security. Note, however, that the keys are stored on the server, which compromises the level of security to some degree (e.g.: if an attacker knows your password and obtain the encryption key-pair, can decrypt the data). However, no “Master Key” does exist on our setup, which means the Admins cannot decrypt any file stored on the cloud without knowing user’s password prior” - Cloud.disroot.org

Currently, if the pending points get approved, Disroot would have an A rating, although this could drop to D due to the blocker nature of the case.

What are your thoughts?

1 Like

The case seems to describe the technical ability, rather than consent given in the terms, for staff to read messages. If anything, I think we should treat these differently, perhaps split it into two cases. IMHO, consent given to read the messages should be the blocker case and technical ability should perhaps just be bad?

For I think even forums that use the free and open source software Discourse, like this one right here, don’t encrypt messages end-to-end, and would otherwise get this blocker case. We should take into consideration whether or not users have the expectation that they’re using a secure means of communication. On the other hand, the service in question does seem to raise the expectation to be a secure and privacy oriented suite, so it is indeed surprising that their e-mail is not e2e encrypted.


You’re right, these quotes do not imply consent for staff to read messages, only technical ability, so I guess it would simply disqualify for Case 372: User-generated content is encrypted, and this service cannot decrypt it.

I think I’ll create a point linked to Case 189: Your private content may be accessed by people working for the service which is neutral and seems to apply here.
Thanks for your help clarifying it!


Yes, that makes total sense. Glad to be of help.

1 Like