Privacy Notice

This notice is about the personal information Kinviq holds about you, why it holds it, and what you can ask it to do with it. It covers the website and the applications that talk to the same servers. It is published at the point where Kinviq first asks you for anything: the sign-up screen links to it, and so does the profile setup that follows.

Only what the product needs to run, and only what these rules cover:

• Your account. The email address you register with, a hash of your password — never the password — the state of the account, and whether your address has been confirmed. There is no name, no phone number and no address.
• Your profile. What you enter during setup: a display name, your date of birth, who the account is for, how you describe yourself, who you would like to be shown, what you are looking for, a city or a region, and any interests you chose. Your exact date of birth and your area are private: no other member is ever shown either.
• What you agreed to. Each statement you accepted, the words you were shown, and the date. These records can be added to and read, never edited or deleted — they are evidence of what happened, so the application is not able to rewrite them.
• Your sessions. When a session was issued, when it was last used, when it expires, and whether it has been revoked. Kinviq stores a hash of the session token, never the token itself, and it does not store a device fingerprint or a user-agent string.
• Security events. Sign-ins and their outcomes, verification attempts, consent records, and significant rate-limit events. These are what an investigation reads, and they deliberately contain no passwords, no tokens and no message content.

The rules Kinviq enforces today, in the product’s own words — the same list the Privacy & Safety screen shows a signed-in account:

• Reaching Kinviq at all. Every account starts inactive and unverified, and stays that way until adult verification is approved. An account that has not passed it cannot browse members, search, message, or reach any protected media — refused by the server on every request, not hidden in the interface. The profile an account fills in during setup is required before verification can even be asked for, and an incomplete profile is refused by the same gate. This is the broadest privacy property Kinviq has, and it is the one that is fully in place.
• Profile visibility. Other verified adults, in the member directory, which is a screen that exists now — and the profile on your own screens is built from the same projection theirs is. The parts that never appear in it — your exact date of birth, your postcode, and the age range you are looking for — cannot reach another member by being forgotten, because the projection is composed from the declared fields rather than written out per caller. Your city appears in it only while you leave city visibility on, and turning discovery off removes you from the directory entirely.
• Search & discovery. The member directory lists accounts that have passed adult verification and have left discovery on, and its search box matches the handle or the city you entered, as a prefix. That is the only place anyone can look for you, and it is behind the same gate you passed to reach it.
• Location. One thing is stored: a city or a region that you typed yourself, such as "Berlin" or "Bavaria". There is no coordinate, no precise position, and no field for a street address — the column is bounded to sixty characters, which is a label rather than an address. Nothing in the product asks your device for a location. Your city is the only part of it another member can ever be shown: it appears on your profile in the member directory while you leave city visibility on, and turning that off removes it from every member-facing surface at once. Your postcode is never shown to another member and is never matched by a search.
• Online status. Presence is published only where you allow it. Your session records a coarse "last seen" timestamp, refreshed at most once a minute: the server uses it to expire a session that has gone idle, and it counts you as online while a live session has recent activity. Another member is told that — and is told when you were last here — only while you leave the two switches for it on, and turning the online one off withholds the timestamp as well, so the two cannot be combined to work out when you were around. No screen draws an indicator beside your name yet, so what exists today is the server's answer rather than a dot.
• Activity visibility. Nothing about your activity is visible to another member, because no member-visible activity surface exists. Account events — sign-ins, verification decisions, privilege changes — are recorded so that security questions can be answered later; they are not shown to other users, and the runtime database role cannot alter or delete them.
• Photos & media. Every upload starts visible to nobody. Nothing you upload is shown to another member until a reviewer has approved that specific item, and the visibility you chose is applied only after that — so the levels below describe what happens to media that has already been through review. A member is never shown your original file: what is delivered is a watermarked derivative, and an item whose derivative does not exist yet is refused rather than falling back to the original. Nothing has a permanent public address: a read is a signed link that expires, and the stored keys are random, so a link cannot be guessed from another one or from your account. Deleting an item removes it and the derivatives made from it together.
• The vault. Nobody but you, and there is no setting that could make it otherwise. A vault item is stored under your account in its own namespace, with a random key, and every route that reaches one resolves it by your account and the item together — there is no share, no request to approve, and no route that returns one to anybody else. The vault is also the one part of the product that is not reviewed: nothing in it is ever shown to another member, so no moderator is asked to read it.
• Blocking. One direction is enough: whoever asked for the block, the two of you stop being shown each other. A blocked member is removed from the directory in the query rather than filtered out of a page, so they are neither listed nor reachable by opening a profile they already had a reference to. On media the block is checked before anything is signed, and it **overrides an access approval you granted before it** — unblocking brings the approval back, because the block refused rather than revoked it. The paths that do not exist yet are the ones that need messaging and calls: there is no conversation to close, no call to refuse and no notification to suppress, so nothing here claims to have closed one.
• Your account and your data. Your email address, and a password digest that cannot be turned back into your password. The state and timestamps of your account and sessions. The answers you gave during setup: a display name, a date of birth, whether the account is for one person or two, how you describe yourself, who you want to see, a city or region, and any interests you chose. The three statements you accepted, each with the exact wording you read and the date you accepted it. And — only when a security event needs to be correlated — a keyed one-way hash of the address a request came from, which is not reversible in practice. There is no legal name, no photograph and no coordinate anywhere in the database. Your raw address is never stored or logged, and the runtime database role cannot rewrite the audit record or a consent record.

