Security · privacy

The safest data is the data we never collect

Most analytics vendors ask you to trust their controls around dangerous data. Sonder's first control is not having the dangerous data: no session video, no screenshots, no DOM capture, no input values, ever.

What the SDK sends

A masked, semantic event stream: clicked "Save changes" (button) in Billing on /settings/:id. Friction events additionally carry a small structured probe of what was on screen: was an error visible (and its masked text), was a spinner or empty state showing, was the clicked control disabled. Routes are parametrized before transport, so raw IDs never leave the page. Consecutive repeats collapse to one event with a count.

What it never sends

  • No input values. Every form value is [masked] before it leaves the browser.
  • No screenshots, session video, or pixel/DOM recording, and no raw HTML.
  • No mouse-movement or scroll streams.
  • No third-party cookies, no cross-site tracking. The session ID is a random per-tab value in sessionStorage.

Masking, twice

Emails, phone numbers, card numbers, SSNs, and long digit runs are replaced with [masked] in the browser. Sensitive keys (password, token, email, …) are masked recursively in any properties you send. The ingest server then applies the same rules again before storage, as defense in depth: a buggy or outdated SDK cannot smuggle PII into the store. Anything extra, mark with data-sonder-mask and it is masked at the source.

Where data lives

StoreWhatWhere
ClickHouse CloudRaw masked events, 90-day TTLGCP us-east1 (US)
Supabase PostgresAccounts, workspaces, issue registryEast US
Google CloudServices, jobs, secretsus-east1 (US)

All traffic is TLS; all three providers encrypt at rest. Everything is US-region during beta. EU residency is on the roadmap and is not offered today; we say that plainly rather than implying otherwise.

Access control

  • Write keys (the one in your frontend) are write-only by design: they can submit events and read nothing. Revocable per key.
  • API keys (server/MCP) are stored hashed, scoped, and revocable.
  • The control plane enforces row-level security per workspace; every event-store query is workspace-scoped. Retention, deletion, keys, and billing are owner-only operations.

Retention and deletion

Default retention is 90 days, configurable per workspace, enforced by an audited purge job. Workspace owners can delete all data for one person: derived records are deleted immediately with an auditable record; residual raw masked events age out within the retention window, at most 90 days.

The LLM step, plainly

Issue diagnosis sends masked, aggregated friction ribbons to the DeepSeek API. No input values, no screenshots. We flag the provider by name because you should get to weigh it, and the model endpoint is configurable for customers who want to bring their own.

What we don't have yet

  • No SOC 2 report yet; the deliberately small data surface is the preparation, and an audit is planned post-beta.
  • No EU region yet.
  • Single-region deployment; availability is beta-grade.

Documents and disclosure

Draft privacy policy, terms, and DPA are published for review and are watermarked as drafts pending counsel. Report vulnerabilities to macklpgr@gmail.com; a security.txt is served on this site. We aim to acknowledge reports within 2 business days.