daed
commented
5 years ago This is fantastic. Exactly the kind of feedback I was hoping for.
Debugging panes:
That appears to be default Electron behavior, but I deliberately left it in because there's no way to open the debugging pane once the software has started. I could see where it would be annoying for the user though. Maybe I'll see if I can set up a toggle for it. Worst case, maybe build a separate "debugging" release with it enabled. Unrelated: Electron doesn't save your window size by default, so if you resize laverna and quit, you have to do it every time. I need to find a fix for that too. I've admittedly spent next to no time on the electron stuff outside of getting it working, and it probably deserves some time spent on it.
File size:
Yeeeaaaah. So I've been doing a bunch of looking at this recently. The 64-bit Windows release clocks in at about 150MB, depending on how you're looking at it, your filesystem block size, and so on. Of that, the portion that laverna takes up (including graphical assets, license, node_modules, et cetera) is about 23.2 MB. The rest is Electron cruft. Biggest culprits are the actual electron binary (we repackage as laverna.exe but it's just renamed for our release) at about 65mb and node.dll at about 17mb. We're (I think) on the latest 2.x release of Electron, though I'm not sure if there's any optimization that can be done to it. The 3.x version has been non-beta for a little while, so I could try updating to that, but I can't imagine it's become that much better. If we had the ability to rewrite in C++ or Java I think we could get it smaller, but I'm not holding out much hope. Maybe asar bundling would help the size a bit? That has its own set of drawbacks though.
The main reason I was celebrating the reduction in size (aside from the obvious) is that thousands of very small files decompress super slow. We're probably at less than 20% of the time spent unzipping compared to what we were beforehand. That's huge. And as bad as 150mb is, ~225mb was much worse. :D
Remote Storage:
I'm not sure where this went. I don't think it was in the dev branch when I got started. Did it work in the old prod branch? If so I can take steps toward getting it back in there. On encryption, so long as encryption is enabled (config setting change, enabled by default) we do client-side encryption to Dropbox still. Here's what a note looks like:
The private key is stored in your browser's local storage, and it uses the login password as your unlocking passphrase (which I don't think we store anywhere that I can find) so it seems reasonably secure, at least for the time being. If there's anyone out there that wants to give a free security audit, I wouldn't complain. :D
Remembering passwords:
I thought about this for a while. My biggest concern with doing it is that it would have to put itself into browser localstorage with your notes. Realistically, that means if you get access to a person's filesystem (or some hosted exploit to get at another domain's localstorage from inside the browser which is probably more likely / terrifying) then it's a bit of busy work to decrypt all of someone's notes. I could encrypt the password, but then you need a password to decrypt your remembered password and it's passwords all the way down. I'd be willing to implement it, but I would probably bury it somewhere that can't be blindly enabled in the config. Maybe a config file that sets a "single user mode" with default user and password? With that option, you have to go out of your way to enable it so it can't be done flippantly, and the password is at least kept in a different location than the private key / notes. Still not great, but probably least bad.
Oooh, I had a thought. It's not a replacement for what you're looking for, but maybe long term we could implement 2FA as well. Given we don't self-destruct or anything if you have enough failed logins (which is also interesting) that might be cool to help mitigate brute force situations.
v1.0.3 on Windows 64 launches OK now but I am getting a set of debugging panes on the right.
Sometimes there is overlap between the main toolbar and the first note on the list below it.
Great it is so much smaller now, but really 158MB on disk is way too much for what the application does. I know we live in code inflationary times and memory is cheap, but I am old enough to remember applications being under 100KB in size :)
To clarify, where is RemoteStorage? And in any case, RemoteStorage or Dropbox, notes are always client-side encrypted, right? The principle here is that we cannot trust anyone (esp Dropbox), whatever their T&Cs promise.
Would it be possible to get the local installation optionally to remember the password so that we don't have to enter it every time we run the application? The assumption is that we may trust the local setup.