Privacy Policy (Zeed Atlas)

Zeed Atlas (EFG technologies Inc., "we") is a reading app for reading, listening and connecting ideas. This policy explains what the app actually collects, what it stores, and where data goes.

Two ways to use Atlas — you choose where your data lives

Without signing inYour subscriptions, read state, likes, notes and interest-learning data are stored only on your device. Nothing is stored on our servers. Deleting the app deletes the data.

Signed in (sync)To use the same data across devices and the Web app, the data above is stored on our servers, tied to your account. Your email address is used for authentication.

Sign-in (email magic-link authentication) is handled by our own server (search.zeed.run). Only the delivery of the confirmation email is handled by Postmark, and all Postmark receives is your email address and the body of that message.

How synced data is protected

In transit: everything is encrypted with TLS.
At rest: the server database is encrypted at rest.
Access: only your account can access your data. Our operational access is limited to incident response and abuse prevention.
Honest note: this is not end-to-end encryption. In exchange, server-side AI can organize your collection (generate summary notes, suggest connections between articles). These features run only on your action or setting.

What is sent to AI features

Atlas has features that use AI on your articles and notes (for example translation, summaries, answering questions, read-aloud, and organizing how articles connect). These features run only when you use them or turn them on in Settings. When they run, the text each feature needs (article headlines and body, and your notes and highlights) is sent via our server (search.zeed.run, on Fly.io) to the AI providers listed below. We use API terms under which providers do not train on your data, and we discard inputs once the response is returned. Results you choose to keep (notes, summaries, maps of how articles connect) are stored as synced data and are deleted when you delete your account.

AI providers we use: Anthropic and OpenAI (features that work with text), ElevenLabs (backup for read-aloud when OpenAI is unavailable), and Google (Gemini API, see "What we send for video analysis" below).

Connecting an outside AI assistant (MCP): only if you authorize a connection, we return your library (articles, notes, highlights) and its state, such as which articles you have read, when that AI assistant (for example Claude) asks for it. How it is handled after that follows the policy of that assistant's provider. Tokens issued on your account page can be revoked there at any time.

Trial quotas are managed with a randomly generated device ID not linked to your identity. Our server stores only a salted hash of that ID, together with the first and last day you used the trial (dates in Japan time), how much you used, the day you first hit that day's limit, the day you switched to your own API key, and the kind of device (iPhone / Android / Web, and whether it is a real device or a simulator / test machine). We use this to enforce the trial period and the daily limit, and to count how the trial is used. These records are deleted 180 days after your last use (only the usage counts needed to enforce the limits are kept).

Optional AI category assistance is off by default. If you enable it in Settings, titles, summaries, and the beginning of feed articles whose categories are unclear are sent via our server to OpenAI. Categories you choose manually are preserved. Article URLs, highlights, notes, and reading history are not included in these classification requests. Our server keeps only an account-specific classification result and a hash of the submitted material in memory for up to 24 hours to avoid repeated requests.

What we send for video analysis

When you paste a YouTube link and run analysis, the video URL is sent via our server to Google (Gemini API), which returns a transcript and a description of what appears on screen. Only the URL of a public video is sent; we never store the video file. Results are cached on our server so the same video is not re-analysed when someone else pastes it (the cache is not linked to who pasted it). Private and unlisted videos cannot be analysed.

Other data we collect

