Security.

The short version

• There is no server holding your notes, so there is no server to breach.
• The app's interface is forbidden from making network requests, by its own content policy. That is enforced by the runtime, not by our good intentions.
• The two secrets the app stores are encrypted with the Windows Data Protection API, in files outside the database.
• Signing in to Microsoft happens in your real browser, on Microsoft's own page.
• It does not, and cannot, protect you from something already running as you on your own machine.

What the architecture rules out

The strongest security properties here are the ones that come from something being absent rather than from something being defended.

• No accounts, so no credential database. The free tier has no sign-in of any kind. There is no password of ours to leak, no reset flow to abuse, and no user table to be dumped.
• No servers, so no server-side copy. Your captures exist on your disk. A compromise of our website — this static site — reaches nothing of yours, because nothing of yours is here.
• The interface cannot make a network request. The app's window is a webview, and its content policy permits exactly one thing: talking to the application's own local code. No origin is allowed. If a dependency inside that interface were compromised, it still could not send anything anywhere.
• All network traffic goes through one place. Every outbound request in the app — Microsoft sign-in, the To Do API, an AI provider — goes through a single component in the native code. There is exactly one file to audit to know everything the app can talk to.

Signing in, and what is kept afterwards

Connecting a Microsoft account opens your real browser at Microsoft's own sign-in page and catches the result on a local port on your machine. It is not an embedded window inside the app — that pattern trains people to type their Microsoft password into a window whose address bar they cannot see, and it should not exist in a desktop application.

There is no client secret, because a desktop application cannot keep one; the flow used is the one designed for exactly that situation, with a per-attempt challenge that cannot be replayed.

Afterwards the app keeps only a refresh token and your account's display name. The short-lived access token stays in memory and is never written to disk.

Secrets at rest

Two files sit next to the database — one for the Microsoft refresh token, one for an AI provider key, if you supplied one. Both are encrypted with the Windows Data Protection API in its user-scoped mode.

What that gets you:

• The key is derived and held by Windows, tied to your user account. The app ships no key and manages none.
• The file is useless to another user on the machine, and useless on another machine.
• If decryption fails for any reason, the app treats it as "not signed in" rather than half-working.
• If encryption is refused, the secret is not written at all. There is no plaintext fallback.

They are separate files rather than rows in the database for a specific reason: the database is copied into a rotating daily backup, and those backups are meant to be freely copyable. A long-lived credential must never be in a file people are encouraged to move around without thinking.

What this does not defend against

This is the section that makes the rest of the page worth anything.

• Anything running as you. User-scoped encryption is a boundary between Windows accounts and between machines. It is not a boundary between programs inside your own account. Malware running as you can read the same files Jot can, database included.
• An unencrypted disk. Your captures are a plain SQLite file. Anyone with the disk, or a backup of it, can read them. If that matters to you, turn on full-disk encryption — that is the layer for it, and Windows has one.
• Anything after a capture leaves. Once a task is in your Microsoft account, Microsoft's security governs it. Once text has gone to an AI provider, that provider's does.
• A compromised machine, generally. A local-first application inherits the security of the machine it is local to. That is the trade, and it is a good one for most people, but it is a trade.
• Losing the machine. There is no server-side copy to restore from. Back up your disk.

This website

• Static pages. No database, no user input that is stored, no session, no cookies.
• A content policy that permits no third-party origin at all — no fonts, scripts, styles or images from anywhere else. The build fails if a page tries to load one, so this is checked on every deploy rather than assumed.
• Framing is refused everywhere except the one route the front page embeds, which is restricted to this origin.
• The one form on the site posts to a single function that validates an address and forwards it. Nothing about you is stored here.

Dependencies

The app is a small amount of Rust and a small amount of TypeScript, and the dependency list is kept deliberately short — a capture tool does not need a framework for anything. Updates are applied when they matter rather than automatically, and the interface's inability to make network requests means a compromised front-end package has nowhere to send anything.

Reporting something

Email hello@wrivio.com with enough detail to reproduce it. Please do not open a public issue for a security problem before it is fixed.

What to expect, honestly, from a one-person project:

• An acknowledgement within a few days.
• An assessment, and a fix if the report is valid, as quickly as is realistic.
• Credit in the release notes, if you want it.
• No money. There is no bug bounty, and pretending otherwise would waste your time.

If something here turns out to be wrong — a claim on this page that the code does not support — that is a report worth sending too, and it will be corrected on this page.

Where this stands today

Everything above describes how the software is built. The parts that have been exercised on real Windows hardware, and the parts that have only been written and tested, are listed separately on the status page. Notably, the encrypted-storage path has never been run against real Windows encryption, and no Microsoft sign-in has ever completed. Read that page before trusting this one with anything that matters.