privacy policy

1who is responsible

plain-language summary: HERE and more, operated from prague. one address for anything about your data.

The controller of your personal data is the operator of HERE and more, operated from Prague, Czech Republic (“HERE and more”, “we”, “us”). This policy covers hereandmore.com, the HERE and more desktop and mobile applications, igni, the JEM identity, and the connected surfaces we operate.

For anything concerning your data, write to lnk@gradientrising.com.

2what we hold

plain-language summary: your entry, what you bring into your room, thin technical traces, and a record of how you move through the service. payment cards never touch us.

• entry and identity — the name or identifier you choose, your email address, your passkey public keys, and the device metadata that comes with them. The operator also keeps a roster record about you that you cannot edit yourself: your role, your tenant, the teams and projects you belong to, a note about you, your daily usage budgets, and who invited you or added you to each room. That roster is written by adding a new line rather than changing the old one, so earlier versions of those fields remain.
• identity verification — where a feature requires you to prove who you are, you upload a photograph of a document and a selfie. This is not sent to an outside company: the check runs on our own machine. The images are held only for the check — the verification service deletes them, and because its deletion was once found to be unreliable we run our own sweep every hour that removes any image its records no longer point at. What we keep afterwards is the result, and we keep it indefinitely: the legal name and document type read off the document, its expiry, a one-way hash of the document number, a confidence score, and, where a check fails, a short reason. We compare that hash against other accounts, so the same document appearing twice is visible to the operator.
• how you move through the service — separately from what you write: which room you last read and when, for every room; a record of applications being opened and closed, with the page address and a short note; and, where your client sends them, a receipt for each symbol you tap on a message. When the operator points the cockpit's lens at one particular person, a timeline is also written of that person arriving, stepping away, speaking in a room, and opening applications. That is written for one selected person at a time, only the operator can select them, and the person is not told.
• your devices — if you turn on notifications, the address of that device and a short identification of its browser. We do not keep the encryption keys your browser offers alongside them, because we send it nothing to encrypt.
• what you bring — messages, files, voice notes, images, and everything you place in your room or share with people and apps inside the service.
• technical traces — IP address, device and browser type, timestamps, and security and diagnostic logs.
• payment — handled by payment processors; we receive confirmations and billing status, never full card numbers.

3why we hold it

plain-language summary: to run the service you asked for, to keep it safe, to meet legal duties — and, for the operator's sight of everything in it, an interest we name out loud rather than let you discover.

We process personal data on these legal bases:

• contract — to provide the service you entered: your room, your people, your apps, igni, downloads, memberships.
• legitimate interests — to secure the service, prevent abuse and fraud, diagnose failures, and improve how it works. We rely on this basis for one further thing, and we would rather name it here than let you find it: the operator's oversight of the whole service, described in section 6. Every message you send is also copied into the operator's own working record, and where igni answered, that copy carries igni's full working — including the excerpt of other people's words that igni was shown. None of that is switched on by your consent, and none of it is needed to deliver your room to you. We weigh these interests against your rights, and you may object at any time.
• legal obligation — to keep what tax, accounting, or other law makes us keep, and to answer lawful orders.
• consent — for anything optional you switch on. Consent can be withdrawn at any time, without affecting what happened before.

We do not sell personal data, and we do not build or trade advertising profiles.

4igni and machine processing

plain-language summary: when anyone in your room writes igni's name, igni is shown the recent conversation there — not only the words addressed to it. a room can also be wired to an outside program, and you are not shown which rooms are.

igni answers when someone writes its name. When that happens it is shown more than the message that named it. It receives:

• the room you are standing in — up to the last 24 messages of that room, each shortened, and each carrying the speaker's display name, whether or not those people addressed igni, wanted it there, or knew it had been called. Nobody in the room is asked first, and there is no way to switch it off. This does not happen in your own private line with igni. One real limit holds: the excerpt is read with the permissions of the person who called igni, so room membership, messages taken back, and igni's private asides to other people are all applied first. igni is not a way into a room the person asking could not already open.
• your own recent line — your last few messages and igni's replies to you from across the whole service, regardless of which room you wrote them in, including private ones.
• facts about your account — your display name, member id and role, your teams and projects, any live cloud desk you have open, and the code organisations you belong to. These are attached to every question; you do not choose them each time.
• excerpts from documents — text retrieved from the document corpus your organisation and teams are entitled to see.