Usage stage records (on by default; you can turn this off at any time in Settings → Privacy): to improve the app and to check whether our ads work, we record, linked to a salted hash (computed on our server, search.zeed.run) of a random per-device ID (the same one used for trial quotas), each of these stages — first launch, finishing setup, opening / finishing / listening to / sharing an article, coming back the next day and 7 days later, reaching the trial limit, seeing the purchase screen and purchasing (including restoring a purchase), and asking for a rating — plus the days you opened the app, together with the date (day only, Japan time), the kind of device (iPhone / Android, and whether it is a real device or a simulator / test machine), the app version, and your country or region. We never include article content, URLs, search terms, or AI conversations. These records are not linked to your signed-in account. Trial quota records and the ad measurement records below are linked by this same ID and counted as numbers of people per stage (they are not linked to purchase verification records, which can be tied to your account). Only if "Send usage milestones" is on in Settings, we record which variant of an A/B experiment you were shown (just the experiment name, the variant name and the date), together with a pseudonymous device ID. If it is off, you are not enrolled in any experiment and nothing is recorded. If you turn this off, neither the stage records nor the ad measurement below are sent. Records are deleted once they are older than 13 months.
Detailed usage analytics (off by default; sent only if you opt in): anonymous aggregate events (app launch, feature name, app version, the week you first opened the app; versions up to 1.0.7 also send stage records such as how far you got in the purchase flow here). Never article titles, URLs, article text, note contents, search terms or your conversations with the AI. What we send is which stage you reached and which week — never the content itself. Toggle consent at any time under Settings → Privacy; sending stops immediately when you turn it off. The identifier is a random value created on your device and is not linked to you or your device.
Measuring our ads (on by default; not sent if you turn off stage records): if you installed the app from an App Store ad (Apple Ads), the app sends, once within 30 days of first launch, the ad attribution token issued by Apple (a string only Apple can read) to our server together with the same device ID used for trial quotas. Our server sends the token to Apple and stores what Apple returns — whether you installed from an ad and, if so, the campaign, ad group, search keyword and ad IDs, the country or region, when the ad was tapped (or viewed), the download type, and where the ad was shown — linked to the ID above. The token is discarded once Apple answers. If you installed from Google Play, we store the referrer that the store passes on (values such as campaign name, source and medium, and whether an ad-click identifier was present; we do not store the identifier itself). These records are deleted 13 months after we receive them. We do not use the advertising identifier (IDFA) and do not ask for App Tracking Transparency permission. We do not share data with third parties to deliver ads, and we do not combine it with data from other companies' apps or websites (tracking).
Purchase verification and records (if you buy Pro): to confirm that a purchase is genuine and active and to unlock Pro and its AI allowance, the app sends the signed purchase information issued by the App Store (iPhone / iPad) or the purchase token issued by Google Play (Android) to our server, together with the device ID. Our server verifies the App Store signature, and checks Google Play purchases with Google (Google Play Developer API). We store a salted hash of the device ID, the product, the transaction number (and, for Google Play, the purchase token), the expiry date, the store (App Store / Google Play) and the environment (production / test). If you are signed in, we link this record to your account so Pro also works on your other devices and on the web (deleting your account removes that link). Card numbers and other payment details are handled by Apple / Google; we never receive them.
Crash reports (opt-in only): technical crash information with no personally identifying information.
Feedback (explicit send only): what you wrote, the screen name and the app version, used only for improvement.
Location (once): used once to determine your country code for the "locality" setting. Coordinates are never stored.
Where usage data goes: stage records and ad measurement go to our server (search.zeed.run, on Fly.io); detailed usage analytics goes to our own Cloudflare Worker (zeed-telemetry.efg-technologies.workers.dev). The app does not send usage data to outside analytics services.
Where crash reports go: the technical crash information above is sent to Sentry, after stripping personally identifying information. This is opt-in (only when you turn it on); nothing is sent by default.

The learner page and the Chrome extension

Visit counting on the learner page (atlas.zeed.run/learn/ja): when you open the page, we record a salted hash (computed on our server) of a random device ID created in your browser, the date of the visit (Japan time), and a short mark showing which link you came from (the ?src= in the URL). Records are deleted once they are older than 90 days. We do not store your IP address, which articles you read, or your user agent (browser type) — the IP address is used on the spot for rate limiting and the user agent for filtering out bots, and neither is kept. The purpose is to improve the page and to know how many people come back. The page also sends anonymous usage events (a page view with that day's edition date and the mark above, and taps on the furigana toggle, a word, read-aloud, a source link — with the publisher's name — or an app link) to Aptabase (EU). These never include the device ID, article URLs or article text. Read-aloud and feedback are sent only when you press the button, and are handled the same way as "What is sent to AI features" and "Feedback" above (if you include an email address in your feedback, it is stored with the message so we can reply).
Chrome extension "Zeed Atlas — Save to Library": only when you use the toolbar button, the right-click menu or the keyboard shortcut, the extension sends that page's URL and title, and the text you selected (when saving it as a note or a to-do), to our server (search.zeed.run) as part of your library — the same synced data as "Signed in (sync)" above. It does not send your browsing history, and it does not watch the pages you visit. Your sign-in token, a list of the article URLs already in your library (to avoid saving the same page twice) and the titles of your 5 most recent saves are kept in the extension's storage in your browser. Sign-in uses the same email-link authentication described above.

