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
{{ message }}
This repository was archived by the owner on May 12, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on May 12, 2026. It is now read-only.
This is a feature request/wish. It would be really awesome if it was possible to protect access to a note (perhaps also folder). A simple password would do.
it would be even better if it could be encrypted with the password, with a good strong encryption like AES. it would make the files hard/impossible to recover if you forget the password - but it would be great having it available as an option.
Option 1) Unsecured
Option 2) Secured with password only
Option 3) Secured with password and encryption
Maybe something like that. (for now you can just store your boostnote storages on a partition encrypted with Veracrypt or something similar though i guess, or something like boxcryptor if you're using a cloud service)
It would be cool if the user could choose the encryption method too but not necessary,
HTTP API data payload encryption: Our backend will send document data after encrypt. Pretty safe from XSS attack until you unlock the documents. Still visible from BoostIO, service provider so we can provide search functionality.
E2E data encryption: We store encrypted data. No one, including BoostIO, cannot access the content without its password. You cannot search encrypted documents from our app anymore since we cannot make them indexable. Pretty safe from data breaching from our backend database.
Thanks, @Rokt33r. Among the two options, I would like to have E2E data encryption.
You can suggest other options. We just want to know how many security measures do people need.
I'm no expert in the field, but I can also think of access token-based authentication, e.g. SSL private key (is it option 1 from above?), an app-specific authenticator file, some standardized authenticator provided by third parties e.g. Google, Microsoft, etc.
I'm no expert in the field, but I can also think of access token-based authentication, e.g. SSL private key (is it option 1 from above?), an app-specific authenticator file, some standardized authenticator provided by third parties e.g. Google, Microsoft, etc.
@mnmami I don't understand what you exactly want to have. Do you want us to implement somewhat 2-factor verification for an individual document?
What joplin does is perfect, if you could replicate their end to end encryption functionality that would be great, i use it with nextcloud and it encrypts all my notes synced there, works very well: https://joplinapp.org/spec/e2ee/
Functionality allowing the user to protect and encrypt a note stored locally (that wouldn't otherwise be encrypted with e2ee) would be useful too, but i guess less important, because to encrypt those local notes the user could just encrypt their system drive instead.
@huzibizi I don't think we can provide the same feature of Joplin app.
Our app is not replicating the whole data of storage for each client.
It seems Joplin syncs the whole data and decrypted it from each client. But our service is sending data on demand. So our server needs to understand what the client requests. It means our app needs to understand the storage structure of the user's storage. Also, the OP is asking about protecting a single note, not encrypting the whole storage.
Our backend needs to handle real-time collaborative writing.
Quite similar to the first reason. Our real-time server needs to read changes from clients to resolve any conflicts among them and generate revisions.
So I think we need a different approach. What experience do you exactly want to have?
Although It's not E2EE, we can still send encrypted payload for every HTTP request and web socket communication. But our backend still needs to read the data to provide the basic functionality, navigating, authoring, and anything else.
We can also introduce a new feature like "encrypted blocks" which can be embedded on a document but cannot open until further authentication is done. It can be E2EE. Its contents are completely unreadable from our backend. So we cannot provide real-time editing for the blocks.
Activity
huzibizi commentedon Jul 22, 2020
it would be even better if it could be encrypted with the password, with a good strong encryption like AES. it would make the files hard/impossible to recover if you forget the password - but it would be great having it available as an option.
Maybe something like that. (for now you can just store your boostnote storages on a partition encrypted with Veracrypt or something similar though i guess, or something like boxcryptor if you're using a cloud service)
It would be cool if the user could choose the encryption method too but not necessary,
Rokt33r commentedon Aug 23, 2021
@mnmami How much security level do you need?
Rokt33r commentedon Aug 23, 2021
You can suggest other options. We just want to know how many security measures do people need.
mnmami commentedon Aug 23, 2021
Thanks, @Rokt33r. Among the two options, I would like to have E2E data encryption.
I'm no expert in the field, but I can also think of access token-based authentication, e.g. SSL private key (is it option 1 from above?), an app-specific authenticator file, some standardized authenticator provided by third parties e.g. Google, Microsoft, etc.
Rokt33r commentedon Aug 24, 2021
@mnmami I don't understand what you exactly want to have. Do you want us to implement somewhat 2-factor verification for an individual document?
huzibizi commentedon Aug 24, 2021
What joplin does is perfect, if you could replicate their end to end encryption functionality that would be great, i use it with nextcloud and it encrypts all my notes synced there, works very well: https://joplinapp.org/spec/e2ee/
Functionality allowing the user to protect and encrypt a note stored locally (that wouldn't otherwise be encrypted with e2ee) would be useful too, but i guess less important, because to encrypt those local notes the user could just encrypt their system drive instead.
mnmami commentedon Aug 24, 2021
Sorry @Rokt33r for the confusion. Please see the updated comment with the intended quote.
Rokt33r commentedon Aug 31, 2021
@huzibizi I don't think we can provide the same feature of Joplin app.
It seems Joplin syncs the whole data and decrypted it from each client. But our service is sending data on demand. So our server needs to understand what the client requests. It means our app needs to understand the storage structure of the user's storage. Also, the OP is asking about protecting a single note, not encrypting the whole storage.
Quite similar to the first reason. Our real-time server needs to read changes from clients to resolve any conflicts among them and generate revisions.
So I think we need a different approach. What experience do you exactly want to have?
Although It's not E2EE, we can still send encrypted payload for every HTTP request and web socket communication. But our backend still needs to read the data to provide the basic functionality, navigating, authoring, and anything else.
We can also introduce a new feature like "encrypted blocks" which can be embedded on a document but cannot open until further authentication is done. It can be E2EE. Its contents are completely unreadable from our backend. So we cannot provide real-time editing for the blocks.
Rokt33r commentedon Aug 31, 2021
@mnmami How do you think about the idea, "Encrypted blocks" in #519 (comment)
mnmami commentedon Sep 1, 2021
@Rokt33r yes, also a very good idea.