Nothing is anonymised on the way out. Real names and member ids are sent as written.

In the ordinary configuration, a member's conversation with igni runs on a model we host on our own machine, and no outside model provider is involved in it. We state that as configuration rather than architecture, because the destination is a setting and the same content would follow it elsewhere. Where parts of this processing run on vetted model providers, they act as our processors, bound by contract to process your data only on our instructions and only to provide the service. We do not permit your personal data to be used for third-party advertising.

room apps — separately from igni, a room can be wired by the operator to an outside program. Where one is wired, every ordinary message in that room is handed to that program as it is sent, together with who sent it, before and regardless of whether igni was named. Members are not shown that a room has an app; only its replies appear. Where those words travel next depends on what was wired up. Ask us whether a room you are in is wired to an app, and we will tell you.

Machine-generated content is produced automatically and can be wrong; the terms of service describe your responsibility when acting on it.

5your keys and your face

plain-language summary: your fingerprint and your device's face unlock never reach us. if you verify your identity or scan yourself in, photographs of your face do.

Entry to the service uses passkeys (WebAuthn). Your biometrics — face, fingerprint — are verified inside your own device and are never transmitted to us or stored by us. What we receive is cryptographic: a public key, and signed confirmations that your device unlocked it. That sentence is exact, and it is about signing in. Two other features involve your face, and neither is covered by it.

identity verification — if you verify who you are, you take a selfie in the browser and it is uploaded to us. It is held for the length of the check and then removed, both by the verification service and by our own hourly sweep, which exists because that service's deletion was once found to be unreliable. What we keep is the result of the check, not the photograph.

scan-in — if you are invited on a personal line, you may consent to a guided capture of your face from four angles, and optionally a scan of your body. Those images are stored on our servers, not on your device, and they are visible to you and to the operator. Scan-in is optional, granted one scope at a time, and you can erase it — this is the one place in the service where deleting truly destroys the files. We keep the record that a capture existed.

Passkeys are the way in we intend you to use, and the strongest one — but they are not the only one, and an earlier version of this policy said they were. Signing in offers three things: a passkey, a password, and signing in through Discord, Spotify or X. The service does have passwords. If you have one, it is a way into your account and worth protecting as one; if you would rather not have one, use a passkey and do not set a password.

6who we share with

plain-language summary: the machines that run the service, the people you choose, the operator — who can read every room — and the law when it genuinely demands.

• the operator — the operator of HERE and more can open any room in the service, including a private conversation between two other members, without being in it, without asking you, and without anything being shown to you. That means reading a room's whole history, searching every message anyone has ever sent, opening the files attached to them, receiving new messages live as they arrive, and writing into the room. The count of people a room shows you counts its members, not an operator who is reading it. It is one person, and that is now a fact about who they are rather than a setting: until 8 august 2026 an ordinary roster field could carry the same power, and it can no longer be granted by editing the roster. One thing is genuinely withheld even from the operator: an aside igni addresses privately to a single person. We would rather state this plainly than let a member count imply a privacy the service does not enforce.
• people you choose — what you write into a room is shown to the members of that room, and to nobody else outside the operator. Membership is checked on every path that serves it: the room's history, search, and — since 8 august 2026 — the files attached to it. Until that date a photograph or document could be opened by any signed-in member who held its link, whether or not they were ever in the room; that is fixed, and a file now answers to the room it was said in, so taking the message back withdraws the file with it.
• processors — infrastructure hosting (Hetzner) and payment processing, each under a data processing agreement and only as needed for their task. Identity verification is no longer on this list: that check runs on our own machine (section 5). Neither is email delivery: the service sends no mail of its own, and messages about signing in come from the sign-in system.
• model providers — a member's conversation with igni runs on a model we host (section 4). Separately, when the operator brings assistants built on Anthropic's, OpenAI's or xAI's tools into a cockpit thread, the contents of that thread go to those companies — and those threads carry the copies of member messages described in section 3. That happens on the operator's side rather than from your room, but your words can reach those companies that way.
• notification services — see section 13.
• your sign-in provider — you can sign in through Discord, Spotify or X. If you do, that company sees that you signed in.
• authorities — when a law, court order, or enforceable request genuinely requires it, no wider than required.
• a successor — if the service changes hands or form, your data may move with it under the same protections, and you will be told.

