cyberWriter — Security & Privacy White Paper

Why a writing app should never become your next breach headline

A technical and privacy overview for security-conscious users, IT reviewers, and healthcare professionals.

TL;DR

cyberWriter is local-first by design, not by accident. Your documents live on your Mac. There is no account, no cloud sync, no server that holds your writing. The app is sandboxed, signed, notarized, and updated through Apple — which means the most common ways modern software gets weaponized simply have no surface to attack here. When you want AI assistance, cyberWriter runs models on your own device wherever possible, so your words don't have to leave the machine to be useful.

This isn't minimalism. It's a deliberate threat model for an era where the supply chain is the attack.

1. The threat landscape isn't theoretical anymore

Three patterns now define how data gets stolen. None of them require attacking you directly.

Healthcare is the prime target — and the breaches are catastrophic.
The 2024 Change Healthcare attack is the largest healthcare data breach in U.S. history: an estimated 192.7 million people had medical records, Social Security numbers, diagnoses, and payment data exfiltrated — more than half the country. Entry point? A remote-access portal without multi-factor authentication. The company paid a $22 million ransom and the data was retained and re-extorted anyway. Paying didn't make the exposure go away — because the data had already left the building.¹

The software supply chain is being poisoned at the source — and it's accelerating.
In 2025, the Shai-Hulud worm became the first self-replicating npm supply-chain attack — it spreads with no command-and-control server by reading its own code and republishing itself through any developer credentials it finds. Successive waves backdoored 796 packages with ~132 million monthly downloads.² Around the same time, the popular tj-actions/changed-files GitHub Action — used by 23,000+ repositories — was compromised (CVE-2025-30066); attackers rewrote existing version tags to point at malicious code, dumping CI secrets into build logs across thousands of projects at once.³

It did not slow down in 2026. "Mini Shai-Hulud" campaigns hijacked trusted scopes including Red Hat and SAP npm packages to harvest GitHub/npm tokens and AWS/Azure/GCP/Kubernetes secrets.⁴ By June 2026, the IronWorm / Miasma campaign poisoned 50+ legitimate packages, again self-replicating across dependency graphs — but now pairing the credential-stealer with an eBPF kernel rootkit that survives reboots and evades traditional endpoint detection (EDR).⁵

The lethal property these share: one upstream compromise instantly poisons every downstream installation. A single hijacked dependency, build action, or auto-update channel reaches every machine that trusts it — silently, at the next install or update. And once malware lands in an app with broad, unsandboxed reach, it can dig in at the kernel level. The more plugins, dependencies, and unconstrained system access an app has, the wider that blast radius — and the deeper an attacker can persist.

2. cyberWriter's answer: remove the surface, don't just guard it

The strongest security control is the one where the risk structurally cannot exist. cyberWriter is built around four such decisions.

No account. No cloud sync. No server holding your work.

The Change Healthcare lesson is brutal but simple: data that's centralized is data that can be stolen in bulk. cyberWriter has no backend that warehouses your documents, so there is no honeypot to breach, no credential portal to leave un-MFA'd, no bulk export for a ransomware crew to exfiltrate. Your files sit in plain Markdown in a folder you control. We can't lose what we never collect.

No plugin system. On purpose.

Every "extensible" editor answers the supply-chain era with a marketplace of community plugins — hundreds of third-party developers whose code runs with the app's full privileges, next to your documents, updated on their own schedule. That is precisely the blast radius Section 1 describes, reproduced in miniature on your Mac. cyberWriter's answer is structural: there is no plugin system. Live API tables, charts, diagrams, math, drawings, the knowledge graph, on-device AI — all of it is built into one signed, reviewed binary. You get the power of an extended editor with the audit surface of a single vendor. Nothing to vet plugin-by-plugin, no third-party code execution path to police, no marketplace update you didn't approve.

Sandboxed by macOS.

The Mac App Store and Setapp builds of cyberWriter run feature-complete inside Apple's App Sandbox — every capability in this paper, with no sandbox carve-outs. That was a deliberate engineering effort: most "power-user" editors abandon the sandbox to get features. cyberWriter keeps the features and the cage. (Precision matters, so here is the one exception, disclosed rather than glossed: the direct-download build runs unsandboxed solely so its Sparkle updater can install updates — a documented macOS limitation, not a feature difference. If your environment requires the sandbox, install from the App Store or Setapp; they are the same app.) Sandboxing means the app can only touch what you explicitly grant it (via security-scoped bookmarks) — it cannot quietly roam your filesystem, phone home, or be repurposed as a foothold into the rest of your machine. When attackers are now shipping kernel-level rootkits through poisoned packages (see IronWorm/Miasma above), the difference between "an app confined to a sandbox" and "an app with unrestricted system access" is the difference between a contained incident and a compromised machine.

