How Affinira protects your data
Affinira handles the most personal professional data there is: who you know, why they matter, and what you said to each other. This page describes the protections that exist in the product today, and states plainly each control’s current boundary. The product tour is a working prototype whose identities are synthetic demonstration data; on sites set up for saving, what you save in the account area goes to a real database and the screen tells you whether it went through, and on sites that are not, it says the action is unavailable instead of appearing to accept it. Where a capability is missing, the control that needs it is withheld and its absence is named rather than left to be discovered.
The public/private boundary
For the served demo profile, visibility tiers determine which contact details its public projection permits. Only the public tier admits anything: the projection copies the channels and links marked public and excludes every other tier, so the difference between the two withheld tiers below is a design distinction this build does not act on yet.
Public
Shown on a public demo profile to anyone with the link — only details configured as public, such as a work email or a booking link.
On exchange
Withheld from the public page entirely — a personal mobile number is the typical example. Releasing these details to someone you have exchanged with is designed and not built: nothing hands out a withheld detail.
Private
Never reaches a visitor under any circumstance: not on the public page, not in the downloadable contact card, and not through any exchange — designed or built.
The boundary is enforced in code, not by the page choosing what to display. The data sent to a public profile is built by a strict projection that copies each permitted field by name — a new field is private by default until someone deliberately decides otherwise — and the result is verified against a strict schema that refuses to serve anything unexpected rather than quietly dropping it. Private notes, memories, and follow-ups have no path onto a public page at all. The same projection feeds the downloadable contact card, so the file a visitor saves can contain nothing the page would not show. And what you write about the people you meet is yours alone: it never appears on any public surface.
Protections running today
Each of these is part of how the product is built.
Unpublished and unknown look the same
An unknown profile address and an unpublished one return the identical "not found" response, so nothing distinguishes a person who has not published a profile from an address nobody holds. A published profile is public by design, and is returned to anyone who visits its address.
Links are validated twice
Every link a profile can carry must be an http or https URL. The rule is enforced when a link is entered and enforced again before anything is rendered to a visitor, so a hostile value that never met the editor still cannot reach a public page.
Security headers on every response
Content-type sniffing protection, a strict referrer policy so outbound clicks reveal only our origin, frame denial against clickjacking, and a restrictive permissions policy that refuses browser capabilities the product does not use.
No tracking; analytics only by consent
The site sets no tracking cookies. The only analytics is Vercel Web Analytics — cookieless, and loaded on marketing pages only after you affirmatively accept it in the consent banner. Rejecting or ignoring the banner loads nothing, and withdrawing consent stops it.
Secrets stay out of the code
No secret value is present in the code delivered to your browser.
Each control’s current boundary is stated below
They are written and tested against a database built from the same files, and each save reports its own outcome. Where a site is not set up for saving, the account features they belong to are unavailable rather than unprotected. That is not the same as nothing being kept. The exchange form on a public profile is filled in by the visitor, not by the profile’s owner. After a successful exchange-form save, your submitted details are stored in this browser’s session storage. That save does not deliver them to the profile owner. We list these controls because the design decisions are already made, rather than promised.
Row-level security in the database
Where a site is set up for saving, a save is sent to a database and the screen tells you whether it went through. The access rules for that database are written here and tested against a local database. A site not set up for saving refuses the save before taking anything. As written and tested, the rules let only you read your relationships, your notes, and any channel or link you mark private; they treat the fields you mark public as public, and show them at your address only while your profile is published; and they let the members of your organisation read the rest of your profile. Keeping one organisation out of another’s records is one of those rules rather than an application habit, and they are exercised against a real PostgreSQL in testing.
Append-only consent records
When someone shares their details with you, the record of what they consented to is designed to be append-only. As written into the same schema and held under the same local tests: a signed-in user can create and read such a record but not change it, and the record survives the deletion of the connection it belongs to — deleting the whole organisation removes its records with it. Nothing in the product writes such a record on a server yet — the exchange form keeps its record in the visitor’s own browser — so the rule stands ready rather than protecting anything today.
Reporting a security issue
If you believe you have found a vulnerability in Affinira, write to hello@affinira.com with enough detail to reproduce it. This page publishes no bug-bounty programme and no response-time commitment — saying so is more useful than implying a process it does not publish.
One thing this page deliberately does not do: claim certifications or compliance badges. No certification is claimed on this page, and a page that describes real behaviour is worth more than a logo that implies it. How personal data is handled in practice is described in the privacy policy.
Privacy is the product working as designed.
The boundary described above keeps every field marked private out of the public projection.