The safest default is still local, visible, and boring.
Security here is mostly about reducing accidental exposure. The project is at its safest when you keep it local, review your config, and treat the optional Web console like a maintenance panel rather than a public app.
What the repo is designed to protect
- Accidental overlapping runs through wrapper-level lock handling
- Silent failure through `status`, `verify`, `doctor`, and log-health surfaces
- Unsafe Web actions through tokens, scopes, allowlists, and cooldowns
- Path drift through rebuild and reinstall flows
- Public disclosure mistakes through the repository security reporting guidance
Privacy model in one paragraph
Apple Notes Snapshot is local-first. Your notes stay in your Apple Notes account and in the export destination you choose. The repository does not describe a hosted backend, an analytics pipeline, or a cloud account model. The optional Web console and Local Web API are local by default and should remain local unless you have a deliberate reason to expose them more broadly.
Web console and Local Web API safety checklist
Set a long random token first
export NOTES_SNAPSHOT_WEB_TOKEN="<long-random-token>"Prefer loopback
Keep the console bound to `127.0.0.1` unless you have a strong reason not to.
Reduce what the token can do
Use token scopes and action allowlists to shrink the exposed surface area.
If you want the browser/API contract spelled out in operational terms, open the
Local Web API guide or run ./notesctl audit --json.
Proof and current live boundary
If you want the shortest truthful evidence trail, open the proof page. It collects the repo-owned gates, the current GitHub-controlled release and Pages evidence, and the live-boundary reminder that first-run Apple Notes / AppleScript permissions still belong to your machine.
Where to report security issues
Use GitHub private vulnerability reporting when the repository UI exposes it. If you need a private disclosure path first, use the public security contact request template without posting exploit details, note samples, tokens, or full logs.
For the full policy, supported scope, and fallback guidance, read SECURITY.md.
Automated scanners and security tooling can also discover the public security.txt entry published by the Pages site.