User Profile

I'm having exactly the same problem. Did you ever hear back from Apple about this or otherwise find a solution?

Update: I've tested my apps again in 10.15 beta 10, and now of the three apps I'm working on that create event taps which filter keystrokes, only one of them is required to get the input monitoring permission in order to create that event tap. The other two can create the event tap without asking for or receiving the input monitoring permission. This makes no sense! I can only assume that this bit of security is very buggy.Could someone from Apple please come here and bring some clarity to this? I'm unable to prepare my apps for macOS 10.15 because I don't know how this is supposed to work!

Hello, thanks for the reply, and thanks even more for your Event Taps Testbench application! I use it frequently throughout my work and find it to be extremely useful.I can help clarify the difference between "Accessibility" and "Automation" at least a bit. Accessibility is the permission an application needs to use Apple's Accessibility API in addition to posting events, and monitoring and filtering them with event taps. I think it's something of a misnomer now that event taps and event posting is mixed in with it, as neither of those APIs are actually part of Accessibility, though I imagine many accessibility applications make use of them. Apple's Accessibility API is documented here: https://developer.apple.com/documentation/applicationservices/axuielement_h"Automation" is what's required for an application to be able to send Apple Events to another application. This is typically done with applets and scripts created using Script Editor but is of course also possible using various other APIs. Every time an application sends an apple event to an app it hasn't previously tried to automate before, it will trigger a new permissions modal dialog asking the user to approve that. Consequently, the "Automation" list in the Security & Privacy system preferences will list each application that has tried to send an apple event, and then nested under them will be each application that it tried to send the apple event to, with a check box for granting or revoking permission. And since AppleScript provides its own interface for using Accessibility features, it creates the rather unfortunate situation where some AppleScripts might need both the Automation and Accessibility permission in order to function. And "full disk access". And a slew of other permissions.It's really quite a mess, especially given that this triggers numerous nagging modal dialogs. Most users will see those and find them to be frequent and irritating enough that they'll care more about getting rid of them than reading what they have to say, and consequently will click the approve button without considering what they're doing. It's Windows Vista's failed security model all over again. I'm not sure why the engineers at Apple thought this was a good idea.Soapboxing aside, though, I'm still not sure what "Input Monitoring" is for. In at least one previous beta of 10.15, and I'm not sure which one (probably beta 4 or 5?), my app triggered a modal dialog requesting "input monitoring" permission when it attempted to create an event tap that listened for keystrokes, I think. I'm not 100% sure of that because I can't trigger it again. As you noted, in beta 7 and now in beta 8 creating keyboard event taps does not trigger a modal dialog asking for permission any longer.I wish someone from Apple would step in and clear this up. It's very important for apps that must observe and filter keystrokes, and I worry that a future release of macOS, possibly even a bugfix update, will suddenly impose this security restriction again without warning, breaking our apps and annoying our users. Historically Apple has not been properly communicative about when these restrictions will be imposed, and how one is supposed to deal with them.

Can anyone please help me with this? I'm unable to make a TSI for this issue as Apple doesn't allow them for beta software. And I'm stuck on 10.15 compatibility until this question is resolved.Additionally:If an application does require "input monitoring" permission, how does that app go about requesting that permission? I've found no indication of an API function for doing so.I'm specifically wondering if there's a function for "input monitoring" that's analogous to Accessibility's AXIsProcessTrustedWithOptions, where the app can choose whether or not a dialog will be displayed to the user asking for permission, but either way the app will be added to the appropriate list in the Security & Privacy preference pane with its corresponding check box unchecked.

The only way for an application to request permission to use Accessibility features is with the API provided by Apple, namely AXIsProcessTrustedWithOptions.What my company's software does is, during the postinstallation phase of installing, launch any of our applications that require Accessibility permissions and have them call AXIsProcessTrustedWithOptions.Unfortuantely it inundates the user with multiple windows asking to grant apps permission. Furthermore our installer installs a kernel extension so starting with 10.14 there's also a dialog asking for permission for the kext to load, and in 10.15 it will require a reboot as well.There is horrible UX. Unfortunately Apple doesn't provide us any way of doing anything different. It's quite unfortunate, and a lot of it strikes me as pointless.I would love Apple to give us a method of granting these sorts of permission during the installation process in a way that's easy for the user to handle, but don't hold your breath. In the future I expect we'll see more features get locked away behind permissions dialogs resulting in further UX degredations, and I don't expect we'll see any new features that alleviates this problem.

