One thought that I have: would there be an issue sending this file in an unsecure context where MITM is a possibility? Alice sends Bob her HTML file over an unsecured medium, and Jane intercepts this traffic, and gives Bob a modified HTML file that will report the password back to Jane. Jane can set it up so that the browser still displays the local file as it's source, but has an HTTP request in the background phone home back to Jane's server.
My scenario only works if Bob doesn't inspect the page source before entering their password, or if the modifications are sufficiently obfuscated.
Yes. This is essentially a binary with the browser acting as the OS. And if it's hosted on a server it's a binary which may change at any moment. There isn't even a mechanism by which to freeze its hash and alert you if it changes - a browser would have to provide that functionality.
To be fair, the exact same problem afflicts something like Protonmail, so calling it a toy may be too harsh.
100% agree. This is why I’m always a bit dubious of in-browser decryption. At any moment a little extra snippet of JS can be added to stealthily leak my secrets. There’s no great mechanism to ensure the JS I’m running is always the same JS I ran before. Compare this to a desktop app where I always know I’m running the exact same binary I ran last time. (And if I’m not then I’m probably already pwned anyway)
For this persons use case though, assuming they’re not a person of interest to any “threat actors”, I wouldn’t be too worried.
It may be too much for moms, but maybe the html document includes the content, but a chrome extension does the work and presents the secret in the extension popup.
- attack surface area drastically reduced. only one MITM matters now, the extension installation
- requires great extension UX, to help dads know where to click
less portable than just a document, but perhaps a nice middle ground
It's important to be precise and clear-thinking when articulating problems, lest we identify the wrong one but believe it's the right one.
Your issue is not with the program being in-browser, but rather it being an online one that gets ~continually re-fetched and immediately trusted without verification.
One counter-measure to this is to run the decryption without internet connection. This is easy enough to explain to a hypothetical non technical mother.
One thought that I have: would there be an issue sending this file in an unsecure context where MITM is a possibility? Alice sends Bob her HTML file over an unsecured medium, and Jane intercepts this traffic, and gives Bob a modified HTML file that will report the password back to Jane. Jane can set it up so that the browser still displays the local file as it's source, but has an HTTP request in the background phone home back to Jane's server.
My scenario only works if Bob doesn't inspect the page source before entering their password, or if the modifications are sufficiently obfuscated.