I couldn't agree more. A text editor exposing an attack surface via a network stack is precisely the kind of bloat that makes modern computing ultra-fragile.
I actually built a "dumb" alternative in Rust last week specifically to escape this. It’s a local-only binary—no network permissions, encrypted at rest, and uses FIPS-compliant bindings (OpenSSL) just to keep the crypto boring and standard.
It’s inspectable if you want to check the crate: https://github.com/BrowserBox/FIPSPad
This is all vibecoded FWIW, I think it'd be cool if authors more proactively disclosed this.
Why does my text-editor need to do "encryption at rest"? If I want data encrypted, I store it in an encrypted drive with a transparent en/decryption layer.
That is completely valid for personal threat models, I rely on LUKS/BitLocker for my daily driver too.
The specific gap this fills is 'Defense in Depth' + compliance. OS-level encryption (like FDE) is transparent once you log in. If you walk away from an unlocked machine, FDE does nothing.
App-level encryption, however, ensures the specific sensitive notes remain encrypted on disk even while the OS is running and the user is authenticated.
It's also portable as it allows the encrypted blob to be moved across untrusted transports (email, USB, cloud) without needing to set up an encrypted container/volume on the destination.
For FIPS/NIST workflows, relying solely on the OS often isn't enough for the auditor; having the application control the keys explicitly satisfies the 'data protection' control regardless of the underlying storage medium.
> If you walk away from an unlocked machine
...then I might as well ask what happens when I walk away from the encrypting edior while a file is still open. User Error can happen with any encryption or security schema. Pointing out a trueism is not an argument.
> It's also portable
So is encrypting files using a specialized tool. I don't need my editor to do this. The entire point of my criticism, and indeed the entire point of this thread, is that software that should focus on a narrow task, tries to do way too much, leading to problems.
For what it's worth I understood the argument and think it is valid. It's one thing for the file you're working on to be vulnerable if you walk away leaving the editor open; it's another for all of your other files to be vulnerable too. It's O(1) vs. O(n). The difference is clearly not zero.
> FIPS-compliant bindings (OpenSSL)
Using FIPS mode can be insecure because the latest FIPS-compliant version can be years older than the latest non-FIPS one with all the updates.
The only time it makes sense to use the FIPS version is where there is a legal or contractual requirement that trumps security considerations.
While I think this is good advice, the fact that it's true feels backward to me. "We have a legal or contractual obligation to be less secure than we otherwise would be." Just seems silly.
Welcome to the reality of most of the "information security" business, which is mostly just compliance by checkbox. A significant proportion of encrypted Internet traffic that is transiting government agencies or major enterprises gets decrypted in flight for inspection, literally inserting a black-box with privileged MITM capabilities into otherwise secure protocols, purely for the purpose of checking a compliance box, and that's not even the worst sin.
There's no insecurity like compliant cybersecurity :)
What does notepad need openssl for?
Encryption at rest (AES-GCM).
To meet FIPS 140-3, I can't roll my own crypto; I have to use a validated module.
I actually only link OpenSSL on Linux, and then only if it's in FIPS-mode. On Windows (CNG) and macOS (CoreCrypto), I use the native OS primitives to avoid the dependency and keep the binary small.
For the built-in web-browser instance it likely contains by now.
Ability to handle email coming soon.
But can it play MP3s?
I'm sure eventually it will, it's law:
Every text editor, if it survives long enough, will end up implementing a partial, bug-ridden version of Emacs.
> Every text editor, if it survives long enough, will end up implementing a partial, bug-ridden version of Emacs.
Every text editor, including Emacs [...].
Emacs has EMMS for music, reusing mpg123/mpv/ffplay and the like, but it can emulate Vim well enough too ;)
Altough now I'm using 9front, Sam and Acme. I feel myself weird not using the keyboard but at least I understood structural expressions for Sam/Acme really fast, first with 'Vis' and next under Acme. Oh, Acme can do mail and news and a bunch more... because it has I/O since the beginning, you can plug anything into it, from commands to the text buffer to sockets. Even a crude HN client if you dare.
No, no, no, Emacs is a pretty good operating system, it just lacks a good text editor.
Looks like it's using it for encryption.
Cryptography I guess