My question was mainly about trying to understand what Apple's requirements are for notarized software more than how I integrate it into my company's specific release system. Apple says that your software should be notarized, mention several different ways to do it (notarize an app, notarize a kext, notarize an installer, notarize all of them) but don't make it clear what the requirements for 10.14.5 are or what the future requirements will be.For example, it's not necessary for us to sign all of our apps because when they're installed via an installer they aren't flagged with the com.apple.quarantine attribute and therefore don't run afoul of Gatekeeper. Will that continue to be the case when Apple adds in the notarization requirement for all apps? If so, then of course I have lots of work to do. But if not then there's no work for me to do. But it'd be nice if they were clear about that! One of the reasons why we don't attend to these issues until Apple is about to release an update with new requirements is that we have no way of knowing what the full requirements are until we have Apple's software to test with.In any case, I've just spent the afternoon doing some tests with a clean 10.14.5 beta 2 installation. The previous version of the installer does not work, but if I manually build a new one with just the kext notarized it works again, so fortunately I have a relatively easy solution that will work for the time being.The other good news is that notarizing the kext only takes a few minutes, and only has to be done once per unique kext. So most releases will not require sending the kext off to Apple to be notarized, and the ones that do won't take all that long.Probably the biggest downside to this will be having to contact all of our clients and sending them updated installers. I'm sure we'll get a few support requests from users that will update to 10.14.5 and see the software break, but we should have an updated installer well before then.Also I apologize if I was agitated earlier, but it's been a rather frustrating day!

We did receive the notice concerning notarization back in October and considered it carefully, and the notice gave us no indication as to when specifically notarization would become necessary. It did not say macOS 10.14.5 would require kexts to be signed. In fact the only reason it suggested that notarization was important was because it would "give users even more confidence in your software" which is a fairly vapid reason, especially given our product and userbase. Given the onerous amount of work that will probably be involved for us to start notarizing our software, we decided not to pursue it at that time given that we had other more important priorities. I guessed (incorrectly of course) that the requirements for software might change in macOS 10.15, and waited for further announcements from Apple.edit: I just made use of the Wayback machine to confirm the previous information Apple gave us: "In macOS 10.14, notarizing your software is optional, but recommended. In a future version of macOS, notarization will be required." The strongly implies that we had until, at the earliest, the release of macOS 10.15 before anything needed to be notarized since them saying "macOS 10.14" implies all bugfix releases of 10.14 as well. So not only did they not announce that 10.14.5 would require signed kernel extensions until very recently, but they implied we'd have more time than that. Quite distressingly too, they decided not to grandfather in already installed but non-notarized kexts, unlike when kext signing became required. This means that our software will breakon anyone's system that updates to 10.14.5! That is very bad for us plus any other developer that must utilize kernel extensions, and demonstrates some unpleasant thoughtlessness from Apple.edit 2: I read from a third party source the kexts installed before March 11, 2019 will continue to work, so it's not quite as bad as I at first thought. However, why is a crucial piece of information like that not included in Apple's own documentation?In any case you're probably right that I won't receive much help here. Unless it's enough for the time being to just notarize our signed kext and package that into the installer, I'll probably resort to using a technical support incident to receive further help directly from Apple.I will go on record as saying though that I'm not happy about the security process and restrictions Apple has been introducing now and for the last several major versions of macOS. All of them strike me as a solution looking for a problem, and they're solutions that introduce a lot of problems on their own. (Don't get me started on how much trouble the restrictions on the Accessibility API and Apple Events has caused us, given that the security mechanisms in place for them are half broken.) The more macOS starts to get locked down and restricted similarly to iOS, the less useful it will be for ourselves and our customers.

Just created it, bug number 36013286