Built to keep conversations private.

Privacy, enforced by the server

Hiding something in an app's interface isn't the same as keeping it private. Kitchen Table makes every decision about who can see what on its server, before anything is sent to your device.

• Conversations: every request for a conversation, its thread, its sources or its takes is checked against the list of people at that table. If you're not at the table, the server doesn't send it, and that includes other members of your team.
• Teams: if you're not on a team, as far as the server is concerned it doesn't exist.
• Locked takes: when a take is shared only with people who've decided, the server holds back its words, and its "what changed" notes, until the reader has decided. They never reach the device of someone still making up their mind.
• The question queue: runs on the server, so questions go out on schedule without relying on anyone's browser, and members see only what's on its way to them.

Sign-in and sessions

Sign-in is handled by Clerk, a specialist authentication provider that holds a SOC 2 Type 2 report and is self-certified under the EU-U.S. Data Privacy Framework. Kitchen Table never sees or stores your password.

• Every request from the app carries a short-lived session token, which our server verifies cryptographically before doing anything.
• Tokens issued for any other website are rejected, even if they're otherwise valid.
• Sessions with unfinished sign-in steps are turned away.
• Every account needs a verified email address.

Invitations

An invitation link is effectively a key to your team, so it's treated like one.

• Each link carries a 256-bit random token. We store only a one-way fingerprint (a SHA-256 hash) of it, so even someone reading our database couldn't use an invite.
• The token sits in the part of the link after the #, which browsers never send to servers, so it stays out of logs along the way.
• Invitations expire after 7 days and work only once. Resending one makes a new link and switches off the old one, and owners and admins can revoke one at any time.

Encryption

• In transit: Kitchen Table only works over HTTPS, with TLS 1.2 or newer. Browsers are told to always use HTTPS for our domain (HSTS).
• At rest: our database is encrypted with AES-256, along with everything in it.

Infrastructure

• Kitchen Table runs on Cloudflare's global network, which absorbs attacks such as floods of fake traffic before they reach us.
• We run no servers of our own, so there are no machines for us to forget to patch or leave open.
• Secrets such as API keys live in a dedicated secrets manager. They're never written into code.
• Only the people who build Kitchen Table can reach production systems.
• Test versions of the app use a separate database and test accounts, so real families' information is never used for testing.

Protecting the app

• Any request that changes something must come from Kitchen Table's own address. This stops other websites from acting on your behalf (cross-site request forgery).
• Everything sent to our server is checked against strict rules for its shape and size before it's used.
• When something goes wrong, error messages never reveal internal details.
• Developer and testing tools are switched off in production.
• This website has no JavaScript at all, sets a strict Content Security Policy, and can't be embedded in other sites.

Payments

Plans are billed through Clerk, and card payments are processed by Stripe. You enter your card details into their secure checkout, so your card number never touches our servers. The only thing we learn is your team's plan and whether a card is on file.

Email

The only email we send ourselves is a team invitation, from hello@kitchentable.fyi. Our domain is set up so that it's hard to impersonate:

• SPF, DKIM and a strict DMARC policy tell receiving mail servers to reject email that pretends to come from us.
• MTA-STS requires email sent to our domain to travel over an encrypted connection.

Backups

Our database provider keeps a continuous history of the database, so we can restore it to any minute in the recent past if something goes badly wrong. Deleted information ages out of that history within 30 days.

Testing

Every user workflow in Kitchen Table has an automated scenario that runs in a real browser, and our server is tested against a real database engine. These tests check, among other things, that people outside a conversation can't see or touch it and that locked takes stay locked.

What we're working on

Being honest about the gaps matters as much as listing the strengths. Next on our list:

• Self-serve account deletion and data export. For now, email privacy@svelte.llc and a person will handle it within 30 days.

Report a vulnerability

If you think you've found a security problem in Kitchen Table, please tell us privately at security@svelte.llc. Include the steps to reproduce it and what you think the impact is. We'll confirm we've got it, keep you posted as we fix it, and credit you if you'd like.

Good-faith research

We won't take legal action against research done in good faith that:

• only uses accounts and teams you own, or have permission to test,
• stops as soon as you reach someone else's information, and doesn't keep, share or change it,
• doesn't degrade Kitchen Table for others, so no denial-of-service or spam testing, and
• gives us reasonable time to fix the problem before you tell anyone else.

Our contact details are also published in /.well-known/security.txt.