Feature requests

[aydin41k]

As a weekly user of the app, I'd find the following features useful:

1. Encryption: Full encryption on server side and decryption on user side.

• Maybe one encrypted list per user
• Maybe a premium-only feature
• Maybe pay-per-list

Use case: Store sensitive stuff.

2. Emergency contact: Add a secondary email. If the user doesn't log in for ~6 months, give the secondary email a right to reset the password for the account. I am thinking, i.e. if I fall off the face of the earth tomorrow, it would be nice/useful/vital? for my once to-do stuff to pass on.

3. Off the back of the above, maybe send a reminder to a user if they haven't logged into the system for 1/2/3 months. It is more of a marketing thing everyone does, rather that what I'd find useful for myself. But would be beneficial for the app overall.

[jessarcher]

Hey @aydin41k, thanks for the great request!

I'm really keen to keep advancing the privacy and security of RocketLog and have long wanted to make it "zero knowledge". I.e. make it so that the contents are unable to be decrypted on the server, even with root access. There will always be some limitations; a bad actor with root access could push malicious JavaScript to the client that would then have access to the decrypted version of the data.

I'm not sure if this would meet your needs, but my original intention was for every list to be encrypted client-side rather than per-list and it would (ideally) be completely transparent to the user. In other words, my intention was to protect the data from someone with access to the server, but not from someone with access to the device. Would that suit your needs? Or are you wanting to have special list(s) that require an additional password to protect the data even if someone has access to a device with an authenticated session?

I haven't done much research yet, but I believe zero-knowledge will be tricky with a web-based application because there would need to be a secret key that only the user knows that is stored locally in the browser for all encryption/decryption operations. To keep the UX good, I was hoping this would be transparent to the user by just using their login credentials as the encryption key. However, I wouldn't want to store this locally in plain-text, nor would I want to send it to the server to authenticate. Instead I think I would need to derive a separate encryption key and server authentication key from the login credentials and store those locally. A downside is that these keys would need to be stored somewhere that JavaScript has access to, whereas the current approach stores these in HTTP-only cookies so that only the browser and not the JavaScript has access to them.

[aydin41k]

Hi @jessarcher!

It is great to see you are thinking along the same lines in terms of privacy!

protect the data from someone with access to the server, but not from someone with access to the device

Yes, this is exactly what I had in mind. Once the data hits the device, it is decrypted and handed over to the user, and it is the user's responsibility thereon.

special list(s) that require an additional password to protect the data even if someone has access to a device with an authenticated session

I think this would be an overkill. I personally don't see how it would help me. You are not marketing it as a cybersecurity tool, it is a to-do list after all :)

I would need to derive a separate encryption key and server authentication key from the login credentials and store those locally.

If you create an encryption/decryption key that is a function of the email and the plain-text password, this would check all the boxes. If I am reading it correctly, this way the server won't see this key, neither it would be able to generate that key. And locally, JS won't have arbitrary access to the info on the server; it would only have a key to decrypt the data that is fed to it.