[macOS Sequoia] Using RegisterEventHotkey with option and shift modifiers doesn't working anymore

Also FB14730958 filed back on August 9th on the same matter.

This was an intentional change in macOS Sequoia to limit the ability of key-logging malware to observe keys in other applications. The issue of concern was that shift+option can be used to generate alternate characters in passwords, such as Ø (shift-option-O).

There is no workaround; macOS Sequoia now requires that a hotkey registration use at least one modifier that is not shift or option.

This was an intentional change in macOS Sequoia to limit the ability of key-logging malware to observe keys in other applications. The issue of concern was that shift+option can be used to generate alternate characters in passwords, such as Ø (shift-option-O).

Thanks for letting us know. However, this should have been clearly documented in the release notes during the beta period so developers could have prepared for it.

I also don't get the logic. The change only impacts sandboxed apps, but malware wouldn’t use sandboxing. Plus, any app can request input monitoring and misuse it, so this mostly hurts legitimate apps and their users, and does very little to stop actual malware.

macOS Sequoia now requires that a hotkey registration use at least one modifier that is not shift or option.

How does this even prevents key loggers?

The opt and opt+shift modifiers are very useful to invoke custom utility functions since apps rarely use them

I think the reason for that is because the keys can be used by users for alternate characters such as Ø. And it's perfect! I don't use alternate keys, and I my custom shortcuts don't conflict with third party apps.

None of the other modifers can replace opt, since they all are in use by the apps. cmd is virtually used by everyone, ctrl is extensively used by CLI and TUI apps.

It's sad to see the possibility to capture opt keys to go away for sandboxed apps. I want to ask to at least keep the possibility for non-sandboxed apps in future macOS versions. Otherwise, it becomes very limiting for advanced users.

Just seconding the other commenters' concerns around this implementation.

I and other people I know use global keyboard shortcuts with App Store apps constantly as a core part of our workflows, and always use a lot of modifier keys so that they don't conflict with other applications.

Having a lot of little utility-apps driven by keyboard shortcuts is a fundamental benefit of macOS for us.

Maybe RegisterEventHotKey could allow a limited number of Shift/Option registrations per app as a middle ground? I think apps generally only need a couple of global keyboard shortcuts, and that'd prevent any useful key-logging.

Thank you for the info.

But I doubt key-loggers are using the RegisterEventHotKey API for every possible combination of special characters. There are so many easier ways to accomplish this.

I doubt this change had anything to do with security or user-safety. It's just yet another change where Apple oversteps its bounds to prevent users from configuring and using their own computers the way they want to, if you ask me.

Edit: and of course, Apple's own keyboard shortcuts are exempt from this restriction (see screenshot)

This is now breaking custom shortcuts for numerous third party apps and other than users complaining about our apps, it's hilarious to require users to learn about this "special knowledge" unless apps begin to say "you must also use CMD key if you want to use Shift or Option" - which makes no sense.

This is a regression back to 1999 when there weren't that many apps and there weren't that many shortcuts to remember.

With this change you're protecting passwords that contain Ø but what about all the other passwords that use plain English and do not use Shift+Option? What about the emails and documents the user has composed in Mail / Outlook / Pages? Those can be logged?

Sequoia might as well disable all keys on the keyboard to protect the user from ever leaking their passwords to key-loggers that their jealous boyfriends managed to install while on vacation.

This is frankly ridiculous.

What is going on here.

Option is a very important key for shortcuts in order to make sure pain in the fingers are reduced.

This is a major bug!! It doesn't prevent any issue but creates a lot of issues for the users.

It seems we will have to get used to use Ctrl instead of Opt from now on.

I don’t know what Apple sees in their data, but I’d be willing to bet that the ratio of users who lost keybindings vs. users affected by keylogging is gargantuan.

Apple should at the very least give a setting (even a defaults write) that allows responsible users willing to accept the keylogging “risk” to continue using the shortcuts they’ve used for over a decade.

These ”security” regressions are why I dread macOS updates and hold out on updating for as long as I possibly can.

Imagine paying 3500 Euro for a professional machine, in order to be forbidden to use your own keybindings with the most reachable key on your keyboard.

This was an intentional change in macOS Sequoia to limit the ability of key-logging malware to observe keys in other applications. The issue of concern was that shift+option can be used to generate alternate characters in passwords, such as Ø (shift-option-O). There is no workaround; macOS Sequoia now requires that a hotkey registration use at least one modifier that is not shift or option.

I don't understand this explanation at all.

Why wouldn't you just not dispatch keyboard events when the user is interacting with password related UI? For example if an NSSecureTextField is editing in the active app...just don't post the keyboard event to listeners. When the user is not interacting with password related UI let them trigger their keyboard shortcuts because....that's what they actually want to do.