Security statement

This statement explains how NotionManager protects your data and your credentials, and where our limits are. It complements the Privacy Policy: the Privacy Policy answers what we collect, and this statement answers how we protect it and what we do not promise. Every technical description here comes from the current version's implementation and release process.

This document covers only who can get to your data. What a backup contains, when it will not be complete, and how to check that it works is a different question, answered in the companion Data integrity statement. Each document covers one subject and does not repeat the other.

Security is a property of the whole

Security is not a feature. It is a property of the whole system once it is running in a real place. Good design is the starting point, but the environment around it often decides the outcome more than the design does: who logs in to this machine, whether the disk is encrypted, what medium the backup ends up on, who else is on the network, and which pages the integration was shared with in Notion. Most of that is not under our control.

So what we can do is hold the software side. NotionManager works hard not to expose you to risk and not to widen the attack surface. In practice that means we add no channel we cannot answer for (no telemetry, no background auto-update, no relay server), we ask only for the permissions the work needs (read-only on Notion), and we keep sensitive information on your own machine. Where we fall short (the local network service has no TLS, the key for local encryption ships with the program, the installer is not yet signed) we write it down plainly instead of wording around it.

Read this document in two parts. The first sections cover what we do. Section 9 covers what we do not do and what we need from you. Security comes from a program as small as we can make it plus an environment you understand and control. Take away either half and it does not hold.

Summary

• NotionManager is a local-first desktop program: backups, indexing and browsing all happen on your own machine, and we run no server that receives, views or stores your Notion content.
• The app makes read requests to Notion only, and the integration can reach only the pages and databases you explicitly shared with it.
• We collect no telemetry, usage statistics or crash reports, and the app includes no analytics, advertising or behaviour-tracking SDK.
• The current version has no background auto-update channel: you download and install new versions yourself from the website or GitHub Releases.
• The app reaches only two destinations on the network: the Notion API, and the license service, used only when you activate or verify a license.
• A license is a one-time purchase. The token is signed with RSA-PSS, verified offline by the client, and bound to this machine.
• Known limits (please read section 9): the key for local credential encryption ships with the program and is no substitute for disk encryption; remote browsing is an HTTP service on your local network and has no TLS; the installer is not code-signed or notarized.

1. Where your data lives

• The backup engine, the database index and the browsing interface all run on your machine. Each backup writes to the directory you set for that profile, and the index and snapshots live in a local SQLite file inside the repository.
• We run no relay: there is no account system, no copy in the cloud, and no step where data is uploaded and then sent back down. The files on your machine are all of it, and we cannot see them.
• For what goes into a backup and where its integrity ends, see the Data integrity statement. The repository directory is entirely yours to control: delete the directory and you delete the backup.

2. The permission boundary with Notion

• The app reaches your workspace through your own Notion internal integration (a Personal Access Token works too). You create the credential, you keep it, and you can revoke it in Notion at any time.
• The app sends read-only requests to Notion (api.notion.com). There is no call in the code that creates, changes or deletes a page, a block or a database. Even if the token you provide carries write permission, the program does not use it.
• By default the integration sees only what you explicitly shared with it. Share only the root pages you need to back up, and keep read-only capability selected in the integration settings.
• To revoke access, unshare the pages or delete the integration in Notion. The token saved on your machine stops working at once, and the app can read nothing more.

3. How credentials are stored

• The integration token and the remote browsing password are never written to disk in plain text: they are kept in encrypted fields of the local metadata database (AES-256-CBC, with the key derived by scrypt from a constant inside the program).
• This encryption keeps credentials out of configuration files, logs and exported archives. It does not protect you from anyone who can already read your disk, because the key ships with the program. Your real boundary is the operating system account and disk encryption: turn on BitLocker / FileVault / LUKS and set an account password.
• The token is used only to reach the Notion API and your own local service. It is not sent to any other third party and is not written into an exported profile archive.
• An exported profile archive contains only metadata (name, repository path, schedule, retention policy, entry list) and backup data. It does not contain the token, the license token or the remote browsing password; after you import it on a new machine, you have to enter the token again.

4. Remote browsing (paid feature, off by default)

