Security & trust
Your files stay yours — and we tell you where we are still limited
Your files are never uploaded to our servers. Encrypted cloud backups can only be read with a key that stays on your devices. And Syncra keeps the previous copy before it replaces or deletes anything.
Last reviewed:
Principles that keep your data from being lost
These are rules of the sync engine itself, not settings you have to find.
The old copy is kept first
Before Syncra replaces or deletes a file, the previous copy moves to a version store (.syncra/versions). Restoring a version keeps the current file as a version too, so a restore can be undone. Versions are kept for the retention period you set.
Large deletions stop and ask
If a run would delete a large share of a folder, it stops and waits for your confirmation. This guard cannot be switched off — only its thresholds can be adjusted — and AI or MCP agents cannot lift it on their own; a human confirmation is required.
Plan first, then run
Every change is planned and previewed before it happens. An AI assistant connected through MCP can only run a plan that was previewed first, and if files changed in the meantime it has to plan again.
Both versions survive a conflict
When a file changed on both sides, Syncra keeps both versions side by side instead of letting one overwrite the other.
Safe writes, inside your folders
Partial files are written under a temporary .syncra-part name and swapped in atomically. Symbolic links are not followed, and paths cannot escape the synced folder.
No unsafe code in our core
The sync engine, networking, cloud, service, daemon, AI and MCP crates and the desktop shell are compiled with #![forbid(unsafe_code)], so memory-unsafe code cannot slip into them by accident. Third-party dependencies are not covered by this.
Encryption and key management
Syncra has three data paths, and each one has its own protection.
Cloud backup with encryption turned on
File contents are encrypted on your PC before upload, in 64 KiB chunks with XChaCha20-Poly1305 under a random 256-bit key. Every chunk authenticates its position and the file's full path inside the remote, so a changed byte, reordered or cut-off data, a swapped file or the wrong key is detected when reading. The cloud provider sees only ciphertext.
Where the keys live
The key and your recovery key are kept only in your operating system's secure credential store (Windows Credential Manager, macOS Keychain, Linux Secret Service), next to your other cloud secrets. They are never written to config files and never sent to Syncra. The recovery key opens the backup on another PC. If you lose both the key and the PC, nobody — including us — can recover those files.
Direct sync on your network
Devices pair with a QR code or code, a one-time secret and a six-digit comparison code. Connections use QUIC with TLS 1.3 and pinned device public keys instead of certificate authorities, and data chunks are sealed with XChaCha20-Poly1305. Nothing passes through our servers.
Who can see what
| Data | Your devices | Syncra servers | Your cloud provider |
|---|---|---|---|
| File contents of an encrypted cloud remote | Readable | Never received | Ciphertext only |
| File contents synced over your network | Readable | Never received | Not involved |
| Encryption key and recovery key | In the OS credential store | Never received | Never received |
| Folder structure, number of files, approximate sizes and modified times of an encrypted cloud remote | Readable | Never received | Visible — file and folder names themselves are encrypted on remotes created with desktop 0.1.3 or later |
| Account data: email, name, device public keys | Yours | Stored (see the Privacy Policy) | Not involved |
| Card details | Entered at the payment provider | Never received | Not involved |
Encryption is something you turn on for each cloud remote, and it cannot be turned off afterwards. A remote without it stores your files as ordinary files at the provider. On servers without an OS credential store, secrets go into an encrypted file whose limits are described in the documentation.
Accounts and devices
The control plane (accounts, teams, billing, device list) never sees your files. This is how it protects what it does hold.
Signed device requests
Every device has its own Ed25519 key pair. A request is signed over the method, path, timestamp, a one-time nonce and a SHA-256 hash of the body. The server accepts each nonce once and rejects requests more than five minutes off, so a captured request cannot be replayed. Revoking a device stops it immediately.
Sign-in
You can sign in with an email link, a Google account or a passkey. Session tokens are stored on the server only as hashes. Browser sessions are protected against cross-site requests with a CSRF token and an origin check.
Secrets encrypted at rest
Payment provider keys and other operator secrets are sealed with AES-256-GCM before they are stored, under a key kept as a platform secret, and are never returned to the browser.
Payments without a webhook to spoof
We expose no inbound payment webhook. Prices are decided on the server only; after a payment the server asks the payment provider directly to confirm it and re-checks pending payments every ten minutes. Card details stay with the payment provider.
An audit log that cannot be edited
Account, device and team actions are written to an audit log whose table refuses UPDATE and DELETE at the database level. Business workspaces can export it.
Ransomware and recovery
A sync tool can spread damage as fast as it spreads work. Syncra is built to stop that.
It stops by itself
Syncra looks for signs of mass damage on your device: bulk extension changes, high-entropy overwrites, sudden mass edits or deletions and ransom-note file names. When the score reaches the pause level, the pair goes into protection and every automatic and manual run is refused until a person resumes it, so damage on one side cannot reach the other. AI agents cannot resume it.
One-click recovery
Recovery restores each unaffected side to the last clean time, makes the affected side identical to the clean side again, and then lifts protection. Damaged files it replaces are moved into the version store, never deleted.
Point-in-time restore
Bring a whole side or a sub-folder back to how it looked at a chosen moment, rebuilt from the version store and the audit log. A restore destroys nothing and is itself recorded, so it can be undone with another restore.
Detection is heuristic: it can miss an attack or raise a false alarm (you can dismiss it). Changes made directly in a folder outside Syncra are not recorded, so point-in-time restore cannot roll them back — recovery then copies the clean side back. None of this replaces an offline or off-site backup.
What you can verify
We cannot ask you to take our word for everything, so here is what you can check yourself.
Signed releases
Windows installers and the command-line tool are signed with a code-signing certificate issued to PROJECTTEAMFORYOU. The release pipeline refuses to publish a file whose signature or timestamp does not verify, and the SHA-256 checksums (SHA256SUMS) are computed after signing, so you can compare what you downloaded.
Watched dependencies
Dependabot proposes dependency updates every week, and every change is checked against the RustSec advisory database and a high-severity npm audit in continuous integration.
A strict website
Pages carry a Content Security Policy that allows only scripts whose hash is listed for that page, HSTS, a ban on framing and no sniffing of content types. The web app processes folders inside your browser and uploads nothing.
A plain security.txt
Our security contact and reporting policy are published at /.well-known/security.txt, the standard place for researchers to look.
Report a vulnerability
Email [email protected] with the subject “Security”. Please do not open public issues or post details before we have had a chance to fix the problem. Reports in English or Korean are welcome.
Please include
- What you found and the affected component or URL
- Steps to reproduce, or a proof of concept
- The version or build you tested
- How we can reach you
Our response targets
- We acknowledge your report within 3 business days.
- We share an initial assessment within 7 days.
- We aim to ship a fix or mitigation within 14 days for critical issues and 90 days for others.
These are targets, not guarantees. We will not take legal action against good-faith research that avoids other people's data and service disruption. We do not run a paid bug bounty at the moment.
Current limits
A page like this is only worth reading if it says what is missing.
No independent audit yet
Syncra has not been reviewed by an independent third party, and it holds no security certification such as ISO 27001 or SOC 2. Everything on this page is our own description of how the software is built.
Our source code is private
You cannot read the code yourself today. That is why we publish the design facts above and sign and checksum our releases.
Cloud encryption does not hide structure
File and folder names are encrypted on new encrypted remotes (desktop 0.1.3 or later), but folder structure, number of files, approximate sizes and modified times stay visible to the cloud provider. Remotes created earlier keep readable names, and encryption must be turned on per remote.
A compromised PC is out of reach
If malware controls your computer while you are signed in, it can reach whatever your account can reach, including the OS credential store. Syncra does not replace endpoint protection or an offline backup.
Lost keys mean lost data
Because only you hold the encryption and recovery keys, we cannot recover an encrypted backup if you lose both.
Roadmap
Plans, not promises: none of these has a date.
Independent security assessment
We are preparing for an independent review: scope, threat model, data-flow documentation and a dependency inventory. No assessor or date has been agreed.
Public threat-model summary
Publishing a summary of our threat model, with the risks we accept, so that it can be criticised.
Single sign-on for Business
Sign-in through a company identity provider for Business workspaces is planned.
Questions about security?
Write to [email protected]. We answer what we can and say so when we cannot.