7where it lives

plain-language summary: on servers in the european union.

Primary infrastructure runs in the European Union (Hetzner, Germany and Finland). Where a processor operates outside the European Economic Area, transfers rest on recognised safeguards — an adequacy decision or standard contractual clauses — and we keep those transfers as narrow as the task allows.

8how long we keep it

plain-language summary: we keep it. almost nothing expires on its own, and there is no button that closes an entry.

An earlier version of this section promised deletion on a schedule. There was no such schedule. Here is what actually happens.

The record of what is said in HERE is written by adding to it. Every message goes into a running record that nothing trims or deletes. Taking a message back adds a line saying so, and the room stops showing it — the original line and its text stay where they are. Uploaded photographs and documents are not swept at any age. Roster records, room membership history, read positions, application usage and notification device records have no expiry either; turning notifications off records that you did and leaves that device's address on file.

Two things genuinely go. A scan-in capture is destroyed when you erase it, leaving only the record that it existed. And the images from an identity check are removed once the check is done, by the verification service and by our own hourly sweep — though the result of the check is kept indefinitely (section 2).

There is no action that closes an entry and removes what it wrote. A member cannot close their own entry; no such control exists. The operator can revoke a personal line or mark someone archived, which withdraws their access and deletes nothing.

So, plainly: we keep your data indefinitely, including messages you have taken back. If you want something erased, write to us and a person will do it and tell you what could not be removed. There is a real constraint behind that: the message record is hash-chained so that any alteration is detectable, and removing a line breaks the chain that proves the rest is intact. That was our design decision, not an excuse, and it is why erasure here is manual.

Security and diagnostic logs record the method, path and result of requests. They hold no message content and no query strings. They go to the host's system journal and are kept until it reclaims the space, which is a limit of size rather than of time; we impose no period of our own and perform no anonymisation. We would rather say that than state a number we have not verified. The same applies to backups: we keep them, and we no longer claim a horizon we cannot evidence.

Where the law requires us to keep something — tax and accounting records above all — we keep it for as long as it requires, and no longer.

9how we protect it

plain-language summary: keys as the main way in, encryption in transit, regular backups. ordinary messages sit unencrypted on our disk where we can read them; a sealed chat does not, and section 9 says exactly what that is worth.

Protection is built into the shape of the service: passkeys as the primary way in, encryption in transit, isolation between systems, and regular backups. We work to protect your data seriously and continuously — and we say honestly that no system is invulnerable, and we cannot promise absolute security.

Two things belong in that list and were missing from it.

stored messages are not encrypted — every message, in every room, including private conversations between two members, is written as ordinary text into a file on our server. It is protected by that machine's permissions and by nothing else. The record is hash-chained, which makes tampering detectable; it conceals nothing.

ordinary chats are not end-to-end encrypted — we hold those messages in the clear and we work on them: we serve them, we search them, and we show them to igni. Anyone with access to that server can read any ordinary room. That is still the default, and it is what section 6 describes.

a sealed chat is the exception, and it is a chat type you choose — your browser encrypts each message in a sealed chat before it reaches us, under a key we never receive. What we store is ciphertext. We do not run our text tools over it, it is not returned by search, it is never copied into the operator's own threads, and it is never put in front of igni — igni holds no key for a sealed chat and is never given one.

what a sealed chat is worth, exactly — the code that does the encrypting is code we send to your browser, fresh, every time you open the room. We do not offer you any way to check that it is the code we published, and we could send different code to one person. So a sealed chat protects your words from the record we keep: from us reading it later, from anyone who takes a copy of it or of our backups, and from a demand that we hand over what we hold — what we hold is ciphertext, and it stays ciphertext. It does not protect them from us at the moment you type them, and it does not protect what you say after somebody has compelled us to change the code we send you. If that distinction matters to you, it should decide what you put in a sealed chat.

