Onmindo privacy policy

Onmindo runs at app.onmindo.com, operated by its developer (Eliran Suisa, webo-tech), free, with open signup. Everything this page says "the server" stores is stored on that instance, in a database the developer operates, scoped to your account and reachable only with your credentials. It is used to run Onmindo for you and for nothing else: not read, not sold, not shared, not used to train anything. You can leave at any time (see "Your rights over your data").

If you send tracked mail to people in a jurisdiction with rules about it, those rules apply to you as the sender and not to the authors.

Onmindo privacy policy, in five lines

The extension reads and edits the Gmail compose window in your browser. It stores no mail content anywhere.
Connecting Gmail asks for a send-only permission plus your address. Read access is asked for separately, per feature, when you turn one on.
No message bodies are stored, except a send you scheduled, until it goes out.
Nothing measures your mailbox. The part of the extension that runs inside Gmail counts nothing and reports nothing, and InboxSDK's telemetry is turned off at the source and blocked at the network layer as well.
Onmindo's own screens are measured. The dashboard, the extension's popup and its options page send usage to PostHog, with session recording off. What that can and cannot see is set out below.
Three outside parties can be in the loop. Two are yours: Google (because it is your Gmail account that sends the mail) and, only if you add an Anthropic API key in Settings, Anthropic (because that is what the AI features run on). The third is PostHog, which sees which Onmindo screens get used and never sees your mail.

What the extension does in your browser

The content script runs on https://mail.google.com/* and nowhere else. It uses InboxSDK to add a button to the compose toolbar, a panel to the thread sidebar, a global activity panel, and an indicator on inbox rows.

Mail content is read in the page, at the moment you press Send:

the compose body HTML, so the signature can be appended and the tracking pixel and rewritten links inserted
the recipient address and subject, so the server can mint tracking tokens
link URLs from the body, but only when you have turned link tracking on for that message

None of that is written to disk by the extension. It is read, modified, and handed to Gmail as the outgoing message.

What the extension stores locally

Where	What	Why
`chrome.storage.sync`	The server URL, your API token, and three preferences: track opens by default, track clicks by default, follow-up days	Everything else is dead without them
`chrome.storage.local`	One cached account payload: the Gmail address, connection status, the server's public URL, today's send count and cap, and the time it was fetched	So the toolbar popup paints instantly instead of showing a spinner

chrome.storage.sync is synced by Chrome to your own Google account, which is how a second machine inherits the settings. If you would rather it did not, turn off extension sync in Chrome. No mail content, no recipient list, and no tracking history is cached locally.

Where the extension sends data

To the Onmindo server, and nowhere else. Every request is built from the server URL you typed on the options page, and the extension has no other host in its code.

What goes over that connection:

On a normal tracked send: the recipient address, the subject, the Gmail thread id, and the URLs of the links you asked to have rewritten. The body itself stays in the page.
When you schedule a send, or send a separate copy to each recipient: the whole message, body HTML included, once per copy, because the server is the thing that sends it.
When you run the deliverability check: the subject and the whole draft body, because that is what is being checked.
When you pick a sequence in the compose window: once the message is away, the sequence's id, the recipient address, and the thread the message landed on, so the server can send the remaining steps on that thread.
Everywhere else: thread ids and recipient addresses, to read back what was already recorded.

The extension ships with no blanket host grant for your server. The origin is requested at runtime from the options page, after you type it. Requests carry the API token as a bearer header, which is why the options page refuses a non-HTTPS server URL unless the host is localhost.

What the server stores

All of it in one Postgres database, scoped to your account:

