Hate to be that guy that ruins parties but there's a couple of obvious issues here
Firstly, the repeated Java Script delivery problem
The library that generates random numbers is bundled in your browser. However, the code that calls that library is delivered from network every time, e.g.
let iv = crypto.getRandomValues(new Uint8Array(blockSize));
This code depends on what the server yields for every connection. There is no audit trail to check how the program behaved in the past.
Secondly, passwords. When you're grandma-proofing your product, introducing a low entropy secret from which key is derived creates a weak link for the communications' key. Stretching the key with PBKDF2 doesn't really help because the initial entropy is so low.
Ideally you want very strong key stretching with memory hard hash functions like Argon2, and you'll want to target local encryption of strong random keys with the password, not the communications itself. This is why we want public key authentication for SSH server and no passwords. It's safer that the weak password stays on the user's device.
Lastly, encryption is about converting confidentiality problem into a key management problem. This application doesn't solve the key delivery problem, if exchanging a secret such as the password over e.g. a telephone line is what you need to do, you might as well use that line to exchange the super secret comms.
The author describes this as a hack, when in reality it's just a bad product that doesn't make it easy to automate best practices. I have much more trust in stuff like Signal that generates (and upgrades automatically) strong secrets, uses public key crypto, and allows authenticating key exchanges with values that are safe to say over even an eavesdropped channels.
There's even open source and reproducible builds. That stuff isn't grandma proof, but at least its researcher proof when there at least IS some audit trail.
Hate to be that guy that ruins your security researcher dreams.
Your Argon2 memory hard function is useful against mass surveillance and belongs in mass market products. Let's leave it there.
Despite your protests, for an average joe who just wants to stash a secret somewhere and not have it in plaintext, this is absolutely ok.
There is no reason not to use Argon2 in place of weaker alternative, especially when there's no UX overhead.
The threat model "for an average Joe who just wants to stash a secret somewhere and not have it in plaintext" should probably be written in red, font size 48.
But take a look what the author is actually saying it can be used for, i.e. to "securely store passwords". The currently available tools like KeepassXC that do just that, also use Argon2.
"Your Argon2 memory hard function is useful against mass surveillance and belongs in mass market products."
Well if this product isn't for mass-market, it's for niche use, and here I thought niche products are usually for the special security cases for people who need extra security, but you're implying average Joes should NOT use mass market grade security but something niche and less secure.
In this case, the reason for not using Argon2 is that it's not available
Then it would naturally follow you wouldn't want to implement password-dependent security systems in JS.
I can respect the HTML file that stores an encrypted note. I just struggle in finding the use case given how files are supposed to be shared using secure platforms, and how client-side encrypted cloud and FDE take care of user's personal file confidentiality.
Perhaps you can just send a self-extracting piece and perhaps it's safe enough to deliver the password over the phone, but generally when your adversary sits in the backbone of the internet (i.e. when your default email isn't secure to begin with), you're in a world of problems. Even IF you're avoiding incidental collection, defaulting to any opportunistic E2EE like iMessage, or to any E2EE protocol that isn't authenticated is better UX-wise.
Firstly, the repeated Java Script delivery problem
The library that generates random numbers is bundled in your browser. However, the code that calls that library is delivered from network every time, e.g.
let iv = crypto.getRandomValues(new Uint8Array(blockSize));
This code depends on what the server yields for every connection. There is no audit trail to check how the program behaved in the past.
Secondly, passwords. When you're grandma-proofing your product, introducing a low entropy secret from which key is derived creates a weak link for the communications' key. Stretching the key with PBKDF2 doesn't really help because the initial entropy is so low.
Ideally you want very strong key stretching with memory hard hash functions like Argon2, and you'll want to target local encryption of strong random keys with the password, not the communications itself. This is why we want public key authentication for SSH server and no passwords. It's safer that the weak password stays on the user's device.
Lastly, encryption is about converting confidentiality problem into a key management problem. This application doesn't solve the key delivery problem, if exchanging a secret such as the password over e.g. a telephone line is what you need to do, you might as well use that line to exchange the super secret comms.
The author describes this as a hack, when in reality it's just a bad product that doesn't make it easy to automate best practices. I have much more trust in stuff like Signal that generates (and upgrades automatically) strong secrets, uses public key crypto, and allows authenticating key exchanges with values that are safe to say over even an eavesdropped channels.
There's even open source and reproducible builds. That stuff isn't grandma proof, but at least its researcher proof when there at least IS some audit trail.