Skip to content
Privacy engineering · capability follows data

Metadata-only should be a design constraint

Data minimization is credible when users can see what the product cannot do. If a service claims not to fetch full email bodies but behaves like a full-content reader, the boundary deserves scrutiny.

Launch essay10 minute read

Email data is not body or nothing

An email API can return sender and recipient headers, subject, dates, labels, read state, a provider-generated snippet, full MIME parts, or raw content. Calling every field outside the full MIME payload “metadata” is technically convenient but insufficient for a user deciding whether the exposure is acceptable.

DeclutrMail stores sender, subject, Gmail’s short preview snippet, dates, labels, read state, size, and a small allowlist of list-unsubscribe headers. It does not fetch or store full message bodies, HTML, attachments, inline images, or raw MIME. The snippet deserves explicit mention because a short preview can still contain sensitive language.

The honest statement is narrower and stronger: full bodies fetched, zero; Gmail snippets stored. Precision earns more trust than a broader claim that later requires footnotes.

The data boundary should limit product capability

Without complete content, DeclutrMail should not offer full-message search, complete thread summaries, attachment extraction, or semantic guarantees about what a message means. Sender volume, opens, replies, labels, and recency can support source-level review, but they cannot replace reading a contract, medical result, or conversation.

This is why the interface returns users to Gmail for message content. A deep link is not an unfinished reader; it is evidence that the companion boundary is being respected.

Constraints also protect future product decisions. A tempting feature that requires raw bodies should trigger a visible privacy decision rather than arriving through an unnoticed expansion of the fetch path.

Derived facts need their own threat model

A system can avoid bodies and still accumulate a revealing behavioral graph. Sender frequency, read rate, replies, last-seen dates, Protected status, decisions, and activity history describe relationships and habits. Data minimization must therefore cover retention, access, logs, exports, and deletion for derived records as well as raw API fields.

DeclutrMail’s product needs those aggregates to rank senders and explain recommendations. Observability payloads, worker logs, and error reports are separately barred from carrying email addresses, subjects, snippets, bodies, or OAuth tokens. The principle is containment: a field belongs only in the narrow path that needs it.

Exports similarly separate datasets. A sender decision export should not quietly become a second message-content archive.

External processors are part of the boundary

It is not enough to say what is stored in the primary database. Users also deserve to know what reaches an error service, analytics system, email provider, or language model. The answer may differ by feature.

DeclutrMail’s sender-reasoning path sends Anthropic precomputed aggregate facts without subjects or snippets. Daily Brief has a different contract: its bounded narrative input can include sender identity, subject, and Gmail preview snippet. Full bodies and attachments are never included, and deterministic templates are the fallback when the adapter fails or is unavailable.

Those two paths should never be compressed into “AI never sees email data” or “AI reads your inbox.” Both slogans are false. Field-level disclosure is the useful middle.

Turn privacy copy into executable proof

The strongest implementation does not rely on developer memory. Schema columns define the allowed stored fields. Gmail clients request metadata format. Prompt types omit body fields. Tests fail when a forbidden property appears. Logging helpers redact known sensitive keys. Data exports enumerate exact columns.

Copy should be generated from or tested against the same allowlist wherever possible. Otherwise the homepage, privacy policy, onboarding, and settings will slowly describe different products.

This approach cannot prove the absence of every bug. It makes privacy drift reviewable in code and gives future contributors a clear point where a boundary change must be debated.

Less data can produce a more legible product

A bounded data model forces DeclutrMail to be specific about its job: reveal recurring sources, quantify their cost, present current-mail actions, record outcomes, and return full reading to Gmail. It discourages a feature catalogue built from whatever content can be extracted.

Privacy and product focus reinforce each other here. The missing body is not only something the security page promises. It is visible in the architecture of the experience.

Continue reading

Make the next decision with context

Metadata-only should be a design constraint — DeclutrMail Journal