Some permissions are broad because the feature itself is broad.
A screen reader must understand what is on the screen.
An automation tool may need to control another application.
A third-party keyboard has to process what a person types.
Those legitimate requirements create unusually powerful observation channels if the same access is misused.
A keyboard can handle extremely sensitive input
Apple’s developer documentation makes the tradeoff unusually explicit for iOS custom keyboards.
By default, a custom keyboard runs in a restricted sandbox without network access. A developer can request open access, and the user must explicitly enable “Allow Full Access.” With that capability, Apple says the keyboard can send keystrokes and other input events to a server for processing and can access additional resources such as shared containers; other data such as contacts or location still require their own permission.
Apple warns developers that keyboards handle some of the most sensitive user data and says open access should not be enabled lightly. See Configuring open access for a custom keyboard.
That does not mean a full-access keyboard is malicious.
Cloud prediction, advanced language models, synchronization, and other useful features may require network communication.
The issue is that the permission creates capability well beyond drawing letters on the screen.
Accessibility access can be broader still
Android’s AccessibilityService exists so software can assist people who need help interacting with applications. Depending on how the service is configured, Android allows an accessibility service to receive UI events, retrieve the active window’s content, inspect interface elements, and perform actions on the user’s behalf.
Google’s documentation explicitly notes that retrieving the view hierarchy can expose private user information. See the AccessibilityService API reference and accessibility-service developer guide.
On macOS, Apple’s privacy settings similarly describe Accessibility permission as allowing approved apps to run scripts and system commands that control the Mac. See Apple’s Privacy & Security settings guide.
Capability is not evidence of abuse
This distinction is essential.
A password manager, screen reader, voice-control system, automation utility, or alternative keyboard may need unusually broad access to perform its advertised job.
Finding the permission does not prove that the program records everything it can see.
A stronger audit asks:
- What specific feature requires the permission?
- Does the app send observed information off-device?
- What does its privacy policy say?
- Can the feature operate with narrower access?
- Is collection limited to the period when the feature is active?
- Has independent analysis observed unexpected network transmission?
The permission tells you what software can do.
Network traces, source code, documentation, or enforcement records tell you more about what it does do.
The Surveillance Economy is easy to misunderstand if capability and conduct are treated as synonyms.
Broad access deserves scrutiny.
It does not deserve an automatic conviction.