the copy of your key that we hold — a sealed chat's key is generated in your browser and shown to you once. You carry it to the people who should read that chat; we never receive it. You may also choose a passphrase, and we then keep a copy of the key wrapped under it, so your other devices can open the chat. We cannot read that copy. But it is on our disks, its strength is your passphrase and nothing else, and anyone who takes a copy of it — a breach, a backup, a lawful demand — can attack it offline for as long as they like. A short passphrase is a short answer. If you would rather we held nothing, do not set one; that chat will then open only on the devices you carried the code to, and if you lose it there is nothing anyone can do.

what is not sealed, even in a sealed chat — the words are sealed and the rest is not. We still hold, permanently: that the chat exists, what it is called, who is in it and every change to that, and for each message who sent it, exactly when, roughly how long it was, and what it replied to. Reactions and pins are not sealed. A sealed chat carries no photos and no files at all — attachments go in an ordinary chat, in the clear. It cannot be searched, by you or by us. Naming somebody in one does not reach them.

a sealed chat can be opened, once — anyone in it can ask to open it, and everyone in it is asked to agree. Opening it publishes the key into our record. From that moment its whole past is readable — by everyone in the chat, and by us — and it can never be sealed again. That is not a setting we promise not to change: the key is simply out, and a key other people already hold cannot be taken back.

and one person can do it alone — we would rather say this plainly than let the word "consent" carry more than it can. Everyone in a sealed chat holds the same key, so any one of them can publish it without waiting for the others, exactly as any one of them could always have pasted the words somewhere else. We ask everyone, we record who agreed, and if somebody opens it without them the record shows who did and who had not answered. The counting itself happens in that person's own browser: we cannot verify it, and you should not read our word for it as proof.

what an opened chat looks like afterwards — new messages in it are ordinary messages, held in the clear like any other room, and section 6 applies to them again. The old sealed messages stay as they are: readable by everyone in the chat, and by us, but they are not put back into search and are never shown to igni, because what we stored for them was never words.

anyone holding the code can hand it to anyone — including to us. If that happens the whole past of that chat becomes readable, by us and by anyone holding a copy of our records, and it cannot be made unreadable again. That is what sharing a key means, and no mechanism of ours changes it.

The previous version of this section said access is limited to what each part needs. We have removed that sentence, because it is not true of the operator's access, which is limited by nothing (section 6).

10your rights

plain-language summary: every right below is yours in law. two you can use yourself; for the rest, a person does it by hand.

Under the GDPR and Czech law you have the right to:

• access your personal data, and receive a copy — you can read your own messages and search across every room you can stand in, and you can see your identity record and your own scan captures. There is no button that hands you a copy of everything; write to us and we will assemble it.
• rectify what is inaccurate — you can correct your own message, and the room shows it marked as edited. You can change your declared legal name and your identity profile yourself. Your display name, role, tenant, teams, projects and the operator's note about you are set by the operator; write to us and we will change them. You should also know that the same mechanism that lets you correct your message lets the operator rewrite the text of yours, and the room shows only that a message was edited, not who edited it.
• erase what we no longer need to hold — the honest position is in section 8. Taking a message back hides it from the room and leaves the text in the record. The only thing you can destroy yourself is a scan-in capture, and that destruction is real. For anything else, write to us; we will delete what we can and tell you plainly what we could not.
• restrict processing while a question is resolved — write to us.
• object to processing based on legitimate interests — write to us. That includes the operator's reading of rooms and the copying of messages into the operator's working record, in sections 3 and 6.
• portability — take the data you provided in a machine-readable form — there is no export in the service. Write to us and we will produce a machine-readable copy by hand.
• withdraw consent at any time, for anything based on consent — this works for both things that ask for it. Scan-in: you can withdraw and erase the captures yourself, and the files are really destroyed. Notifications: the same control that switched them on switches them off, and pressing it stops us waking that device. Until 8 august 2026 there was no such control, and the only way out was your browser's own site settings; that is fixed. Switching off does not remove the device record we already hold (section 8), and blocking notifications in your browser still works as a second route.

