To be fair, the exact same problem afflicts something like Protonmail, so calling it a toy may be too harsh.
For this persons use case though, assuming they’re not a person of interest to any “threat actors”, I wouldn’t be too worried.
This doesn't help if someone can mess with the HTML though.
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.
- 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
I assume you are referring to the OP's post there but I did a double take because I know some extremely technical moms.
I’d expect better from Jane. This is the kind of shit Mallory would pull.
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.