• When you turn it on, the app starts an HTTP service on your machine and serves the backup as web pages to other devices on the same network (a phone, a tablet, another computer). The default port is 8732. The bind address defaults to all network interfaces, so a device on the local network can reach it with no extra setup. That default is deliberate, to keep things easy for non-technical users.
• Every request requires HTTP Basic authentication. Credentials are compared in constant time as SHA-256 digests, the password is stored encrypted, and a failed response does not say whether the username or the password was wrong.
• The remote interface is a read-only browsing interface: it returns no token and no repository path, and a remote device sees only a list of profiles with sensitive fields removed.
• Paths to static files and attachments are normalized and confined to the repository directory, so .. cannot escape it.
• The service has no TLS: passwords and content travel in plain text inside the same network. So use it only on a network you trust — a home or office LAN, or your own VPN. Do not expose it directly to the internet, and do not run it on a network you do not trust (public Wi-Fi, a shared office network, a guest network). If you need access from outside, put it behind your own TLS reverse proxy or VPN.

5. Which services the app connects to

The app talks to two kinds of external service:

1. Notion API (api.notion.com): reads your workspace data during a backup, directly between your machine and Notion.
2. License service (lic.notionmanager.com): contacted only when you activate or verify a license, to confirm the license with the payment provider and fetch the signed token. What it receives is the license key, install_id (see section 6), and the order and email details the payment provider already holds. It does not receive your workspace content.

Also:

• No telemetry, no usage statistics, no automatic crash reports, and no analytics, advertising or behaviour-tracking SDK of any kind.
• The current version opens no background auto-update channel: new versions are published on the website and on GitHub Releases, and you download and install them yourself.
• Local logs exist only for troubleshooting and stay on your machine. If you send logs to support yourself, check first that they hold nothing you would rather not share.

6. License, signatures and device binding

• A license is a one-time purchase, not a subscription. The license service signs the license token with RSA-PSS/SHA-256, and the client verifies it offline with a built-in public key. Activation requests travel in an RSA-OAEP + AES-256-GCM envelope.
• install_id is computed with SHA-256 from a fingerprint of this machine (the system machine-id, or hostname|platform|arch|CPU model when that is missing). It is recomputed on every start and never written to disk. Its only use is to identify the device for license checks and activation seat counting, and it does not contain or link to any personal information. The token is therefore bound to this machine: copying it to another machine does not work, and sending us someone else's install_id together with their key does not work either.
• After a successful activation there is no periodic callback, and paid features keep working offline over the long term.

7. Distribution and installer verification

• Installers are published on GitHub Releases. Each release comes with its SHA-256 checksum, and the download page gives you the command to verify it. Please check before you install.
• A checksum that does not match means the file was altered or damaged: discard it and download it again from an official channel.
• The current installer is not code-signed or notarized (the macOS build does not enable the hardened runtime, and Windows has no signing certificate configured), so the system may warn that it comes from an unidentified developer. This is the known state of things; see section 9.

8. Website and payments

• The website is a pre-rendered static site hosted on Vercel. Fonts are self-hosted, and the pages load no third-party analytics, advertising or tracking scripts. Your language and theme preferences are stored in your own browser's localStorage.
• Checkout is handled by payment providers (Paddle as the merchant of record, plus a Dodo Payments channel): card numbers and payment details go only to the payment provider, and we neither touch them nor keep them. The website does not collect your Notion token and does not need it.
• We store only what you send us yourself (support email, comments, refund requests), and we store it to reply and to display it.

9. Known limits and what we do not promise

• Local encryption is not local protection: see section 3, and pair it with disk encryption and an account password.
• Remote browsing has no TLS: see section 4. It is built as a convenience for use inside a LAN or a VPN, not for exposure to the internet.
• The installer is unsigned and not notarized: we cannot prove the origin of the binary through the system signing chain, so rely on the SHA-256 checksum on GitHub Releases.
• Whether a backup is complete is outside this document: what a backup contains, what will not appear in it (the reach of the Notion API and its known gaps), and the 3-2-1 copy practice we recommend are all in the Data integrity statement. This document covers only who can get to your data, and does not repeat that part.
• We offer no bug bounty program and no SLA: this is a one-time-purchase software product, and our security response is the commitment in section 10.

10. Reporting a security issue

• Send security issues to security@notionmanager.com. General questions, feature requests and refund matters go to support@notionmanager.com.
• Please include as much of this as you can: the software version, the operating system, the steps to reproduce, the scope of impact, and your own assessment. Reproduce in a test workspace if you need to, and do not attach real workspace data.
• Do not disclose an unfixed issue in public (an issue tracker, a forum, social media).
• Our commitment: we confirm receipt within 3 business days, then share the fix plan and timeline. Once the fix ships, we thank you in the release notes, if you agree to be named.