Write to lnk@gradientrising.com and we will answer within one month. You also have the right to complain to a supervisory authority — in the Czech Republic, the Office for Personal Data Protection (Úřad pro ochranu osobních údajů, uoou.gov.cz), or the authority of the country where you live.

11cookies

plain-language summary: only the cookies that keep you in. no trackers, no ads — which is why there is no cookie banner.

The service sets only strictly necessary cookies: session and security cookies that keep your entry open and safe. There are no advertising cookies, no cross-site trackers, and no third-party analytics riding along. Because nothing beyond the essential is set, no cookie consent is asked for — there is nothing to consent to.

12children

plain-language summary: the service is not for children under 15. we never ask anyone's age, and if we learn of a child we act by hand.

The service is not directed to children under 15 years of age, and we do not knowingly hold their data. We should say what we do and do not collect: the service never asks for or records anyone's age or date of birth. Where identity verification reads a date of birth from a document, it is used to check the document and is not stored.

If we learn that an entry belongs to a child below the required age, we will act to end their use of the service and remove what we can. We will not promise more than the service can do: there is no single action that closes an entry, and what has already been written into the message record cannot simply be deleted (section 8). We will do that work by hand, and tell whoever raised it what we could not remove.

If you believe a child is using the service, tell us.

13when we wake your device

plain-language summary: notifications are the one thing here you switch on yourself. the wake-up we send is empty — your own browser fetches the words.

If you turn on notifications, your browser gives us an address for that device, and we keep it along with a short identification of the browser (section 2). This is the one processing on the member surface that rests on your consent.

When something happens in a room you are in, and you are not already looking at it, we send a wake-up to the push service your browser uses — Google's, Apple's or Mozilla's, depending on the browser. That wake-up carries nothing. No message, no sender, no room name: the request body is literally empty. Your browser is woken, and it then asks us — over your own signed-in connection — what happened, and writes the notification from our answer. So the words you read on your lock screen came from us to you, and the push service never sees them.

What that service does necessarily learn is that one of your devices should be woken, and exactly when. Over time, that is a record of when you are active. Each of those requests also identifies this service to it, by an address and a fixed key, which lets it recognise every device here as belonging to one service. We hold none of the keys that would let us encrypt content to your device, because we send it no content.

Turning notifications back off is described in section 10, and is not yet as easy as turning them on.

14what is broken, and not yet fixed

plain-language summary: things we know are wrong, written down before you find them. this list should get shorter.

A policy that only described the parts that work would be a kind of lie. These are defects we have found in our own service. We would rather you learned them here, and this list is meant to get shorter.

a message you take back still counts — it leaves the room, and it leaves search, but the room's unread badge still counted it before you withdrew it, and it still spent a word from your daily allowance. Neither is repaid.

the notification control can be out of date — it reads whether your browser holds a subscription, not whether our own records still list your device. If we retired your device because its push service told us it was gone, the control can still say notifications are on. Pressing stop always works; the label can be wrong.

closed on 8 august 2026 — four things that were on this list, or should have been, are fixed, and are recorded here rather than quietly removed: a message taken back stayed findable by searching (§10); a file's link worked for any signed-in member regardless of the room (§6); there was no way to switch notifications off from inside the service (§10); and the power to read every room could be granted by editing an ordinary field on the roster, which for three weeks in july was held by somebody outside the company (§6). That last one was found while checking this policy against the code, and it is the reason version 3 of this page says something narrower about the operator than version 2 did. Whether the service has passwords was an open question here, and is now answered plainly in §5: it does.

15changes

plain-language summary: this page carries the current date. material changes get a heads-up.

We may update this policy as the service evolves. The effective date at the top always shows the current version. For material changes we will give notice within the service, or by other reasonable means, before they take effect.

16contact

plain-language summary: one address. a person reads it.

For anything in this policy — questions, requests, rights, worries — write to lnk@gradientrising.com. Postal contact details are available on request.