Request: Page Encryption


#1

Creating a new thread to track Page Encryption feature requested in the forum page Privacy and security

Key points:

  • This is request for Client side encryption
  • Page security after logging into Dynalist
  • 100% risk of losing data if this password was forgotten by user.

True Offline Mode or Encrypted Data
Privacy and security
Self-Hosted Dynalist (Privacy and Security)
#2

Thanks for the request.

By the way did you add the “Tracked” tag yourself? Or is that a mistake?


#3

Yes, I added the tag (thought best fit).


#4

I’ll remove it for now, it’s only for bugs and it means the bug has been tracked by us.

I don’t see a way to add a quick tooltip for each tag, so sorry for the confusion! You don’t need to add any tags when posting a topic, it might cause future confusion when managing topics. Thanks!


#5

I would really like to see this feature too.
Client side encryption.
If there is a security breach at dynalist valuable information could be stolen.


#6

I think this should be merged with the ‘password protection’ feature on trello https://trello.com/c/e7flE77k/149-password-protected-documents. Without actual client-side encryption setting a password for a document is not so useful. Why not make it client side encrypted at the same time?


#7

I think that one is a bit different. Password protected document is so that your kid or spouse or colleague won’t accidentally see what’s in your secret Dynalist document.

I still think they are two different use cases. Obviously page encryption is a stronger measure to protect your privacy.


#8

I would like to use Dynalist for work, and this is a necessary component of me feeling safe to do that (along with implementing two-factor authentication). So here’s another vote for implementation! I realize it’s likely a big task to do so.


#9

Is there any update or timeline for this feature?


#10

@Erica @Shida As I see it, this could be implemented fairly easily by just encrypting each item with a client side key before sending it to the server and decrypting each async http response with items locally in the client.

When opening a new Dynalist tab, you would have to insert your keyphrase so that it is locally stored in memory of the client.

The same procedure applies to the API, all requests send encrypted data and receive encrypted data.

For shared documents, the key would have to be communicated between participants over a different channel (like person to person, encrypted email, etc).

Which commonly used encryption scheme to use would still have to be discussed.

All of this should be easy to implement, compatible with all current Dynalist features, and much easier than an offline mode or similar ideas. Furthermore, a huge selling point compared to competitors.


#11

Totally agree that this would be very useful to have.

Couple of concerns we’re still working out the details:

  • Backward compatibility (or upgrade process). Depending on which part is encrypted and how the encrypted data is encoded, older dynalist clients (especially mobile app and desktop app) will either completely break, show encrypted data in the form of gibberish if stored in some ascii format like base64, undefined rendering behavior if stored in bytes (bad unicode chars).
    This could be solved with an upgrade period during which people can’t create encrypted documents, and once we’re confident there’s very little old clients left, flip the feature on.

  • Feature support. Should we also disable dropbox/gdrive backups? Encrypted backups won’t be useful for most of the population who aren’t able to implement the decryption algorithm to decrypt their backups. This is especially problematic for plaintext backups because item content and description are dumped into plaintext with newlines and tabs inserted. Same problem with google calendar sync.

  • Encrypted document creation. Do we allow “encrypting” an existing document? If so, a lot of things needs to be taken care of, for example, concurrent modifications (i.e. what if a collaborator/other device made edits before you made the switch, but synced it after because that device didn’t have internet access).

  • Synchronization. We’ll need to keep most of the item metadata unencrypted, and only encrypt the content and note fields. This is because the server needs to know item order (indices) to be able to merge new changes into the document.

    • If we were to keep everything decrypted on the client side, it means the user MUST enter the password when the document gets loaded into their client. Keeping it decrypted would save us the need to change the client code since we can transparently encrypt/decrypt when it syncs to the server, and the rest of the client code can just work the way it is right now. Downside of this is that a client must enter the password if an encrypted document is detected, or else the document will not even be kept locally (desktop/mobile client supporting offline mode especially). Also none of the cross-document features will work until it is decrypted, i.e. global search, tag pane, go to anywhere, link to any item, move to any item. I think it’s reasonable given the user didn’t decrypt the document, just have to make extra sure things don’t go haywire when the document isn’t loaded.
    • The other option is to keep the document contents encrypted, and decrypt it in-place when the user enters the password (the first time in each user session). We’d need to make sure all the client code doesn’t “accidentally” touch the encrypted data and come back with gibberish. This means things like global search, tag pane, etc. I don’t really like this one.

That’s what I can think of right now. Pretty sure when implementation time arrives there’s going to be loads of more issues to tackle.


#12

I’m not sure I understand the concern with the backups. If the backup process will encode (base64 or similar) the encrypted text as part of the process, then it can be easily restored later and doesn’t risk getting mangled while in a plaintext format.

I think it’s fair to release this feature with the ability to create new encrypted documents and support converting existing documents later. Hopefully phasing this will help with the release time and effort for building the system.

Also, I fully expect to have to enter the password to decrypt a document each time it needs to be opened/edited and that searching would be restricted until that document is decrypted.


#13

The backup process is not able to decrypt the content and note section of the item, because they are encrypted with a password not sent to the server. This means we would be putting the encrypted content in plain text, one after each other in the plaintext backup.

The OPML backup is more easily decrypted using an XML parser, but decrypting the plaintext backup would be more difficult and in my opinion, probably unnecessary.


#14

Sounds good, and of course, you are right.

Having encrypted OPML backups makes sense to me, users wishing to restore them simply import them back into Dynalist. Also, users who chose to encrypt their Dynalist definitely don’t want unencrypted backups flying around anyways. As far as I know auto backups to Dropbox/Google drive are in OPML anyways? If you want a plain text backup you could do that manually from within the Dynalist client (the download backup option in the menu), and there the passphrase is available. Google calendar sync support would indeed break.

Easy solution: Encrypting a document duplicates it. Deleting any document must ensure that there is no trace left on the servers, i.e. delete version history, meta data, etc.

I think that is acceptable, the item content and note field is what might be sensitive.

I agree with this option in particular for its code re-usability potential. Treat all encrypted documents as non-existent until the user clicks an unlock button to enter their passphrase to unlock all encrypted documents.