You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of focusing on running Cleodora locally for privacy reasons it would be possible to have a central Cleodora server where user data is end to end encrypted i.e. nobody on the server side could read it.
The reasons for not pursuing this at least initially are:
I did not find simple and good JavaScript libraries for end to end encryption. They are needed for creating the default web client.
Running a central instance would generate costs that I would have to cover myself. That's a big commitment to start out with.
Running a central instance would mean making user management part of the MVP (minimum viable product).
Getting data encryption wrong would be catastrophic because it would give users a false sense of security and privacy. If problems were revealed at some point it would lead to lack of trust. If this is done it needs to be done properly.
End to end encryption slightly reduces usability because users who misplace their password would no longer be able to recover their data in any way.
The question of which data (metadata?) to encrypt would have to be solved. The more is encrypted, the more difficult it might be to implement. Encrypting less might leak information. Possibly this is not an issue, but possibly some people care strongly.
The text was updated successfully, but these errors were encountered:
Instead of focusing on running Cleodora locally for privacy reasons it would be possible to have a central Cleodora server where user data is end to end encrypted i.e. nobody on the server side could read it.
The reasons for not pursuing this at least initially are:
The text was updated successfully, but these errors were encountered: