Client side decryption has the benefit that no machine or router in the middle can view or cache the decrypted page without the password.

You mean, unless they tamper with the Javascript to capture the password (or the derived key).

I designed a similar tool with that threat model in mind: the resulting HTML/JS is as minimal as possible so it’s possible to inspect before entering the password. Of course assumes safe browser and client machine.. https://github.com/dividuum/html-vault

Kind of possible. With enough content, would you actually spot a "}; and some highly obfuscated code in the middle of the blob? (My guess is a no)

You're right. Probably not. But at least the chance exists as there isn't a multi-KB obfuscated JS dependency somewhere that would be a lot harder to handle.

Valid if you actually host the file online. Local files are generally not allowed to make requests. Not sure if local storage methods are usable without http/s.

Their solution intends for the static file to be copied offline

Wow I like that. So simple and elegant. Could be combined with a username to produce unique urls per user.

A miss configured http server that allows directory listing would compromise everything.

Also now all intermediate things that have access to the hashed url would suddenly have access to a secure piece of information.

Don’t be clever with security

You can always put an index.html to prevent that mistake.

Requiring some sort of VM or container to run this webserver on? Is it possible that's way more onerous than a static html file which can be emailed around? Are you sure nginx is even going to be around in, say, 15 years? (think password protected PDF but in html and allowing for JavaScript.)

> you sure nginx is even going to be around in, say, 15 years?

Considering it's been around longer than that, yes I think it will be around in 15 years