Security.

The short version

• Captures stay on your device by default. A Live Jot sends an encrypted, temporary copy only when you choose to share it.
• The desktop interface is forbidden from making direct network requests by its content policy.
• An AI provider key you choose to save is encrypted with the Windows Data Protection API in a file outside the database.
• This release has no Microsoft account connection or app-operated crash reporting.
• 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 default server-side copy. Your captures exist on your disk unless you create an encrypted Live Jot. The public website does not hold your local library.
• The interface cannot make a direct network request. The desktop window is a webview, and its content policy allows calls to Jot's native commands rather than remote origins. Those commands can use the network for features you invoke, so command validation and dependency review still matter.
• Network paths are explicit. AI requests and Live Jots use Jot's native HTTP component when you invoke them. Update checks use Windows Store services. The privacy page describes when each path is used.

Secrets at rest

If you save an AI provider key, Jot stores it in a file next to the database, 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, the app treats the AI key as unavailable.
• If encryption is refused, the secret is not written at all. There is no plaintext fallback.

The key is in a separate file rather than a row 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. When you create a Live Jot, the temporary encrypted copy is held by the sharing service. When you send text to an AI provider, that provider's security governs the request.
• 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. Dependency changes are reviewed and tested; Windows Store can install app updates automatically. The desktop content policy limits direct network access from the interface, while native commands are audited separately.

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 AI key and provider flows still need a complete real-provider pass. Read that page before trusting this one with anything that matters.