Signed, notarized, and inspected by Apple.

Every release is code-signed and passed through Apple's notarization pipeline, which scans for malware before the binary is allowed to run. Updates flow through that same trusted, signed channel. Compare that to the supply-chain attacks above, where the update mechanism itself was the weapon. An attacker can't silently swap cyberWriter's binary out from under you the way a tampered package or hijacked CI tag poisons an unsandboxed app — the signature would break and notarization would reject it.

Plain files, open formats, no lock-in.

Your content is Markdown on disk — readable, portable, and yours whether or not cyberWriter exists tomorrow. No proprietary database to corrupt, ransom, or hold hostage.

The throughline: every one of these was chosen for hardening, not convenience. "No sync" isn't a missing feature — it's a deleted attack vector. "Sandboxed" isn't a limitation — it's a containment boundary. "Local files" isn't old-fashioned — it's the absence of a breachable vault.

3. Local AI: more powerful than the industry wants you to notice

AI is now core to writing — but almost every major tool routes your text to their cloud, on their metered credits. There's a reason for that, and it isn't your safety: the business model is selling you sharded cloud-AI capacity. Meaningful on-device AI undercuts that revenue, so the big players have little incentive to ship it well.

On-device models have quietly gotten good enough to change the calculus. cyberWriter supports AI that runs entirely on your Mac:

• Apple Intelligence (Foundation Models, on macOS 26) — zero-config, on-device, no key, no network.
• Ollama and MLX — run capable open models locally.

When you use local AI, your sentences are processed on your own silicon and never leave the device. That's simultaneously:

• Safer — no third party receives your draft; nothing to log, retain, train on, subpoena, or breach.
• Cheaper — no per-token credits, no subscription to a model vendor for routine work.
• Always available — works on a plane, in a SCIF, on a locked-down clinical network with no outbound AI access.

For sensitive fields, "the AI ran locally" is a far stronger guarantee than any vendor's data-handling promise — because the data was never theirs to mishandle.

4. Honest disclosure: where data does leave (and how to stay clean)

We won't pretend the boundary is invisible. cyberWriter also lets you connect cloud AI providers (e.g. Claude, OpenAI-compatible endpoints) using your own API key. When you do, the text you send goes directly from your Mac to the provider you chose — cyberWriter is not a middleman that stores or sees it. But that content does leave your device and is subject to that provider's terms.

API credentials never touch your documents. cyberWriter's live-data blocks can call APIs you configure — and the keys live only in the macOS Keychain, stored WhenUnlockedThisDeviceOnly (never synced, never exportable to another machine). Documents reference them as {{secret}} placeholders; the key material is injected at request time, redacted from the on-disk request history, and a block only ever runs when you click Run — documents cannot execute network calls by merely being opened.

No telemetry. There is no analytics or crash-reporting SDK in the binary, no usage tracking, no phone-home. The complete list of ways bytes can leave your Mac: (1) opt-in cloud AI, under your key, directly to your chosen provider; (2) a live-data block you explicitly Run; (3) a chart whose author bound it to a remote data URL; (4) the update check (App Store/Setapp via Apple; direct build via its signed Sparkle feed); (5) license activation on the direct build; (6) the feedback form, when you send it. Every one is user-initiated or channel-inherent — none carries your documents.

Guidance for regulated or sensitive content (including PHI):

• Use on-device AI (Apple Intelligence / Ollama / MLX) for anything sensitive — it never transmits.
• Treat cloud AI as you would any outbound disclosure: only with non-sensitive content, or where you (or your organization) hold the appropriate agreements (e.g., a BAA) with that provider.

The architecture gives you a clean, local-only path. The cloud path exists for convenience and is entirely opt-in, per provider, under your key.

5. What this means for healthcare & HIPAA-minded users

cyberWriter is a writing tool, not a regulated medical system, and we make no certification claims. But the architecture lines up with the principles that actually prevent healthcare breaches:

In plain terms: the safest place for sensitive writing is a machine you control, running an app that doesn't try to take a copy. cyberWriter is built to be exactly that — and where it can't be (opt-in cloud AI), it tells you plainly.

You don't have to trust us with your data.
We designed the app so you never have to hand it over in the first place.

cyberWriter — a native, sandboxed, local-first Markdown editor for macOS.