What is already true, and does not depend on that decision: the fields that can reveal this are answered by you and nobody else, no other member is shown your date of birth or your area at any point, and nothing about your profile is shown to anybody at all until your account has passed adult verification.

To run the account you asked for: to let you sign in, to keep the account secure, to establish that it belongs to an adult, and to show your profile to the people you chose to show it to. Nothing is held for advertising, and nothing is held to build a profile of you for anybody else.

The formal statement of the lawful basis for each purpose — Article 6, and the separate Article 9 condition for the information described above — is part of the same outstanding legal review. It will be published in a table here, purpose by purpose, and it is not guessed at in the meantime.

Retention periods are not defined yet, and that is a gap rather than a policy: deletion policies are a decision to be taken with legal advice, and until they exist Kinviq does not claim a period it does not apply. What is true today is that nothing is deleted automatically, records of what you agreed to are kept for as long as the account exists because they are evidence, and nothing is kept forever by design.

Nobody else, at the time of writing. Kinviq sends no data to an advertising network, an analytics service or a social platform, loads no third-party fonts, and has no advertising or profiling partner of any kind.

That will change when Kinviq connects services it does need — an email provider and an age verification provider — and each one is a deliberate decision with its own data flow. When one is chosen, it is named in this notice, with what it receives and where it is, before it is used. Identity documents and verification media will be handled under their own retention rule and never reused for anything else.

Under the UK GDPR you have the right to be informed, to see what is held about you, to have it corrected, to have it erased, to restrict what is done with it, to object to it, to receive it in a portable form, and to withdraw consent where consent is what Kinviq relies on. Withdrawing consent never affects anything you were entitled to before you withdrew it.

There is no self-service way to exercise these yet — no data export and no account closure — and the product says so on the screens that would otherwise imply it. That is a build gap, and it is recorded as one.

Kinviq sets two cookies, both of which are strictly necessary: one holds your session so that a page you load knows who you are, and it cannot be read by scripts; the other is the cross-site request token that stops another site from acting as you. There is no advertising cookie, no analytics cookie and no tracking pixel, so there is no consent banner — a banner asking permission for something the site does not do would be a lie about the site.

The words below are recorded, with the version and the date, when you accept them:

• “I confirm that I am 18 years of age or older, and that the date of birth I gave is my own.”
• “I understand that my exact date of birth is never shown to anyone, that my city is the only part of where I live that my profile shows, that my postcode is never shown to another member and is used only to work out how close people are, and that no part of Kinviq shows my profile to another member until I have passed adult verification.”
• “I agree not to share anyone else’s profile, media or messages outside Kinviq, and I understand that consent asked for once does not apply a second time.”
• “I agree that Kinviq may store the answers I choose to give about my sexual orientation and my intimate interests, that giving them is optional and I can remove them at any time, and that they are shown to other verified adults only if I leave them on my profile. I understand these are sensitive answers about my sexuality and that I am giving them freely.”

Before you can create an account you also affirm two things on the sign-up screen: that you are 18 or over, and that you accept the Terms of Service and the Community Guidelines. Those are statements about the account, not consent to process anything, and they are recorded separately for that reason.

If you are unhappy with how Kinviq has handled your information you can complain to the Information Commissioner’s Office, which regulates data protection in the United Kingdom, at ico.org.uk/make-a-complaint. A contact address for Kinviq itself is one of the details still to be added, for the reason given in the Terms of Service.