Dev.to Security πŸ” Cybersecurity πŸ‘ 0 πŸ“– 7 min read

Why a Mac Writing Helper Needs Two Permissions, and Why It Still Refuses Password Fields

A writing helper that works inside someone else's text field has to ask macOS for a lot of trust. Accessibility permission is how an app reads and, if you approve it, replaces text in another app. Input Monitoring is how

A writing helper that works inside someone else's text field has to ask macOS for a lot of trust. Accessibility permission is how an app reads and, if you approve it, replaces text in another app. Input Monitoring is how it can see keyboard events while you are in Mail, Notes, or a browser. Those are two different Privacy & Security toggles, and they should be. People are right to pause on both.

We build DraftKey, a Mac app for Tab autocomplete and rewrites you review before they are inserted. This post is about the permission model behind a helper like that: why two system permissions are required, how we ask for them, and the cases we refuse even after you have said yes. The general mechanics come from Apple's public documentation, linked at the end. The product rules come from the shipped app's own wording, including the Apps & privacy section in Settings.

Two panes, two jobs

Apple documents these as separate resources, and System Settings treats them that way.

Accessibility is under Privacy & Security. It is the permission that lets an app control your Mac on your behalf: read user interface elements, including text, and change them. A Mac app can ask whether it is a trusted Accessibility client with AXIsProcessTrustedWithOptions. If the process is not trusted, it cannot usefully work in another app's field. The honest usage description is therefore about suggestions and about replacing text only when the user approves, not about "making writing nicer" in the abstract.

Input Monitoring is a different list. Apple's own support page is blunt about what it means: some apps can monitor your keyboard, mouse, or trackpad even when you are using other apps. You turn that ability on or off per app. Apple's documentation for resetting TCC access even uses a different service name for it, ListenEvent, alongside a separate PostEvent service for sending keystrokes and a separate Accessibility service. If you have ever wondered why a shortcut utility and a window manager can end up in different panes, that split is why.

DraftKey needs both, for different reasons. Reading a compatible text field, and writing a rewrite back after you press Insert, is an Accessibility job. Noticing Tab when a suggestion is showing, or Command-Option when you want Writing tools, is a keyboard job. Typing sounds, which are a separate feature you can turn off, also need keyboard access. The in-app prompts say so directly: "Allow Input Monitoring for shortcuts and typing sounds," and "Allow Accessibility and keyboard access in DraftKey."

Lumping those into one explanation is how permission dialogs start to sound like a blank check. Keeping them separate is more work in onboarding, and it is clearer.

Ask, then get out of the way

The system already has a prompt and a Settings pane for each permission. The useful work in the app is not inventing a third one. It is sending people to the right pane, then noticing when they come back.

DraftKey's onboarding copy is: "Approve DraftKey in the macOS prompt or System Settings, then return here." Settings also has a Refresh permissions action. That sounds minor until you remember how often a Mac permission is granted to one build, then seems to vanish after a move, a rename, or a reinstall. Apple publishes a tccutil-based reset procedure for developers for exactly this class of problem. Users should not have to learn that command. They should have a button that re-checks trust and, if needed, opens the same Privacy & Security pane again.

A good permission ask is specific about what you will and will not do. "Allow access to your keyboard and supported text fields" is narrower than "allow this app to control your Mac," and it is closer to the truth. It also leaves room for the next section, which matters more than the wording of the dialog.

Permission granted is not permission everywhere

Once both system toggles are on, the dangerous default is "every text field, every app." We do not take that default.

Settings includes an Apps & privacy section whose subtitle is "Choose where DraftKey works." You can turn writing help off for an individual app. If you invoke it in a place that is turned off, the app tells you: "Writing help is turned off for this app. Review Apps & permissions in DraftKey." That is an allowlist you can edit, not a one-time consent that silently covers the whole machine.

Some exclusions are not optional, and they are not buried.

  • Password fields are always excluded.
  • Password managers always exclude writing help and typing sounds.
  • Terminals start with sounds only. Writing help is off there until you change it.
  • When secure input is active, writing help is unavailable. The message is: "Writing help is unavailable while secure input is active. Click a normal text field and try again."

The last two points are worth unpacking, because they are easy to misread as bugs.

Apple's NSSecureTextField is the standard password field. It displays bullets instead of characters and does not allow cutting or copying its contents. A writing helper that suggested the next word in a password field, or offered to "rewrite" it, would be doing the wrong thing even if the user had granted Accessibility. So the rule is not "skip password managers we recognize." It is "skip password fields, wherever they appear."

Secure input is broader than a single field. When a Mac app enables secure keyboard entry, the system is telling other processes to stop observing those keystrokes. Apple documented the fair use of this mechanism years ago in Technical Note TN2150, Using Secure Event Input Fairly: turn it on only while sensitive input is happening, and turn it off afterward, because leaving it on breaks other software. From the helper's point of view, the only correct behavior while secure input is on is to refuse. If a password prompt is in front, or a terminal has Secure Keyboard Entry enabled, DraftKey should not try to be helpful. It should wait until you click a normal text field.

Terminals are a softer default, not a hard ban. A terminal looks like a text field, and some of what people type there is just a commit message. A lot of it is not: commands, tokens, remote sessions. Starting with sounds only, and leaving writing help off, means the app is present without reading shell input until you opt in for that specific app. You can still enable it if your actual use is writing prose in that window. The default assumes you might not be.

Compatible fields, not every app

Even in apps you have allowed, support depends on how the editor exposes its text. Some custom editors do not. DraftKey is a helper for compatible text fields, not a claim that every Mac app will work. That limit belongs next to the permission talk, because a user who has just opened Accessibility and Input Monitoring deserves an accurate picture of what those permissions buy.

The same honesty applies to what the app does after you grant them. Tab autocomplete suggests the rest of a sentence and adds it only when you accept it. A rewrite opens a preview, and nothing is written back until you choose Insert. Those are separate actions, and both are opt-in at the moment of use. Granting a system permission is not the same thing as accepting a change.

What I would tell anyone asking for these permissions

  1. Treat Accessibility and Input Monitoring as different asks. They live in different panes because they do different things. Explain each one in a sentence, not as a bundle.

  2. Send people to System Settings, then detect the return. A custom primer screen cannot grant the permission for them. A refresh action can close the loop.

  3. Do not let system consent become app-wide access. Give people an apps list. Default sensitive classes off, or exclude them entirely.

  4. Refuse password fields and secure input, even if the APIs would let you try. If your feature is writing help, those contexts are not writing.

  5. Say "compatible text fields" and mean it. A permission grant does not make an inaccessible editor accessible.

Where DraftKey fits

If you want to try the result, DraftKey needs an Apple Silicon Mac on macOS 14 or later, and its writing features need at least 8 GB of memory and a separate writing-model download of about 1.12 GB, with at least 2.2 GB of free space. Every Mac gets 500 free words of writing help. After that it is $4.99 once, for up to three Macs you own. It works in compatible text fields, password fields are excluded, and some custom editors are not supported. You can read more about it here.

If you ship a Mac app that needs Accessibility or Input Monitoring, how do you explain the ask without making it sound like a blank check? And which apps did you default to off?

Sources

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.

Share 𝕏 Twitter ✈ Telegram β†— Reddit 🟧 HN
← News πŸ” Cybersecurity 🏠 Home