Please don't open a public issue for security problems.
Use GitHub's private vulnerability reporting instead — it's enabled on this repository and goes straight to the maintainer without disclosing anything publicly.
This is a small side project, not a funded product. Expect a reply within a week or two, and please be patient if a fix takes longer.
Only the latest release gets fixes. Older versions are not patched.
| Version | Supported |
|---|---|
| 1.1.x | Yes |
| < 1.1.0 | No — and the permission model changed, see README |
Dock Lock requires Accessibility permission, which is a powerful grant, so it's fair to want to know what it does with it.
It installs a Core Graphics event tap (EventTapManager.swift) that watches for exactly three event types:
mouseMovedleftMouseDraggedrightMouseDragged
Keyboard events are not in that list. The app cannot see what you type, and this is
verifiable in three lines of source. When an event's location falls inside a blocked band the
tap returns nil to drop it; otherwise it passes the event through untouched. It never
creates or modifies events.
What the app does not do:
- No network requests of its own — the only outbound traffic is Sparkle checking for updates
- No telemetry, analytics, or crash reporting
- No logging of user activity
- No reading of files, clipboard, screen contents, or other applications' data
- Nothing is stored except your chosen display's ID and an on/off flag, in
UserDefaults
Updates go through Sparkle:
- The appcast is fetched over HTTPS
- Every release archive is signed with an Ed25519 (EdDSA) key, and Sparkle refuses any update whose signature doesn't verify against the public key embedded in the app
- Compromising this repository alone is not enough to push a malicious update — the signing key is held offline and is not in this repository or in CI
Because there is no CI pipeline, releases are built and signed on the maintainer's machine. That means the update channel's security rests on that key staying private.
Dock Lock is signed with a self-signed certificate, not an Apple Developer ID, and is therefore not notarized. Two consequences you should know about:
- macOS blocks the first launch and you have to click "Open Anyway". The install steps in the README walk through it.
- Apple has not scanned this binary for malware. With a notarized app you get that check
for free; here you're trusting the source and the signature instead. The source is public,
and you can build it yourself with
./build.sh.
Why self-signed rather than ad-hoc is explained in docs/SIGNING.md — it's what allows the Accessibility permission to survive updates, which ad-hoc signing does not.