True Offline Mode or Encrypted Data

Hi,

I work at a company that doesn’t allow confidential data to be stored in the cloud. However, the company does not offer anything for notetaking that is as compatible with my brain as Dynalist is.

I already voted for [Pro]True Offline Mode, but I wanted to make an alternate suggestion, just in case it might be easier to implement.

I’m not sure how your synchronization works, but would be possible to have a mode where all of the actual text is symmetrically encrypted locally by the browser, but the synchronization mechanisms and data storage are otherwise unaffected? The UI required would be an option to create an encrypted file, plus entering a local password to unlock it. In my case, since I’m using a company computer to edit the data, it would be fine to store that local password locally so that I don’t have to re-enter it each time.

If that were possible, I think it would be OK for me to use, and it would have a nice advantage of still supporting cloud synchronization and storage. Either way is OK with me though.

7 Likes

I can’t say if that can be done, @Shida is more qualified to answer.

Thanks for raising this point! I think many others are in the same boat as you where their companies have policies over these things.

2 Likes

Unfortunately, because synchronization involves conflict resolution, it would be a huge technical challenge to keep everything encrypted end-to-end without the server being able to read the data.

For example, if a user has modified the same document on two different computers before syncing them to the cloud (rare, but a plausible scenario), then there would be no way for the server to be able to merge the changes made by the two computers without decrypting the data. This also applies to a shared Dynalist document.

Even if there was a way to do so without compromising the security, we would still need to rewrite our sync algorithm to support both the end-to-end encrypted version as well as the regular version, which would be a burden to do at the moment.

In comparison, disabling sync for a document (or multiple documents, or all documents) is likely simpler. I would opt to implement that one first before considering the alternative solution.

2 Likes

+1 for encrypting as much as possible end-to-end

@Shida is there a conflict resolution happening on the within-item level? Would encrypting just text of the items allow you to do the merging of edits to different items while keeping their content hidden from the server? Some things like hashtag search and data integration might be tricky with this approach, though, if they are currently handled on the server.

Having a local JS API might actually allow us to write extensions that would hook into document loading/saving routines and do local encryption/decryption on the fly btw.

1 Like

Thanks so much for the super detailed response. What you said makes total sense to me. It seems like in the end-to-end encryption scenario, the server would have to store both versions and have a client handle the resolution at some point in the future (and then tell the server the result). I can see how that would be complicated to implement given the current system.

It’s extremely extremely unlikely to ever get end-to-end encryption for Dynalist. Simply because it then becomes almost impossible as a user, to use more than one device which is a requirement for me at least.

In order to use end-to-end encryption you need a private key. That private key must be on any devices that you want to access your data from. And the important bit is that Dynalist themselves can’t ever have that key, otherwise it’s not end-to-end. So that makes you the end user to be responsible for copying to/from all your devices, making sure it’s backed up safely as if you reset your device and don’t have access to your key, all your Dynalist material is gone.

I’d say that it’s possible to derive a private key from a passphrase you can enter on every device. But yeah, if you lose the key, then all your data is forever gone.

1 Like

@Cliff_Spradlin meanwhile you could try playing around with a Chrome text encryption extension. Something like Quick Encrypt does HTML as well (* not tested/used)

Thanks for the suggestion. However, I don’t think this will be compatible with Dynalist. I’m not trying to protect a specific secret like a password but rather the entire document.

The plugin you suggested does encrypt HTML, but it doesn’t transform the HTML already on the page. Even if it could, the result would be irrelevant because the HTML on the page is just a rendered view of the underlying Javascript-based data model.

An encryption solution that would work for the whole document would need to be more integrated and supported by Dynalist directly. Because merge conflicts are resolved on the server, the server currently needs to see the plaintext of the document. Conflict resolution could conceivably be moved to the client, but that would be significantly more work than the implementation I suggested.

As a side note, many eventually-consistent distributed storage platforms actually require the client to handle conflict resolution because the server usually doesn’t know how to correctly resolve conflicts.

Client-side encryption is always a great feature, but a simpler solution for businesses which require maximum confidentiality is simply to start selling a self-hosted license.

Businesses with these requirements will pay for it. Project management software like ActiveCollab has been doing this model for years and show no signs of losing popularity (and it also looks like they’ve already had the Views feature for a while).

A self-hosted license would be my #1 choice for maintaining privacy as client-side encryption is meaningless unless you open-source the client. Even then many want the server code released e.g. see controversies with Telegram, Wire, Signal etc. At that point it would have been quicker to have gone straight to the self-hosted model.

However there is a third option for confidentiality, and it also is easier than implementing client-side encryption: integration with the remoteStorage open protocol.

remoteStorage-enabled web apps allow users to store and serve their data from a server of their choice - currently you can choose to host your own data on Dropbox, Google Drive or any remoteStorage host (self-hosted or a hosting provider like 5apps).

Laverna (Evernote-alternative) is one such remoteStorage-enabled web app:

This would solve the requirement for confidentiality, as well as the need for integration with cloud storage providers which has been already been noted as useful for true offline mode.

1 Like

Has there been any new development for end-to-end encryption in Dynalist?

There is another thread asking for the same: Request: Page Encryption

I would really like to see end-to-end encryption in Dynalist and I’m perfectly aware of the usual deal: if I loose my encryption key the data ist lost.

Copying a long encryption key from device to device is preferable to not having encryption at all and password managers are perfect for this job.

I do get the difficulties on server side. Are there any new Ideas to solve this?

One other aspect is search. But search is already done on client side so this should still be possible with encrypted documents.

If I had a wish, Dynalist would be open source and end-to-end encrypted. But I’m fine with the next best thing: closed source and encryption.

I can’t speak for self-hosting companies. But I imagine there are many people using Dynalist who are the only ones in their company. So it doesn’t make sense to self host it. But the company still may allow them to use Dynalist if it were encrypted.

My question is: How hard is it to implement end-to-end encryption in Dynalist? Besides merge conflicts, are there other server side functions that would break? And can’t we outsource those functions to the client apps?

Maybe this isn’t helpful but I’m using Bitwarden as my password manager. It is open source, offers mobile apps and a web app. Obviously it encrypts end to end; but it seems to work and they must have had the same problems.

2 Likes

There is now a feature request on trello for client side encryption, please vote!
https://trello.com/c/5m8S6gWC/180-client-side-document-encryption

4 Likes

Related poll: Client-side encryption poll