Privacy Policy

Letterprove has two kinds of people in it: vendors, who sign up and install our script on their own site, and the visitors to those sites, who never interact with us directly.

For vendors, we hold an account and the configuration you enter. For visitors, we record the company domain, and the country and region a request came from — never a name, never an email address, never an IP address, and no cookies. We do not set anything on your device, and there is nothing on a vendor's site that identifies you personally to us.

When someone signs up, logs in, or starts a session on a vendor's site, the Letterprove script sends us a single small message. It contains exactly five things, and we store one more:

• The vendor whose site it came from.
• The email domain — acme.com, or gmail.com. The domain only. Not the address, not the local part, not a hash of either.
• The kind of event — one of session, signup, or login. Nothing else is a valid event.
• A configuration version number, so we can tell old installs from new ones.
• The origin the request came from, as the browser reported it.
• Our own receipt timestamp, taken from our server rather than from the message, so it cannot be backdated.

That is the complete list. We do not receive names, email addresses, IP addresses, user identifiers, device fingerprints, page URLs, form contents, or behavioural data, and we set no cookies and no local storage. A domain like gmail.com tells us nothing about a person; a domain like acme.com identifies a company, which is the entire point of the product.

If this changes, this page changes first. This is that change, made before the collection starts rather than after it.

Approximate location, starting shortly. To detect fabricated traffic we are adding two more fields to the list above: the country and the first-level region (a state or equivalent) that a request arrived from, as our hosting provider reports them from the network. Real usage by real companies comes from many places; traffic invented to look like customers usually comes from one. That difference is only visible if we record roughly where requests came from.

This is deliberately the coarsest form of that signal. We do not record the city, the latitude and longitude, the postal code, or the IP address itself, even though our hosting provider offers all of them — a region contains millions of people and identifies none of them, and the extra precision would buy us nothing a spoofer couldn't defeat anyway.

We considered recording the network operator each request came from, which is the sharper signal because it distinguishes a data centre from a home connection. We are not doing it: it would mean either shipping a commercial address database or sending every visitor's IP address to a third-party lookup service, and the second of those is a far larger disclosure than the problem justifies.

Two checks run before anything is stored, and both fail closed — a rejected event is discarded, not queued:

• The request must come from the vendor's own domain. An event claiming to be from a site it did not come from is dropped.
• The vendor must have proven control of that domain by publishing a DNS record we specify. Until they do, nothing they send is stored at all — so nobody can accumulate a history on a domain they do not own.

Letterprove is a publishing product, so this section matters more than it usually would.

Aggregate counts are public. A vendor's proof page shows totals — how many companies were observed, how many sessions, how many signups. These name nobody.

A customer is only ever named with their consent. Consent is opt-in and the default is anonymous: a customer added without anyone considering the question is withheld from publication, never published by accident. A named customer is counted in the totals either way; consent controls whether their name appears.

We never publish individual events, individual visitors, or the raw domain list. The per-domain view exists only inside the vendor's own dashboard and our internal staff tools.

Letterprove holds no vendor identity of its own — signing in and organization membership are handled entirely by Letterstory, which Letterprove trusts as an authenticated peer. We do not store a vendor password or password hash. We do store what you enter about your company and customers: names, domains, categories, the date a relationship started, and which features you claim.

Your publishable key is not a secret. It ships in your page's HTML by design, which is why the domain checks in §3 exist — the key alone cannot authorise anything.

Data is isolated per account by Postgres Row Level Security, enforced by the database rather than only by application code. Observation tables carry no access policies at all, so only our own backend can read them.

Published attestations are signed with an Ed25519 key and chained to the one before, so a published claim cannot be altered after the fact without breaking the chain. Anyone can verify this independently — the verifier is open source and re-implements the check rather than importing ours.

Traffic is encrypted in transit over TLS. No system is perfectly secure.

We keep this list short deliberately. Letterprove uses:

• Supabase — database.
• Vercel — application hosting.
• Letterstory — vendor sign-in and organization membership. Letterprove holds no identity of its own; see §5.
• Resend — delivers the consent emails described in §4, when a vendor asks us to send one.
• Stripe — reads a vendor's own connected account, at their instruction, to corroborate a customer's paid subscription for a higher provenance tier. We do not process payments and do not receive card data.
• Slack — internal alerting for our own team; no vendor or visitor data is routed through it.

We do not use advertising trackers, we do not use visitor de-anonymisation services on this product, we do not sell information, and we do not build behavioural profiles.

A vendor decides to install our script and decides which of their customers to record. For that data, Letterprove acts on the vendor's instructions rather than deciding independently what to do with it. We have not yet formalized this in a signed data processing agreement; if your organization requires one before you can use Letterprove, contact us at the address below. If you are a visitor to a vendor's site and want to know why your company domain was observed, the vendor is the right first contact — though you are welcome to reach us directly and we will help.

Raw observations — the individual events our script sends — are deleted after 35 days. What we keep for as long as the vendor's account is active are hourly counts per company domain, which carry no per-person data, and the signed attestations built from them, because the published history is cumulative and a signed chain cannot be silently rewritten.

Vendors can delete customer records from their dashboard at any time, which removes them from future publication. To delete an account and its underlying data, write to us and we will action it.

We will update the date at the top when this changes, and for material changes — such as collecting a category of data not listed in §2 — we will make a reasonable effort to notify vendors before it takes effect.

Questions about this policy, or a request about data concerning you: support@letterbrace.com