Ok will keep the ciphertext in body, and discard adding the locked_ciphertext field. Are there any other concerns?
I don’t have time to give it a proper read before the submission deadline, but there is nothing else of major concern
I have one last concern, I was thinking of giving the user the choice of using a master password to lock all notes, or use a password for each note. For the sake of UX, and giving the user the freedom of choice. What do you think?
I think this would increase the complexity too much to have both the option of a master key or invidividual keys.
Bear in mind for the approach you have originally chosen (individual keys), bulk encryption / decryption needs special handling. If you encrypted 10 notes individually within a notebook with 10 different passwords, then you encrypt the whole notebook (and the 10 already encrypted notes are skipped), if you then want to decrypt the whole notebook, how would you handle this? If you gave 11 different password prompts, the user has no idea which prompt corresponds to which note(s), and if there is no concept of actual notebook encryption, you can’t know which notes were encrypted in bulk and which were not
Notebook password does not bulk encrypt/decrypt notes, It acts as an access gate: once the notebook is unlocked, the user can see and open its notes. Notes that have their own password are always encrypted/decrypted with that note password only, not double encrypted using both the note password, and the notebook password. Notes that don’t have their own lock but live inside a locked notebook are encrypted/decrypted with the notebook password, but decryption is still on demand per note when it is opened, with plaintext cached only in memory for the session.
That is what is stated in the proposal:
A new module will be added,
services/perNoteLock/effectiveLockResolver.tsthat providesresolveEffectiveLockForNote(noteId)andresolveEffectiveLockForResource(resourceId). It determines whether a note or attachment is effectively locked, and whether that lock comes from the note itself or its parent notebook. This centralizes the “is this item locked and by which password?” logic so every entry point can reuse the same rules instead of reimplementing them.
Keep in mind what I meant here :
is to give the user the choice to have local encryption setup work in two different modes (using a master password to lock all notes, OR use a password for each note), not both together.
is to give the user the choice to have local encryption setup work in two different modes (using a master password to lock all notes, OR use a password for each note), not both together.
What I mean is only choose one for your proposal because the project is already big and you should not increase the scope further
Notebook password does not bulk encrypt/decrypt notes, It acts as an access gate: once the notebook is unlocked, the user can see and open its notes.
Ok I didn’t realise that. That is a problem, because there is a lot more complexity involved with hiding contained encrypted notes and notebooks (because notebooks can be nested in an encrypted notebook too) across all areas, managing moving notes / notebooks between encrypted / not encrypted notebooks. Also if you are hiding notes within encrypted notebooks it gives the impression that everything inside is encrypted (including note and notebook titles), so you then should really add encrypted titles, which adds more layers of complexity.
I recommended to other candidates to not implement real encrypted notebooks because it increases the scope of the project too much.
Okay, we can discard the notebook encryption, and make it a bulk encryption action for all notes in the notebook using the same password (per-note encryption approach)
Will that work?
P.S. when I submit the proposal should I consider this project medium or large?
It’s definately a large project. And yes just use bulk encrypt / decrypt for notebooks
Bear in mind for the approach you have originally chosen (individual keys), bulk encryption / decryption needs special handling. If you encrypted 10 notes individually within a notebook with 10 different passwords, then you encrypt the whole notebook (and the 10 already encrypted notes are skipped), if you then want to decrypt the whole notebook, how would you handle this? If you gave 11 different password prompts, the user has no idea which prompt corresponds to which note(s), and if there is no concept of actual notebook encryption, you can’t know which notes were encrypted in bulk and which were not
You’ll have to figure something out for this though. You need some way to identify when some notes use different encryption keys when looking at the notebook list, and maybe do not allow bulk encrypt / decrypt unless all notes within the notebook have the same state
I was thinking of a workaround:
- Bulk encrypt notebook: prompts the user once for a password and applies it only to currently unlocked notes in that notebook, notes that are already locked (with any password) are skipped and indicated as such in the UI, or alert screen.
- Bulk decrypt notebook: prompts once, then tries that password on each locked note in the notebook, notes that decrypt successfully are unlocked, and notes that were locked with a different password remain locked. The UI shows something like “X notes unlocked, Y still locked (different password)”.
Yeah that works
@mrjo118 @personalizedrefriger I’ve submitted my GSoC proposal. Thank you very much for all the feedback and time you put into helping me refine the design. Whatever the outcome, I really appreciate your guidance, and I would be very glad to work on this if selected.
Will it work on Android or iOS?
Yes mobile support is planned