What Sant Tabs collects and what it refuses to. The complete picture.
Sant Tabs collects no telemetry, no analytics, no crash data. Here is exactly what the extension stores, what leaves the browser, and where the gaps still are.
20 April 20267 min read
The Chrome extension ecosystem has a data collection problem. Most extensions collect telemetry by default. Usage events, error reports, install identifiers, and in some cases the URLs of every page a user visits. The permissions model that Chrome requires is public, but the actual data that flows out of an extension and into a developer's analytics platform is not. Users grant permissions at install time without knowing what those permissions are used for in practice.
Sant Tabs was built on a different default. The principle is the same one that runs through every Sant product: data stays local unless it has to leave, and when it leaves, the path is narrow enough to describe in one place. This post does exactly that. Free tier, Premium tier, AI features, and the gaps that still exist.
What the free tier actually does with your data
For a free user who has not signed in, Sant Tabs stores everything in chrome.storage.local. Tab collections, saved windows, scheduled items, settings, theme preferences, and a local tab usage history. None of it reaches a Sant server. None of it is transmitted anywhere.
The tab usage history deserves a specific note because the feature is named "analytics" inside the extension code, which sounds like it means something it does not. The feature is a local map of which URLs a user visits frequently, capped at five hundred entries, stored entirely in the browser profile, and used only to power the in-extension Tab Usage panel. It is never transmitted. Calling it analytics in the code was a naming choice by the developer. The data behaves like a local preference file.
The one outbound call that does fire for free users is ExtensionPay, which checks paid status. This is the closest thing to a phone home in the extension. ExtensionPay is a Stripe-backed payment layer that the extension uses to verify whether a user has purchased Premium. It fires a polled call to confirm paid status. Free users see this call too, because that is how ExtensionPay determines they are not yet paid. The call does not contain browsing data, tab contents, or usage information. The call goes to extensionpay.com, not to Sant.
One more outbound path exists for free users who choose to sign in with Google: the standard OAuth flow to confirm identity. Sign-in is optional. A free user who does not sign in makes no outbound calls beyond the ExtensionPay check.
What Premium cloud sync stores, named exactly
Premium users who enable cloud sync have their saved tab collections written to Firestore, a Google-hosted database, through a Sant Cloud Function that verifies identity before accepting any write.
What is stored: saved windows, which include full tab URLs, tab titles, and favicon URLs. Scheduled items. A small settings document covering theme, view, icon size, and window sort order. These are stored under a Firestore path keyed to the user's Firebase Auth UID, which is derived from their Google account. No other user can read or write to that path. Firestore rules enforce this at the database level.
What is not stored in Firestore: browsing history, currently open tabs, tab usage statistics, cached AI summaries, auth tokens, or any telemetry.
The honest description is that Premium cloud sync stores the same tab collections a user can see in the extension itself, on a server, so they persist across devices. Full URLs are in that data. That is what sync requires. It is not aggregated, anonymised, or reduced. It is the actual saved tabs.
The AI Smart Organise feature
The free tier includes an on-device summariser that uses Chrome's built-in Summariser API. It never leaves the machine.
The Premium AI Smart Organise feature works differently. When a user triggers it, the extension sends up to one hundred eligible tabs, each as a title, URL, and locally cached summary if one exists, to a Sant Cloud Function. That Cloud Function forwards the data to Google Gemini to generate grouping suggestions. The Cloud Function verifies the caller's Firebase ID token before accepting the request. It does not write to Firestore. It does not log the prompt. It does not persist the request after returning the clustering result.
Internal URLs, including browser system pages and extension pages, are filtered out before the data leaves the browser. The on-demand nature of the feature is deliberate. The data crosses out only when the user actively chooses to organise, not on a background schedule.
Google's standard Gemini API data handling applies to what Gemini receives. That is Google's policy to answer, not Sant's, and the post links to it rather than paraphrasing it.
What is never stored anywhere
No telemetry. No crash reporting. No usage analytics. The extension was audited against every major analytics and monitoring SDK, and the grep returned zero hits across the full codebase. Errors go to the browser console.
No browsing history beyond the local tab usage map described above. No current open tabs stored anywhere outside the browser session. No full message content, because there is no messaging system in the extension.
The retention gap
One gap exists and deserves naming rather than hiding. When a Premium user cancels or downgrades to free, their saved tab data in Firestore is not automatically deleted. A deletion endpoint exists in the Cloud Function and can be called manually. Nothing in the current codebase triggers it on cancellation. There is no scheduled cleanup, no TTL on the Firestore documents, no webhook from ExtensionPay that fires a delete on downgrade.
The practical effect is that a former Premium user's synced tab collections remain in Firestore until they explicitly request deletion. Sant is aware of this gap. Automatic deletion on cancellation is a roadmap item. Until it is shipped, the honest description is that Premium cloud sync data persists indefinitely unless the user triggers deletion themselves.
Where this thinking sits in the regulatory landscape
Sant Tabs' data handling choices sit inside the New Zealand Privacy Act 2020, the framework Sant Limited operates under. The same principles map closely to the Australian Privacy Principles and to GDPR's data minimisation and storage limitation articles, which matter to Australian and European users respectively. The posture is to collect what the feature requires and nothing beyond it.
Where this thinking shows up in client work
The decisions behind Sant Tabs are the same decisions Sant applies when building any product that collects user data on behalf of a client. Collection defaults to off. Transmission is justified per feature, not assumed. The boundary between what stays on device and what crosses to a server is named explicitly before the first user sees the product.
That work lives in Sant Launch services. When a product is already in market and the concern is keeping that posture honest over time, Sant Advisory carries the governance conversation.
Frequently asked questions
Does Sant Tabs send my browsing history anywhere. No. The extension tracks which URLs a user visits frequently in a local list stored only in the browser, capped at five hundred entries, and used only to power the in-extension Tab Usage panel. This data is never transmitted.
Does the free tier contact any Sant server. No. The only outbound call from a free user's browser is to ExtensionPay to confirm paid status, and optionally to Google for sign-in if the user chooses to sign in. Neither call carries browsing data or tab contents.
What does Premium cloud sync actually store. Saved tab collections, including full tab URLs, tab titles, and favicon URLs, plus scheduled items and basic settings. These are stored in Firestore under a path keyed to the user's Firebase Auth UID. No other user has access to that data.
What happens to my cloud data if I cancel Premium. Currently, it is retained in Firestore until you explicitly request deletion. There is no automatic cleanup on cancellation. Sant is working on automated deletion on downgrade. Until that ships, users who want their data removed should contact Sant directly.
Does the AI Smart Organise feature store my tabs. The Cloud Function that handles grouping does not write to Firestore and does not log the prompt. The tab data, including titles and URLs, is passed to Google Gemini to generate grouping suggestions and is not retained by Sant after the request completes. Google's standard Gemini API data handling applies to what Gemini receives.
Closing
Privacy in Chrome extensions is not a setting. It is an architecture. The absence of collection has to be built in at every layer: no SDK bundled, no event fired, no default-on transmission, no silent phone home. Sant Tabs does that work on the free tier. The Premium tier adds cloud sync and AI features that require data to move, and the post above names exactly what moves and where. The gap around retention on cancellation is real, acknowledged, and on the roadmap.