Critique of a Hardware-Based Mac Control Loop
Your idea for a hardware bridge to control a Mac via HID/Accessibility without target software is technically sound but faces several 'real-world' hurdles.
Technical Critique:
- What breaks first? The Security/Privacy TCC prompts. Even with HID emulation, macOS will pop up 'Allow this device' or 'Accessibility access' prompts that require a physical click or existing trust.
- Security Concerns: This is a 'Rubber Ducky' style attack vector. Modern macOS (Sequoia+) has USB Restricted Mode, which blocks new HID devices if the Mac has been locked for more than an hour.
- Genuine Use: This would be invaluable for headless server recovery or automated testing of OCLP installations where the UI is unaccelerated and traditional VNC is too slow.
Original Question: "Seeking technical feedback on Mac-to-Mac control via accessibility + HID"
I’m working on a small hardware bridge that lets one Mac assist/control another via accessibility and HID, without installing software on the target machine.
The problem I’m trying to solve is reliable remote interaction with a second Mac in situations where software install/admin access is a bad fit.
I’d love feedback from people who’ve worked on accessibility automation, HID/device emulation, or low-latency control loops:
• what would you expect to break first?
• where would trust/security concerns show up?
• what would make this genuinely useful vs just a neat hack?
I’m especially interested in critique, not hype.
[link] [comments]
Post a Comment