macOS "Secure Keyboard Entry" doesn't persist across app restarts

[jzelinskie]

Describe the bug
Secure Keyboard Entry is functionality in macOS doesn't remain across application restarts.

To Reproduce
Steps to reproduce the behavior:

1. Open kitty.app
2. In the menubar, kitty > Secure Keyboard Entry or press option+cmd+s
3. In the menubar, kitty > Quit kitty or press cmd+q
4. Open kitty.app
5. Notice that in the kitty menu, Secure Keyboard Entry is not still enabled

[page-down]

I had thought of this as a configuration option:

• always enabled
• save last enabled state
• disabled by default

In addition, the "Secure Keyboard Entry" shortcut is not customizable and cannot be removed. This key combination cannot be used for any other purpose.

These two have been on my list for a while.

---

Here are some of my thoughts.

• [config option] macos_secure_keyboard_entry
  • no (default)
  • yes (enabled)
  • <CONF_DIR_FILE_PATH> (standalone kitty conf file, include at startup)
• [mappable action] toggle_macos_secure_keyboard_entry
  • If configured with <CONF_DIR_FILE_PATH>
    • Every switch (toggle) writes the current state to this standalone kitty config file.
• config file content:
  • macos_secure_keyboard_entry [yes|no]

atomic_save(f'macos_secure_keyboard_entry {self.state}'.encode('utf-8'), os.path.join(confdir, 'current-macos-secure-keyboard-entry.conf'))

[kovidgoyal]

This is not something I care about. Patches are welcome. I don't even
know what "secure keyboard entry" is supposed to accomplish, given that
any program running as the same user can read traffic on the tty pipe.

And to make it persistent, it would need to be stored on the filesystem,
where again any malicious app running as the same user can change it at
will.

So I really dont know what this "security" feature secures one from.
That said, I have no objection to a patch making it persist, should be
easy using NSUserDefaults in kitty/cocoa_window.m

https://developer.apple.com/documentation/foundation/nsuserdefaults

[page-down]

The security risks that this feature can defend against are quite limited.

• Software that is restricted by the macOS sandbox (cannot read arbitrary files)
• and that gives accessibility rights (reads the keyboard)

In my opinion, when such software is installed, it is already a serious security problem. This is a "feature" that provides a false sense of security.

The reasonable usage scenarios I can think of are as follows

• Do-not-disturb mode
  • When this feature is on no other program can get the user focus, including cli commands such as "open".
• Using screen recording software, but do not want to display the on-screen keys when entering specific content.

Honestly, all I care about is how to remove that hard-coded shortcut key combination.