Tome — Privacy Policy

Last updated: 9 August 2026

Tome is self-hosted. The browser extension talks to one server: the one you enter in its settings. There is no Tome company, no hosted service, and no account with anybody but the operator of that server — usually a friend, or you. Nothing in this document describes data going to the authors of Tome, because none does.

Two parties can hold your data, and it's worth being clear about which is which:

• The extension, running in your browser on your machine.
• The server you point it at, run by whoever invited you. If that isn't you, they can see what's described under "What the server receives".

What the extension stores

All of it stays in your browser's extension storage. None is transmitted anywhere except to your configured server, and only as described below.

Signing out (settings → Sign out) removes the API key. Removing the extension removes all of it.

What leaves your browser, and when

Only when you click a button. Tome has no background scraping, no content scripts running on page load, and no automatic reading of tabs. It holds the activeTab permission, which grants access to a page only after you click the toolbar button, and only for that page.

When you click Send to Kindle or Open preview, the extension reads the article from the page you have open and sends it to your configured server: the title, byline, publication date, source URL, article text and images, and the reader stylesheet. That is the feature — it cannot render a document without the document.

The only other requests are to your own server: a status check (which also asks what extension version it has), and reading or updating your profile.

What the server receives

Your server stores your email address, the address documents are delivered to (usually a Kindle, but it can be any mailbox), and a SHA-256 hash of your API key (never the key itself). It keeps invite codes until they are used or expire.

Articles are not stored. They are rendered to PDF or EPUB in a temporary directory, sent to your Kindle, and the temporary directory is deleted. The readable conversion history — which article, from where — exists only in your own browser.

The server does keep a minimal record that a conversion happened, so the operator can see load and spot failures: which account, when, the format, whether it succeeded, the file size and how long it took. No title, no URL, no domain — nothing identifying what you read. These rows are deleted after 30 days. The server also records the date each account last used its key, so the operator can tell an active account from an abandoned one.

If email delivery is configured, the operator supplies a Resend API key and the rendered document is emailed to your Kindle address through Resend. Amazon then receives it, as it must for Send-to-Kindle to work at all.

If the operator turned on analytics

A server can optionally send a copy of that same record to PostHog, so the operator can see which devices and reading settings are actually used and decide what to work on. It is off unless the operator sets a key, and it is their own PostHog project — not one belonging to the authors of Tome, who receive nothing either way.

What an event carries: whether it was a preview or a send, the format, whether it succeeded, how long it took, a size band rather than an exact byte count (<256k, 256k–1m, …), your chosen device, body font and colour mode, and — if it failed — a category such as render or delivery, never the error text. Two other events exist: that someone redeemed an invite, and that the server restarted.

What an event never carries: the title, the URL, the domain, any part of the article, your email address, your Kindle address, or your IP address. Events are sent by the server, so PostHog sees the server's address and never yours, and location lookup is switched off. You appear as an opaque account number with no meaning outside the operator's own database, and person profiles are disabled, so PostHog builds no per-person record.

Everything in an event is a number or a fixed value from a known list. The server refuses to send any value that looks like a URL or an email address, so this stays true even if the code changes.

Nothing here is new information about you — it is the conversion record above, which the operator can already read, forwarded to the tool they use to read it.

If you ask for an invite

A server may put a form on its landing page for requesting one. If you use it, the only thing collected is the email address you type. It is emailed to the operator so they can send you a code. It is not added to any list, used for anything else, or passed on, and nothing is ever sent back to it except an invite — if the operator chooses to send one.

Your IP address is not recorded with the request. The form is protected by a challenge and a rate limit, and those handle abuse — so storing an identifier for someone who isn't yet a user would inform no decision anyone makes.

Requests are kept for up to three months and then deleted, whether or not an invite was sent.

Third parties

There are none in the extension. No analytics, no telemetry, no crash reporting, no advertising or tracking SDK, no CDN. Fonts are bundled in the package rather than fetched from Google Fonts, specifically so that opening a preview doesn't disclose to a third party that you're reading something. Nothing in your browser reports anywhere but the one server you configured — and that remains true whether or not your operator turned on the server-side analytics described above.

A server's website is separate from the extension, and what it involves depends on how the operator hosts it. A server reachable over the public internet usually sits behind a proxy or CDN, which necessarily sees the connection — including your IP address — in order to route it at all. If its landing page carries an invite form, the anti-spam challenge on that form also runs in your browser and comes from whoever provides it. Neither is analytics, and neither is part of the extension; both follow from the site being publicly reachable. Ask your operator what their deployment uses.

Downstream of your server, at most three services are involved, each only if the operator set it up:

• Resend, which transmits the email, and Amazon, which receives the document on your Kindle. Both are inherent to emailing a file to a Kindle.
• PostHog, only if the operator turned on analytics, and only the conversion records described under "If the operator turned on analytics" above — never the article, its title, its address, or yours. It is the operator's own PostHog project.

Ask your operator whether analytics is on; a server states it in its startup log, so they will know.

What is never done

• Your data is never sold, and never shared with data brokers.
• It is never used for advertising, personalisation, or profiling.
• It is never used to assess creditworthiness or for lending.
• Your browsing is not collected. Tome sees the one page you explicitly asked it to convert, at the moment you asked.

Your control

• See what's held: settings → Recent conversions.
• Erase local data: Clear history, Sign out, or remove the extension.
• Erase server data: ask the operator to delete your account; if you are the operator, delete the user with tome admin users or delete the data volume.
• Change your Kindle address: settings → Account, any time.

Permissions, and why each is needed

There are no host permissions at all, for your own server or anyone else's. The extension reaches it as an ordinary cross-origin request, which the server allows. Nothing gives the extension standing access to any site — the only page it can ever read is the one whose toolbar button you clicked, for as long as that click lasts.

If you are in the EU or UK

Tome has no company behind it, so there is no central controller to write to. The operator of the server you use is the data controller for everything that server holds; the authors of Tome are not, because none of it reaches them. This server's operator and how to reach them are shown at the end of this page.

Why each thing is processed, and on what basis

How long things are kept

Where it goes. The server is run by an individual and may be anywhere, including outside the EEA or UK — commonly on a machine in the operator's own home. If delivery is configured, Resend and Amazon receive your Kindle address and the document, and both are US companies. If analytics is enabled, the conversion records go to the operator's PostHog project, which may be PostHog's US cloud, its EU cloud, or an instance they host themselves. Ask your operator where their server is, and which of these they use, if it matters to you.

Your rights. You have the right to access your data, to correct it, to have it erased, to restrict or object to its processing, and to receive it in a portable form. The Your control section above is how each is exercised in practice; for anything it doesn't cover, ask the operator. You also have the right to complain to your data protection authority — in the EU, the one for the country you live in; in the UK, the ICO.

There is no automated decision-making or profiling, and nothing here is sold or shared with data brokers.

Contact

Tome is open source — read the code, or raise an issue, at https://github.com/patali/tome. That reaches the authors, who hold none of your data.

For data held by a server you were invited to, contact its operator — they administer it. If you don't know who that is, it is whoever gave you your invite code.