Does using HIDVirtualDevice rule out Mac App Store distribution?

With this entitlement present, macOS shows the system prompt requesting Accessibility permission.

First, as a clarification, the prompt is tied to specific device types (keyboards/mice/touchpads), NOT just general HID device usage. Putting that in more concrete terms, it's required because your device is generating events that could be used to directly control the system, not simply because you're using the virtual HID API. Also, as a side note, you can use IOHIDCheckAccess and IOHIDRequestAccess to determine what your app’s current authorization status is.

Having said that, please file a bug on this and post the bug number back here. As background context, the "Accessibility permission" is the general purpose permission for apps that are manipulating the system-wide input stream. I think using it for virtual HID is something we might want to reconsider, as it's giving you significantly more capability than you need/want, since it's allowing you to actively monitor/manipulate the system-wide event stream when all a virtual HID app actually NEEDS to do is blindly "inject" events into the stream. I'm also concerned that it's indirectly encouraging the usage of DriverKit for the same role, something I'm pretty actively against.

Is creating a virtual HID device from userspace via HIDVirtualDevice considered inherently incompatible with Mac App Store distribution?

My understanding is that, in general, apps that require the Accessibility permission aren't eligible for the Mac App Store. However, I don't think that totally matches what HIDVirtualDevice is used for, so it's possible that exceptions to that might be made and/or the required access might change at some point.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I have submitted a bug, tracking number: FB22498595

Perfect, thank you. Clarifying my thoughts here, my personal view is that using "just" HIDVirtualDevice should not require "Accessibility". It's only posting events, so it shouldn't have/need to broker "listen" access "Accessibility" provides.

However, if you want to listen AND post, then that’s what the "Accessibility" permission provides. Similarly, App Reviews concerns about its usage are pretty direct, as that capability is inherently quite dangerous.

One note, for my app, I also need to receive, not just input, events from the event stream, but I don't think that should affect your reasoning, since it's the messages input afterwards that should affect the system.

Input from "what"?

The major concern here is actually receiving the event stream, since that's what opens the door to things like keystroke recorders. While, it's obviously true that a virtual HID device can "control" the system, actually turning that into a "practical" attack is trickier than it might seem. Most actions within the system are driven and routed based on state that isn't actually visible to the "raw" HID system. Mouse motion and click targeting are driven by the current cursor location. The "basic" key event routing is that keyboard events are set to whatever window is currently "key window", but edge cases like global hot keys override that behavior and internal app implementation then override the basic case.

If you're operating purely within the HID API, your app doesn't really have visibility into any of that state, which significantly complicates your ability to actually drive specific actions. You can use "tricks" like using the upper edge "wall" to force the mouse to a particular location or using common global hot keys, but there are limits to what the makes possible and broader system state (like the screensaver or full screen apps) can totally invalidate any given "path".

Finally, thanks for responding, man. I was looking everywhere for information on this, and after reading enough CoreHID posts, I thought, "If I could just talk to Kevin, this should be solvable." 😀

Well, thank you!

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Context for what we're trying to do:

Apple has not implemented FIDO2 support over BLE, so we decided to try and make our own, following the framework we did for Linux.

In short: create a virtual device with the HID descriptor of a FIDO device, receive data from browsers, etc., through the system with the HIDVirtualDeviceDelegate class, repackage these and communicate over BLE, receive an answer, repackage back to USB HID packets, and send back to the system with dispatchInputReport.

Since this communication goes back and forth, we need to be able to both receive and post events.

I assume this is how the PassKeez project I mentioned in the initial post could use it as well.

This might be something Apple does not approve of, and that would be acceptable, but the rejection we got didn't seem to fit that sort of issue.

In short: create a virtual device with the HID descriptor of a FIDO device, receive data from browsers, etc., through the system with the HIDVirtualDeviceDelegate class, repackage these and communicate over BLE, receive an answer, repackage back to USB HID packets, and send back to the system with dispatchInputReport.

Please add these details to your bug, as a big part of what matters here are the details of exactly what kind of device you're trying to present to the system.

This might be something Apple does not approve of, and that would be acceptable, but the rejection we got didn't seem to fit that sort of issue.

So, what triggers the rejection here is that the "Accessibility" authorization you're getting is extremely powerful. In particular, it also controls access to CGEventTap and the AXAccessibility API. Between those two APIs, your app has the ability to modify all interface event activity, as well as access to the Accessibility API that exposes the interface to assistive apps like screen readers. In practical terms, you have enough information and control that your app could make the computer do anything it wanted. That's obviously far more capability than you need/want, but that doesn't change what you COULD do. In any case, that's where App Review's concern comes from.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Added to bug report.

I don't know what the way forward will be, but I suppose any changes in behaviour here will take a long time to reach users, so maybe direct distribution will have to do for now.

I will at least refer to our discussion if the next build is rejected as well.

What is odd to me is that the first version of the app, which is on my personal developer profile, was accepted. It was only rejected when we tried to upload the same app to a company profile. I suppose it might just come down to individual verdicts, and might be off-topic for this thread.

This has become increasingly specific to your specific product, so I'm going to suggest we move this conversation off the forums. When you have a moment, please submit a Code-level support request using this form. As part of that request, please include a link to this thread and mention that I asked you to file it.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware