Note History keeps the un-encrypted data

[cipherswami]

Need to flush out the note history after encrypting.

[mrjo118]

I did further analysis and tests with note revisions, and actually even with the existing Joplin code it is possible for unencrypted contents to get created in a revision after revisions have been deleted, so there could still be a leak even if adding to the api the ability to get all revisions for a specific note.

Not sure how viable this is (in terms of what the UX will be like, and whether or not step 4 is possible), but I have an idea for an alternative which is worth attempting, which for sure would prevent any leak of unencrypted note contents into revisions after encryption has been applied. It also does not require any change to the Joplin api. The solution is the following:

1. User chooses encrypt note and confirms the password dialog
2. Encrypt the note contents and save it to the note (important - the original note should be replaced with the encrypted contents BEFORE duplicating it, as existing revisions are deleted and then a revision is created with the final contents, upon permanent deletion)
3. Create a new note with the same contents as the original
4. Switch to the new note in the UI
5. Permanently delete the original note

[cipherswami]

IDK man, I did similar gimmicks like this with refreshNotesView function. The bugs you are seeing in mobile version is because of that.

But your Idea might solve my other issues.

If push comes to shove I'll implement this.

[mrjo118]

IDK man, I did similar gimmicks like this with refreshNotesView function. The bugs you are seeing in mobile version is because of that.

But your Idea might solve my other issues.

If push comes to shove I'll implement this.

I had a look at the refreshNoteView function and it is almost the same as what my proposal is, so my proposal is certainly possible. The reason you get the temp notes left in the recycle bin is because you're not using the permanently delete mode of the delete note api. Currently when you navigate back from a newly encrypted note on mobile, it shows the recycle bin because the last used notebook was the recycle bin (as you're not doing a permanent deletion). Hopefully by doing a permanent deletion, the last used notebook will remain as the parent of the current note, so you won't get a navigation issue anymore.

By the way, any chance you could put some instructions in the README of how to build your plugin?

[cipherswami]

Yes yes, mine and your ideas are similar. That is what I said, in the worst case scenario, I'll implement your Idea it will solve both problems, But that's not really an Ideal way. I have few tests in mind, will see what happens...

And the instructions to build the plugin is already there in README.md, Check Installation section. If any further help is needed DM in the Joplin forms.

[mrjo118]

Ah, I missed the hyperlink in the installation section. I gave it a go doing the permanent temp note deletion, and unfortunately when you navigate back on mobile, it takes you to a blank note list, and then navigating back again takes to back to the original note. Unfortunately it can't be avoided to add to the navigation history every time you navigate to a different note when using the navigation commands, which is not a good user experience on mobile. Although now that you don't get the password prompt every time the note opened when you're in edit mode, 1 or 2 useless presses of the back button for each encryption / decryption to go back may be passable if this is the only solution that can be implemented. If my Joplin PR laurent22/joplin#13031 gets merged, then it would be less of an annoyance if you can go straight back to the note list easily from the note viewer / editor.

I do think though that it's a bug that the navigation on mobile allows you go back to a reference where the note no longer exists. I'll look into if I can address this in a Joplin PR, and if that gets resolved as a bug fix, then best case scenario the refreshNoteView style implementation would actually give no usabilty issue, as the backward navigation would then skip over useless steps.

[cipherswami]

We have all this problem because of editor API. ContentScripts will give me full control, But writing an editor from scratch is a big work and I don't know what will happen to the performance either.

And instead of back button we can keep hamburger menu of the notebook view.

[mrjo118]

But writing an editor from scratch is a big work and I don't know what will happen to the performance either.

Sure, I'm just trying to make things easier for you, as I don't want this great work to go to waste due to a poor user experience or leaking unencrypted data. Adding a get revisions for note api is not going to be sufficient to prevent unencrypted content being created by the revision service at a later point, and the only way to truly deal with it via the api is to make a delete all revisions for note api, which does the clean up in full. But that's a very specific use case. To be honest I am doubtful that some changes to the Joplin API will be accepted just to support your plugin, but fixing a more general issue has a much better chance

[mrjo118]

I do think though that it's a bug that the navigation on mobile allows you go back to a reference where the note no longer exists. I'll look into if I can address this in a Joplin PR, and if that gets resolved as a bug fix, then best case scenario the refreshNoteView style implementation would actually give no usabilty issue, as the backward navigation would then skip over useless steps.

I was able to find a bug in the Joplin code as I described. I've created a PR to fix it here: laurent22/joplin#13428. I made local modifications to your plugin in order to test the fix.

If my fix gets merged, then using my proposal, you will be able to fix issue #1 and #4 without introducing any navigation history issues. The only issue would be that there will be a 'flicker' of the note changing to the duplicated note upon encryption / decryption (how visible depends on the performance of the mobile device), but to be honest this is pretty minor and acceptable (and the contents will be the same, so it will be barely noticeable, which is better than briefly seeing the temp note at current)

[cipherswami]

Bro don't worry about this refresh notes function I will definitely remove it. I'm planning to put the password dialog directly in the plugin editor view (Secure View), I know it is possible with contentScripts, just checking if it would be possible via editor API. This would take time. But, the will be a good user experience.