Ads, tracking, selling data

No ads. No selling data to third parties. No cross-app tracking (we do not use the advertising identifier, IDFA). This does not change with sync.

Your rights and choices

Freedom not to sync: without signing in, your data stays on-device (all core features work).
Export: synced data can be exported as standard JSON.
Deletion: deleting your account deletes synced data on our servers (purged from backups within 30 days). On-device data can be reset from Settings at any time.
Toggles: stage records (on by default), detailed usage analytics and crash reporting (both off by default) can each be switched on or off at any time.

Children

Our services are intended for people aged 13 and over. We do not knowingly collect information from children under 13.

Changes

When we add or change features, we do not update this page as long as the kinds of data collected, where they are sent, and why stay within what this page describes. If that scope widens (a new kind of data, a new recipient, or a new purpose), we update this page and the date below, and notify you in the app.

Change log

2026-10-20: rewrote "What is sent to AI features" to describe what is sent, to whom, and why, instead of listing feature names. Added the connection to outside AI assistants (MCP, offered since 2026-09), which had been missing. Clarified in "Changes" when this page is updated. The scope of data handling has not widened.
2026-10-03: stage records now also include which variant of an A/B experiment you were shown (just the experiment name, the variant name and the date). Only if "Send usage milestones" is on in Settings, this is recorded together with the same pseudonymous device ID as the stage records; if it is off, you are not enrolled in any experiment. Like stage records, it is deleted once it is older than 13 months.
2026-09-28: stage records (how far you got in the app) are now on by default (you can turn them off in Settings) and stored on our server linked to the same device ID as trial quotas (deleted after 13 months). Ad measurement no longer depends on opting in to usage analytics (it is not sent if you turn off stage records), and we added storing the Google Play referrer. We added the kind of device to the trial quota records. We removed PostHog, which we did not actually use, from the usage-data destinations.
2026-09-27: described three things we already do but had not written down — the trial quota records (deleted 180 days after last use), measuring our App Store ads (ad attribution; deleted 13 months after receipt), and App Store / Google Play purchase verification and records. We also set a 13-month deletion period for the ad attribution records, which previously had none. Our data-handling policy itself has not changed.
2026-09-25: added the section "The learner page and the Chrome extension", describing the anonymous visit counting on the learner page (atlas.zeed.run/learn/ja), including Aptabase as the destination of its usage events, and what the Chrome extension sends and keeps in your browser. Our data-handling policy itself has not changed.
2026-09-09 (corrected the same day): an earlier version published the same day named "Supabase" as the processor for sign-in. That was wrong. The sign-in we actually ship is handled on our own server, and only the delivery of the confirmation email is entrusted to Postmark (Supabase code still exists in the repository but is not reachable from any screen in the app). The wording has been corrected.
2026-09-09: named the processors we actually use — Postmark (delivery of the sign-in confirmation email), ElevenLabs (read-aloud fallback), PostHog / our own Cloudflare Worker (usage analytics), and Sentry (crash reports). Our data-handling policy itself has not changed.
2026-09-08: added "how far you got in the purchase flow" (recorded as an anonymous stage only) to the usage-analytics examples, and corrected the default-state wording to match actual behavior (off by default, sent only if you opt in).
2026-08-22: introduced sync (server storage when signed in) and revised the policy from "on-device only" to the two-mode model above. The signed-out experience is unchanged.
2026-08-21: first version.

Contact

tsuyoshi.nagamine@efg-technologies.com

Last updated: 2026-10-20 (see the change log for earlier changes)