Trust You Earn by Staying Narrow

"The user handed you the keys to every app. What you do with keys you'll never need is the whole measure of the tool."

The Grant Is a Trust, Not a Transaction

Granting Flint Accessibility permission is not a small checkbox — it's handing over the ability to read and drive every app on the machine. The user does that trusting the tool will act narrowly inside a power that is enormous. That grant is a relationship, not a one-time transaction: it obligates Flint, every time it runs, to behave as if the trust could be withdrawn the moment it's abused. Security, in the end, is what you do with power the user can't watch you use.

Earned, Not Assumed

The wrong mental model is 'the user consented, so anything within the permission is fine.' Consent to a broad capability is not consent to use all of it. Flint treats the grant as trust to be continuously earned, not a blank check to be spent. That reframing changes behavior: instead of asking 'is this technically allowed by the permission?' it asks 'is this within the narrow thing the user actually wanted?' The permission is the ceiling; the intended job is the room you stay in.

THE USER GRANTS              FLINT OWES IN RETURN
--------------------------  ----------------------------
read any app                read only the focused selection
type into any field         insert only the proven target
access to everything        never a secure field, never a secret
(implicitly) their trust    narrow use, visible action, local default

The Three Ways Flint Earns It

Concretely, Flint earns the grant three ways. It stays narrow: it reads the focused selection and inserts one proven result, never roaming other apps or windows. It stays visible: results that can't be safely inserted surface on the clipboard with a message, so nothing happens silently. And it stays local by default: personal and sensitive text doesn't leave the machine unless a macro explicitly sends it, so the sweeping read permission rarely turns into data crossing the network. Narrow, visible, local — three habits that together turn a scary permission into a trustworthy tool.

A broad permission obligates narrow behavior — the wider the grant, the tighter the self-restraint it demands. The relationship is inverse: the more a user must trust you with, the less of that trust you should actually spend. Powerful permissions are not licenses to act everywhere they technically reach; they are responsibilities to act only where you were invited. A tool that treats a broad grant as permission to roam has misread trust as entitlement.

This is how the whole family treats power. Flint is one instance of a pattern that runs through every cwk tool: the capabilities are strong, and the discipline is to use them narrowly, keep them local, and make the actions visible. Trust isn't a setting you switch on; it's the accumulated result of a tool never once doing the alarming thing it easily could. You build it the same way every time — by being narrow when nobody's checking.

Code

The permission is a ceiling; the intended job is the room·swift

// The permission technically allows reading ANY element in ANY app.
// Flint's own code refuses almost all of that reach on purpose.
func snapshot() -> TargetSnapshot? {
    guard let element = focusedElement() else { return nil }   // only focused
    guard !isSecure(element) else { return nil }               // never secrets
    // Read ONLY this element's selection. Not the window, not siblings,
    // not other apps — even though the permission would allow all of it.
    return TargetSnapshot(element: element,
                          selection: selectedText(of: element))
}
// The narrowness isn't enforced by macOS. It's a promise Flint keeps itself.

Exercise

Accessibility permission technically lets Flint read every window of every app. List three things it could do that would stay strictly 'within the permission' yet clearly betray the user's trust. Then describe the three habits — narrow, visible, local — that keep Flint's actual behavior far inside the ceiling the permission sets, and explain why 'the user consented' is not a sufficient justification on its own.

Hint

It could harvest text from background windows, read a document the user didn't act on, or quietly send everything it reads to a server — all technically permitted, all a betrayal. The three habits: narrow (only the focused selection, never a secure field), visible (unsafe results surface on the clipboard with a message, nothing silent), local (personal text stays on-device unless a macro explicitly sends it). 'The user consented' fails because consent to a broad capability is not consent to spend all of it; the grant is a ceiling, and trust lives in how far below it you choose to operate.

Trust You Earn by Staying Narrow

The Grant Is a Trust, Not a Transaction

Earned, Not Assumed

The Three Ways Flint Earns It

Code

External links

Exercise

Progress

Comments 0