Table	Contents
`user`	Your sign-in email and, if you chose a password, a scrypt hash of it (never the password itself). A Google sign-in account has no password at all. Only on a multi-user instance such as the hosted one.
`session`	Opaque session ids for the dashboard cookie and when each expires. Deleting a row signs that browser out.
`account`	The connected Gmail address, connection status, today's send count, and the Gmail OAuth refresh token encrypted with AES-256-GCM. The plaintext token is never written. A Google client id and secret or an Anthropic key saved in Settings are encrypted the same way.
`tracked_message`	Per tracked message: every recipient address with its field (to, cc, bcc), subject, Gmail thread and message ids, send time, and the pixel token. Not the body. A "separate copy to each" send is one row per copy.
`open_event`	Per pixel fetch: timestamp, the requesting user agent truncated to 300 characters, whether it came through an image proxy, the note it carries (Apple Mail's automatic loading, or within a minute of sending), whether it was set aside as a delivery prefetch or a duplicate, and, only when the reader's own client fetched, the two-letter country code Cloudflare reports. Behind a proxy that column stays empty.
`link`	For a message with link tracking on: the destination URLs and their tokens.
`click_event`	Per click: timestamp, user agent, and a two-letter country code, present only when Cloudflare sits in front of your server.
`scheduled_send`	A queued message in full, body HTML included, until it is sent. Stays in the table after sending unless you delete it.
`reminder`	Thread id, recipient, subject, due time, mode, and the instruction you typed.
`template`, `signature`	Whatever you wrote in them.
`sequence`, `sequence_step`	Each sequence's name, whether a reply halts it, and every step's wait, subject, and body.
`enrollment`	Who is on a sequence: recipient, thread, current step, state, and next-due time.
`suppression`	Addresses you or bounce handling have suppressed, with a reason.

A failed scheduled send or follow-up also keeps up to 500 characters of the error that caused it, which can quote whatever Gmail's API said.

No IP addresses are stored. The pixel endpoint compares the requesting address, in memory, against Apple's published Mail Privacy Protection ranges, so an Apple relay fetch can be told apart from a reader, and then drops it. What is kept is the user agent and the Cloudflare country header, the latter only for a fetch or click that came from the reader's own client.

The server writes one access log line per request: method, path, status, elapsed milliseconds, and Origin. Paths carry ids, so a recipient address appears in the log whenever the dashboard or the extension looks one up. That log is yours, wherever your host puts it.

There is no automatic expiry. Onmindo never deletes a tracked message, an open, or a click on its own. Retention is a DELETE you run, or a database you drop.

Live activity is also held in memory: the last 100 feed events, so a page that connects mid-session sees recent history. It does not survive a restart.

Who else is in the loop

Which Gmail permissions Onmindo asks for, and when

Google. Your own Gmail account sends the mail, so Google sees it, exactly as it would if you had pressed Send without Onmindo. Connecting Gmail is two separate consents. The first, "Connect Gmail," asks for gmail.send and userinfo.email; the server holds that refresh token to send scheduled mail and to know which mailbox you connected. A base-only token cannot read your mail at all: it has no scope for it. The second consent is asked for only when you use a feature that needs it, sequences, reply detection, AI thread summaries and follow-up drafts, or the draft and send follow-up modes, and adds gmail.readonly and gmail.compose. With that consent the server reads a thread when you ask for a summary or a follow-up draft, and saves that draft to your drafts folder. There is no relay: Onmindo never sends your mail through anyone else's SMTP.

The third consent is asked for only when you switch on naming which recipient of a group email opened it, and adds https://mail.google.com/, the full Gmail permission, which Google's own screen describes as "Read, compose, send, and permanently delete all your email from Gmail". Gmail's SMTP submission server accepts no narrower scope over XOAUTH2, and that submission path is the only way to send one copy per recipient under one shared To line. It is never asked for at signup, and declining it leaves everything else working.

A booking page is a separate consent again, on your Google Calendar rather than Gmail: calendar.freebusy, which returns start and end pairs with no titles, no guests and no descriptions, and calendar.events, which creates the one event a booking becomes and reads the dates of all-day entries so the page does not offer a stranger a slot in the middle of a day you have taken off. Google reports an all-day event as free, so nothing else can see it. It is asked for when you create a page, and for nothing else.

What the booking page itself reads of those entries is four things: the start date, the end date, whether the entry was cancelled and whether you declined it. Never the title, the guests or the description. A visitor is sent open start times and nothing else, so no title of yours can reach one.

One screen reads more, and only for you. "Open my week" in a Gmail compose window draws your week so you can pick times against what is already on it, and drawing it needs the titles and the guests' addresses. They are read for that request, rendered in your own browser, and thrown away with the response. Onmindo does not store them, log them, or send them anywhere else, and nobody but the signed-in account holder can ask for them.

Anthropic, only if you configure it. The AI features are off unless you add an Anthropic API key in Settings. When one is set, four calls can send mail content to the Anthropic API: a follow-up draft (the thread as text plus any instruction you typed), a thread summary (the same thread text), a deliverability copy review (the draft's subject and first 20,000 characters of body text), and reply classification (an inbound reply's sender, subject, and first 6,000 characters of body text, used to decide whether to halt a follow-up or a sequence). That is mail content going to a third party, which is why it is opt-in by configuration rather than on by default. Nothing else about you is attached: no account identifier, no tracking data, no recipient list. Anthropic's own terms govern what they do with an API request.

The deliverability check also has a static-rules-only mode, which is what runs when no key is set. It sends nothing anywhere. The Check this message button in Gmail asks for the full check, so with a key configured that button sends the draft's text to Anthropic.

Google, once more, if you sign in with Google on the hosted instance. That sign-in is handled by Firebase Authentication, a Google service: Google sees that you signed in to Onmindo, and hands the server a signed token from which it keeps exactly one thing, your verified email address, to find or create your account. The server verifies that token itself and stores nothing else from it. Email-and-password sign-in involves no third party.

Cloudflare. The hosted instance sits behind Cloudflare, so Cloudflare sees the pixel and click requests and the dashboard traffic, as any reverse proxy in front of a server would; it is also where the country code on a click comes from.

PostHog. Usage analytics for Onmindo's own three screens: the dashboard, the extension's popup and its options page. PostHog sees which screen was opened and what was clicked on it. It has no access to your mail, your recipients or your tracking data, it is not loaded by the part of the extension that runs inside Gmail, and session recording is turned off, so no replay of any screen exists.

Google API Services User Data Policy

Onmindo's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. In practice: Gmail data is used only to provide the features you turned on; it is never used for advertising, never sold, and never used to build profiles or train models; and no human reads it except with your explicit permission for a support request, or where required for security or by law. The one transfer to another party is the optional Anthropic call described above, which happens only if you enable the AI features and carries only the thread text those features need. The usage analytics receive no information from Google APIs at all.

Where the usage analytics run, and what they can see

Three Onmindo screens send usage to PostHog: the dashboard at app.onmindo.com, the extension's popup, and its options page. PostHog receives which of those screens was opened, what was clicked on them, and a random identifier that lets one visit be told from another. Session recording is off on all three, so no replay of any screen is made or stored.

The extension's other half, the part that runs inside Gmail, is not instrumented at all. It loads no analytics code and makes no request to PostHog, which is checked at build time: PostHog is bundled into the popup and options pages and is absent from the script that runs in your mailbox. PostHog never sees a message, a subject line, a recipient, a link, or a thread.

The server sends PostHog four events, and only these four: a tracked message was sent, an open was recorded, a click was recorded, a booking was made. They exist because the screens cannot see them: a browser is not present when a pixel is fetched three days later, so without these the product cannot tell whether anything it does actually works.

What rides along with each one is a count, a true or false, and a word from a fixed list: how many people were on the message, whether tracking was on, whether the send came from Gmail or from the scheduler, how confident the open was and whether it arrived through a mail provider's image proxy, how long a booked meeting is. The person is the same random account identifier the dashboard uses. No address, no subject line, no link, no thread, no country, and no message counter tied to anything but that identifier. A click event carries no properties at all, because the only fact about a click is the link, and the link is yours.

The marketing site you are reading now also uses PostHog, plus Vercel Web Analytics for page views. These are public pages with no account behind them.

What Onmindo does not collect

No analytics inside Gmail, and nothing about who you write to leaving the server. The four counters the server does send are listed above, and none of them carries an address, a subject line or a link.
No telemetry from inside Gmail. InboxSDK, the library Onmindo uses to talk to Gmail's DOM, normally POSTs error reports and usage analytics to api.inboxsdk.com, including a hash of your Gmail address as a persistent identifier. Onmindo stops that twice over: it loads the SDK with its own documented opt-outs so the requests are never attempted, and a network rule blocks the host outright so a future version of the SDK cannot reintroduce it either.
No ads, no ad networks, no data brokers, nothing sold or transferred to anyone. Your mail, your recipients and your tracking history never leave the Onmindo server.

What is recorded about the people you email

When you send with tracking on, the server records that you sent to that address, the subject, and every subsequent pixel fetch or tracked-link click, with the timestamp, the user agent, and for a fetch or click from the reader's own client the country code Cloudflare reports. Nothing is stored on the recipient's device: a tracking pixel is an ordinary image request and Onmindo sets no cookie on it.

Onmindo is deliberate about what that evidence means. Gmail's delivery-time fetch is recorded as delivered, never as an open. An open is recorded when a mail client drew the message for a reader, and it names the client (Gmail, Apple Mail, Outlook, or a browser). For a Gmail reader no device or location is recorded or shown, because Google's proxy fetched the pixel, not their machine. For a direct fetch the user agent names the device and Cloudflare names the country. Nobody is ever told a person read the words; a pixel cannot know that. The reasoning behind each of those labels is set out in what a tracking pixel can and cannot prove.

Tracking pixels carry legal weight in some jurisdictions, and consent or disclosure may be your obligation as the sender. Onmindo honours a per-recipient suppression list and ships no consent management framework. Know the rules that apply to you.

Your rights over your data

The dashboard shows everything stored about your account: messages, opens, clicks, templates, signatures, sequences, suppressions, and your settings. Delete any of it there.
Disconnect Gmail in Settings, or revoke access at myaccount.google.com/permissions, and the stored refresh token is useless either way.
To delete the account itself and everything keyed to it, email [email protected] from the address you signed up with. It is done by hand, promptly, and it is permanent. There is no self-serve delete button yet; this line changes when there is.
Uninstall the extension to clear its local storage.

How changes to this policy are recorded

This document is versioned alongside the source code and dated at the top. When something here changes, the date does.

Back to the contents