Task sync is not one privacy decision. It is a sequence: capture, store locally, choose sync, transmit a payload, keep operational metadata, recover another device, and sometimes let an API act on the list. Each step has a different trust boundary.
Here is the short 2026 data-flow map for private task sync:
| Moment | What can leave the device? | Task-content encryption boundary | Metadata that can still exist | Practical rule |
|---|---|---|---|---|
| Local capture before sync | Nothing required for the first task, if the app supports local or no-account capture. | The task can stay on the device until sync is enabled. | Local device storage, app state, crash logs, or OS backups may still matter. | Use local capture when one-device privacy matters more than continuity. |
| Optional cross-device sync | Task text, list names, IDs, timestamps, list IDs, sort order, deleted state, and sync routing data. | Zero-Friction stores encrypted task text and encrypted list names in the synced task/list rows. | Sync code record, task IDs, client/device IDs, pin state, order fields, timestamps, deletion flags, list IDs, reminder fields, quota/rate-limit records. | Sync gives continuity; it is not the same as zero metadata. |
| Public REST API access | The sync code is sent in the X-Sync-Code header, and API-created task text reaches the server before it is encrypted for storage. | The API encrypts stored task text/list names and decrypts them again for API responses. | Request timing, rate limits, sync-code validation, resource IDs, pagination, pin/reminder/list metadata. | Treat API access as an explicit automation trust boundary, not as provider-blind sync. |
| Reminders and notifications | Reminder text, fire date, recurrence fields, notification IDs, and task references can be stored for scheduling. | The current public reminder API stores reminder fields separately from the encrypted task text fields. | Time, recurrence, notification IDs, task IDs, deletion state, modified dates. | Do not put secrets in reminders; timing can be sensitive even without task text. |
| Backups, exports, and old devices | Local OS backups, screenshots, exports, logs, browser storage, and old synced devices can contain readable data. | App encryption does not automatically sanitize every copy outside the app. | Device backup metadata, file names, exported CSV/text, notification history. | Protect the device and backup path, not only the cloud path. |
Direct answer
Private task sync should be chosen, not assumed. In Zero-Friction Tasks, task text and list names are encrypted for synced storage, but sync still creates IDs, timestamps, ordering, reminder, quota, and routing data. Public API access changes the boundary further because the sync code is sent to the server and the API decrypts content for responses. Use local-only capture for the narrowest surface; use sync when cross-device continuity is worth that trade-off.
Facts checked and method
Facts were checked on October 14, 2026 against the current Zero-Friction download page, encrypted task manager, data protection, public API documentation, local API implementation, NIST Privacy Framework, FTC security guidance, and MDN Web Crypto API documentation.
The checks were:
- Does the first task require a new email account or workspace identity?
- Which user-entered fields are encrypted for storage, and which fields remain operational metadata?
- Does sync or API access send the sync code to the server?
- Does the server process plaintext during the public API path?
- What is recoverable if a sync code, device, backup, or export is lost?
- Is the claim about task-content encryption, metadata minimization, or provider-blind zero knowledge?
For the architecture background, read Server-Side vs Zero-Knowledge Task Encryption in 2026. For the device continuity trade-off, read Why Task Managers Break When You Switch Devices in 2026. For the local-first privacy angle, read Offline-First Tasks Are Privacy Design.
Capture, sync, and API access are different boundaries
The word sync sounds harmless because users experience it as convenience: write a task on one device, see it on another. Privacy-wise, sync is a data movement decision.
Capture is smaller. A task appears, the user writes it down, and the app can store it locally before a server has any reason to see it. That is why no-account first use matters. If the app asks for an email address, workspace, billing state, team, import, calendar connection, or profile before the first task, the privacy boundary starts with identity instead of utility.
Sync is broader. It needs a way to identify which task list belongs together, route data to other devices, reconcile changes, handle deletes, enforce quotas, and prevent abuse. Even when task content is encrypted, the system can still need IDs, timestamps, list references, sort order, sync-code records, rate limits, and device/client hints.
API access is broader again. Zero-Friction's public API documentation says every request must include the sync code in the X-Sync-Code header. The current API implementation validates that code against a stored sync-code record, rate-limits it, and updates last_used_at. For task/list responses, the API decrypts stored encrypted fields using the sync code and returns readable task text or list names. For API-created tasks, the request body contains the plaintext task, and the API encrypts it before storage.
That does not make the API useless or unsafe by default. It makes it a deliberate automation surface. If a script, assistant, or integration needs to read and create tasks, the server has to process that request. The privacy rule is: use the API when automation is worth the extra boundary, and protect the sync code like a credential.
What leaves the device when sync is enabled
The safest way to discuss private sync is field by field.
| Data category | What it means | Storage/sync status in the current implementation | User-facing implication |
|---|---|---|---|
| Task text | The sentence the user types. | Public task API stores text as [ENCRYPTED] when encryption succeeds and stores encrypted content in text_encrypted. API responses decrypt it for the authenticated sync code. | Stored task text is not ordinary plaintext in the task row, but API responses can expose readable text to whoever has the sync code. |
| List name | The project/list label. | Public list API stores name as [ENCRYPTED] when encryption succeeds and stores encrypted content in name_encrypted. API responses decrypt it for the authenticated sync code. | List names get content protection, but they are still readable to API callers with the sync code. |
| Sync code | The private code tying devices/API clients to the task list. | API requests send it in the X-Sync-Code header; middleware validates it against 0F_sync_codes and updates last_used_at. | The sync code is not just a label. Treat it as an access credential. |
| Task IDs and client IDs | Identifiers used to route and reconcile items. | Returned and stored as ordinary fields. | IDs can reveal structure and device/client patterns even without task text. |
| Pin state and ordering | Whether a task is pinned and in what order. | is_pinned, pin_order, and pinned_at are ordinary fields. | A pinned item may reveal priority or workflow shape. |
| List IDs and sort order | Organization metadata. | Ordinary fields on tasks/lists. | Organization can leak context even when names are encrypted. |
| Deleted state | Soft-delete flags and timestamps. | Ordinary fields; deleted items can be queried with the API. | Deletion is workflow state, not automatic secure erasure. |
| Reminders | Fire dates, recurrence, notification IDs, reminder text. | Current public reminder routes store these as ordinary reminder fields. | Timing and recurrence can be sensitive. Keep reminder text boring. |
| Quota and rate limits | Abuse control and plan limits. | Middleware and API helpers use sync-code-based quota/rate-limit checks. | Operational controls can exist without an email account. |
This is the distinction many privacy pages blur. Encrypted task content is one claim. Minimal metadata is a second claim. Provider-blind processing is a third claim. A product can do well on the first and still have honest caveats on the second and third.
Where the key lives, and where it is used
Zero-Friction's API encryption helper derives an AES-CBC 256-bit key from the sync code using PBKDF2 with SHA-256 and a fixed salt. It then encrypts plaintext into an iv:ciphertext format and decrypts that format when the API needs to return content.
MDN's Web Crypto documentation is useful for vocabulary: deriveKey() creates a cryptographic key from initial key material, and encrypt() returns ciphertext from plaintext. MDN also warns that cryptographic primitives are easy to misuse and that key management and system design are hard. That warning is exactly why product privacy claims should explain the full data flow rather than stop at AES-256.
For current Zero-Friction API users, the important sentence is this: the sync code is used server-side by the public API. That means API automation is not provider-blind in the strict zero-knowledge sense. The server can derive the key during an authenticated API request because the request includes the sync code. Stored task/list content is encrypted in the database rows, but the API path intentionally decrypts content for authenticated clients.
Native app sync can still be a good privacy improvement over a conventional account-backed task manager, especially for no-account personal capture. But if your hard requirement is that the service operator must be unable to decrypt task content under every server-side path, you should evaluate the exact client and API behavior, not only the marketing phrase.
Metadata can be more revealing than it looks
A task list is short-form data, but the pattern is rich. A task titled "call doctor" is sensitive. A reminder at 08:00 every weekday may also be sensitive. A pinned task, a deleted task, a list ID, a device ID, a rate-limit event, or a last_used_at timestamp can reveal habits even when the task body is encrypted.
That is why NIST frames privacy as risk management, not only security controls. The NIST Privacy Framework is a voluntary tool for helping organizations identify and manage privacy risk while building useful products. For task apps, that means asking which data is needed for the user benefit and which data exists only because the product architecture made collection easy.
FTC business security guidance points in the same direction: collect only what you need, keep sensitive information safe, and dispose of it securely. In a task app, "only what you need" means not requiring identity before capture, not syncing before the user chooses sync, not processing task content through broad automation by default, and not pretending metadata is meaningless.
Local-only, private sync, or API automation?
Choose the narrowest boundary that still solves the job.
Use local-only capture when one device is enough
Local-only capture is the strongest privacy default when the task list does not need another device. It is useful for sensitive temporary tasks, private notes you will handle today, or a workflow where the phone or laptop is the only trusted place.
Local-only is not magic. The operating system, backups, notifications, screenshots, device search, browser storage, and device theft still matter. But it avoids creating a cloud copy before there is a clear reason.
Use private sync when continuity matters
Use sync when the task must survive device switching. If you capture on Windows and need the same task on iPhone, sync is the point. The Zero-Friction download page currently lists iPhone/iPad, Android, Windows 10/11, macOS Apple Silicon, and Web. It also says the web app needs no download, install, or signup, and that all apps sync with a single sync code.
The trade-off is explicit: task/list content can be encrypted for storage, but sync still needs operational data. If your risk model allows that, private sync is a reasonable compromise. If it does not, keep the task local.
Use API automation when the task should be created by another system
The public API is useful for scripts and agents that need to create, read, update, delete, pin, list, or schedule tasks. It is also the path that most clearly changes the privacy boundary. API calls carry the sync code, and task text is processed server-side before encrypted storage or before being returned to the caller.
Use API automation for narrow, deliberate workflows: "when this monitoring job fails, create a task," or "when this form is submitted, add a follow-up." Do not give the sync code to broad tools that can read everything unless that is exactly what you want.
A practical checklist before enabling sync
Ask these questions before turning a local task list into synced data:
- Do I need this task on another device, or am I syncing out of habit?
- Is the task text itself sensitive, or is the timing/list/pin state also sensitive?
- Which fields are encrypted for storage, and which fields remain metadata?
- Does the sync code ever leave the device in the workflow I use?
- If I use the REST API, which scripts, logs, tools, and error reports can see the sync code?
- Does the app soft-delete or hard-delete records, and what does that mean for old tasks?
- Are reminders stored separately from task text?
- Are device backups, browser profiles, screenshots, notification previews, and exports protected?
- What happens if I lose the sync code or every trusted device?
- Can I start local and enable sync only when the benefit is concrete?
The answer does not need to be paranoid. It needs to be explicit.
Who Zero-Friction is for, and who it is not for
Zero-Friction Tasks is for people who want private first-mile capture without turning every thought into an account-backed workspace. It fits users who need to save personal tasks quickly, try the app without signup, use a sync code instead of an email login, and choose cross-device continuity when the benefit is worth it.
It is also for users who can accept a pragmatic sync model: encrypted stored task/list content, no-account first use, cross-platform apps, and a public API for deliberate automation. That is a useful privacy posture for personal capture, especially compared with a cloud planner that requires identity before the first task.
Zero-Friction is not for teams that need assignments, comments, roles, shared boards, SSO, SCIM, legal hold, administrator reporting, or manager-controlled recovery. It is also not the right fit for users whose requirement is strict provider-blind zero-knowledge across every API path. If a system must be technically unable to decrypt task content under all server-side processing, audit the implementation and choose a tool designed for that exact threat model.
The 2026 rule for private task sync
Do not ask only, "Is sync encrypted?" Ask what leaves the device, which fields are encrypted, where the key is used, what metadata remains, and which path you are using.
Local capture has the smallest surface. Private sync adds continuity and metadata. API automation adds power and a server-side processing boundary. A good task app should make those steps visible instead of bundling them under one vague privacy label.
Download Zero-Friction Tasks if you want private no-account capture with optional sync across iPhone, Android, Windows, macOS, iPad, and Web. Read the encrypted task manager page for the product's encryption model, and treat API automation as a separate trust decision.
Official sources checked
- Zero-Friction Tasks: download page, encrypted task manager, data protection, and public API documentation.
- Zero-Friction implementation checked at commit
9fceb8395235656cd4f0d333ce6fe346183d2fdb: API encryption, sync-code authentication, task routes, list routes, pin route, reminder routes, and OpenAPI spec. - NIST: Privacy Framework.
- FTC: Start with Security: A Guide for Business.
- MDN Web Docs: Web Crypto API, SubtleCrypto.deriveKey, and SubtleCrypto.encrypt.