We collect and process the following categories of personal data:
3.1 Account Data
- Name and email address. Depending on how you sign in, these come from your Google account (Google sign-in) or directly from you (email verification code).
- Optional public username (@handle), used for sign-in, invites, and your optional public Nemi card.
- Profile picture (from Google or a photo you upload; optional animated photo on eligible plans).
- Passkey credentials, if you register a passkey: we store the public key and related metadata, never the private key, which stays on your device.
- Account creation date and authentication tokens.
- Plan status used for product features such as verified badges (blue or gold checkmarks, and a black one for people who work on Nemi) shown next to your name where the Service displays senders and collaborators. An account that holds more than one badge stores which one it chose to show.
- Which notifications you have read. Until August 21, 2026 this was kept only on the device you were using, so reading something on a laptop left it unread on a phone; it is now stored with your account so your devices agree. We store the identifier of the notification and the moment you read it, nothing about what the notification said, and we delete those marks once the notification itself has aged out of the list after 14 days.
- Interface preferences that follow you between devices: your theme, your accessibility settings, and whether you have finished or dismissed the first-run aids such as the product tour and the getting-started checklist. These are settings, not activity: we store what you chose and when you dismissed something, never a record of what you did in the Service. Preferences that only make sense on one device, such as which view a folder was last shown in, stay in that browser and are covered by Section 8.
- Where your name and photo are shown to people you send links to. A recipient sees your name, your profile picture and your verified badge on the page behind a link you sent them, next to what you sent. On a password-protected link they see that before entering the password, because knowing who a link is from is how somebody decides whether to trust it at all; what the link CONTAINS, meaning the file names and sizes, stays hidden until the password is right. Earlier versions of this policy described where badges are shown but did not say this plainly, and until August 26, 2026 your name was in fact already delivered to the locked page without being displayed on it. If you do not want a recipient to see who sent something, do not send it from an account with your name on it.
3.2 Billing Data
- Subscription status and plan type.
- Payment information is processed directly by Stripe and is never stored on our servers. We only store your Stripe customer ID and subscription ID.
3.3 Content & Usage Data
- Files you upload, and documents, spreadsheets, forms, and canvases you create.
- File metadata: name, size, type, upload date, expiry date, and malware scan status.
- Authorship information in collaborative documents: edits are attributed to the account (or connected AI assistant) that made them, so collaborators can see who wrote what.
- Share link settings and analytics: number of downloads and opens, and timestamps. If you switch on Trace for a link, considerably more than that, and Section 3.10 sets out exactly what.
- Comments on a document you publish with reader comments switched on: what a reader writes on the published page, and the name they give. Only comments written on the published page are shown there; comments you and your collaborators write inside Nemi are never shown to readers. A correction, October 3, 2026: until this date, comments written inside Nemi by the people working on a published document could appear in its public comment section, readable by anyone with the address. Each comment now records where it was written, and only those written on the published page are shown there.
- Review rounds on a share: the versions you put up for review, the comments left on them and where in the file each comment is pinned, and the approval or rejection with the name of whoever gave it.
- Workspace information, folder structure, and contacts.
- Files can be moved or copied to another of your workspaces. Somebody who can add files to two workspaces can send files from one to the other. A moved file leaves the first workspace completely: its members stop seeing it, and share links, rooms and review rounds there that included it stop showing it. Because that takes the file away from everybody in the first workspace, you can only move files you uploaded yourself, unless you are an owner or admin of that workspace. A moved or copied file counts towards the storage of the workspace it arrives in, follows that workspace's plan and retention, and is still counted as uploaded by the person who uploaded it when it is moved; a copy has you as its uploader. A file that is still being scanned for viruses waits until the scan has finished. Files in a vault cannot be moved or copied out of it, and nothing can be moved into one.
- Contacts: email address, optional name, optional username, and (when known) a link to a Nemi account. Contacts are private to your account. We may create or update a contact when you share files, invite someone to a workspace or folder, or add a collaborator by email or @username. We do not operate a global public directory of all users. A correction about usernames. A username is meant to be the thing somebody can give out instead of their email address. Until August 26, 2026 it was not: addressing somebody by their @username alone caused us to look up the account behind it and store that account's email address in the sender's contacts, where it was then offered back to them the next time they shared something. Anybody who knew a username could obtain the address behind it, about anybody. We said on that date that this was fixed, and it was only partly true: the contact save itself stopped copying the address, but sharing a document with somebody by @username, inviting them to a folder or a workspace by @username, and emailing a link to a Nemi account you picked still passed the account's address into the contact, so the leak continued on those paths until September 26, 2026. It is now fixed on every path: a contact you added by username holds the handle, the display name and a link to the account, and no address, and the only address a contact can hold is one you typed yourself. On the same date we removed the addresses that had already been copied: every contact linked to a Nemi account no longer holds that account's own email address. That also removes the address from a contact whose owner had typed it in themselves, because we cannot tell the two apart; the contact stays linked to the account and sharing with it works as before. The list of open workspace invitations had the same fault, showing the owner the address of somebody they had invited by username, and now shows the username instead. A second correction, about addresses. The rule is that an email address you type tells you nothing about whether a Nemi account is behind it, and a username never tells you the address behind it. Until September 26, 2026 several parts of Nemi broke that rule, and anybody signed in could use them to check whether an address belongs to a Nemi account and whose it is: sharing a calendar with an address added its owner as a member straight away and showed their name, photo and main email address; inviting an address to a document showed the account's name and badge and marked it as joined before they had opened anything; a pending folder invitation showed the account's name and photo to every member of the workspace; saving or sharing with an address linked the contact to the account behind it; signing in with a passkey answered differently for an address that had one; signing in by username showed a shortened form of the account's address; and adding a second address to your account said whether it was already taken. Inviting somebody to a document, a folder or a Business organisation by username also showed the inviter that person's email address, and a signed-in reader with no display name commented on a public page under their email address. All of it now works the same whatever is behind an address: a calendar you are invited to appears the next time you open Calendar, a document or folder invitation shows only the address or username that was typed until the person opens or accepts it, and an invitation by username shows the username. On the same date we removed the addresses that invitations by username had left on Business invitations and in the organisation's activity log; a log line whose invitation had already been deleted cannot be matched to it and may still hold the address. The same contact rows also stored a copy of the full name on the linked account, written whenever somebody shared with it; from September 26, 2026 a contact only holds a name its owner typed, and copies that still matched the account's current name were removed (a name typed to match exactly is removed with them, and a copy taken before a rename cannot be recognised and remains until the owner edits or deletes the contact). Opening a contact page for an address you have never saved no longer shows anything about an account behind that address: not its name, not its username, not its photo. If you would rather not be in somebody's contacts at all, they can delete the contact, and deleting your account removes it everywhere. Connections. Your contacts are your own address book and ask nothing of the people in them. A connection is mutual: one account asks, the other accepts. We store which account asked which, whether the request was accepted or declined, and when. A declined request is not reported to the person who asked: they keep seeing it as sent, and cannot send it again. Being connected, or working together in a workspace or the same Business organisation, is what lets somebody see your full name in their contacts, their share suggestions and the username lookup, and see your presence ring (Section 3.20); anybody else who addresses you by username sees that username and your profile photo. Somebody you share with is listed under Recently shared with rather than among the contacts you saved, until you save or connect with them. Your name is still shown where you put it in front of somebody yourself, such as the sender line on a link you send them or your edits in a document you share. A connection is kept until either of you removes it or deletes their account, and is included in your data export. Where you sent the same person several links, we can show you their activity gathered on one page, grouped by the email address you sent to. That page contains nothing we did not already record per link, only you can see it, and it empties link by link as those links are deleted or expire.
- Mentions: a document can mention another document, a file, or a person. Mentioning a person stores their name and email address as part of the document, where everyone who can read the document can see it, and the mention is listed on the mentioned file's details and, for a person, on your contact page for them.
- Embedded data: a document, canvas, or form can show values from one of your spreadsheets, and a spreadsheet tab can be connected to another part of Nemi and filled with rows from it. Whatever is embedded or copied in this way becomes part of that document or spreadsheet and is visible to everyone who can see it, which can be more people than could see the original.
- A correction. Until September 23, 2026 this item said that embedding was always started by a person who could already read the source, and that it was their choice, the same as pasting. That was not true for a spreadsheet tab connected to a calendar or to share link statistics: such a tab refreshed by itself whenever any member who could edit the spreadsheet opened it, and it then put that member's own calendar or share link statistics into the shared sheet without them choosing to. It no longer works that way, as the next points set out.
- What a connected tab can hold from the workspace. Form responses; the files of a folder (name, type, size, upload date, number of downloads and a link to the folder, plus the folder path when subfolders are included); Gallery photos (name, date taken, camera, dimensions, size and whether it is a favourite); and the cells of another spreadsheet, copied as values.
- What it can hold from the account of the person who connected it. Their calendar events; statistics of their share links; their rooms (name, status, dates, and the number of files, requests, open requests, messages, opens and distinct viewers, and when a room was last opened); the request list of one of their rooms (each request, its details, its kind, whether and when it was done, the name a guest typed when they delivered it, and the name of the delivered file); and their upload links (name, folder name, status, number of uploads, bytes received, when it was created, when it expires and the last upload).
- Only you copy your own data. A tab connected to your calendar, share links, rooms, room requests or upload links is only ever filled when you, the person who connected it, press Refresh, including the first fill when you connect it. It is never refreshed in the background, on a timer, or as another member. Your own data is not limited to the workspace the spreadsheet is in: rooms and upload links you made anywhere, including the names of folders in another workspace, land in the spreadsheet you connect them to.
- Automatic refresh. A tab connected to form responses, a folder, Gallery or another spreadsheet can be set to refresh every 5, 15 or 60 minutes, and refreshes once when it is opened. That happens only in the browser of somebody who can edit the spreadsheet, while they have it open in a tab they are looking at. We run no scheduled refresh on our servers.
- The workspace fence. Form responses, folders, photo libraries and other spreadsheets can only be connected to a spreadsheet in the same workspace, a spreadsheet cannot be connected to itself, and every refresh is checked against what the person refreshing may read. Nothing in a Vault folder is ever copied into a connected tab, not even the encrypted placeholder entries.
- Preview and plain text. While a tab is being connected, a preview of the first rows is shown to the person connecting it and nobody else, and nothing is stored or copied until they press Connect. A copied value that starts with "=" is stored as text and never runs as a formula.
3.3a Business organizations
On the Business plan you can create or join a company organization. For that organization we process:
- Organization name, optional logo, seat limits, and membership roles (owner, admin, member).
- Invites sent by email or username, and acceptance or decline of those invites.
- Linked membership so storage and plan entitlements can be pooled for the organization while membership is active.
- Display of the organization name and logo next to verified badges for members, on profiles and share pages where applicable.
Organization owners and admins manage seats and members. When you leave or are removed, organization-linked entitlements end for your account.
3.4 Technical Data
- IP address (for security, rate limiting, and abuse prevention).
- Browser type and version, and device information.
- The approximate location of each device you are signed in on, shown to you alone in your sessions list so you can recognise a device that is not yours: a city, a region and a country. It is worked out from the device's IP address in a location database that sits on our own servers (DB-IP's free database, which we download; DB-IP never sees a lookup), so the address is not sent to anybody to find out where it is. This corrects how the sessions list worked until October 4, 2026, which this section did not mention: we sent the IP address to ipapi.co, a location service outside the EU, to look it up, and the Nemi web app asked two outside services, ipify and Cloudflare, what the browser's own address was. All three have stopped, and none of them receives anything from us now.
- Cookies and similar technologies (see Section 8).
3.5 Communication Data
- Email address for transactional and marketing emails.
- Email interaction data (opens, clicks) for improving our communications.
- Your email preferences and unsubscribe choices.
3.6 Data About Recipients & Visitors (No Account Needed)
If you interact with the Service without an account, we process a limited amount of data about you:
- When you download a shared file: the download timestamp, and a salted, truncated hash of your IP address. The sender sees download counts and timestamps as analytics. If the sender switched on Trace, more is recorded and Section 3.10 sets it out in full.
- When you open or preview a shared file: an open event with a salted, truncated hash of your IP address (we do not store your raw IP address for open analytics) and the timestamp. The sender sees these as counts and timestamps, and is notified in the app the first time each of their links is opened. That notification says only that the link was opened, never who by: identifying a visitor is what Trace does, and Trace is a separate thing the sender has to switch on (Section 3.10).
- A correction about those hashes. Until August 9, 2026 the salt behind them had a fallback value written into our own source code. An IP address is a small enough range of possibilities that a known salt makes the hash reversible by trying them all, so anyone who held our source could turn those stored hashes back into the addresses they came from. That means they were pseudonymous in name only, and earlier versions of this policy described them as if they were not. This is the correction. The fallback is gone: the salt is now configuration that is never published, and on a deployment where it is not configured we record the open and store nothing that points at a viewer at all, rather than an identifier we cannot stand behind. Hashes written before this change stay in the records that hold them until those records are deleted on their normal schedule.
- When you ask the sender to resend an expired link: a salted, truncated hash of your IP address, under the same salt and the same correction described above, and nothing at all in its place where that salt is not configured; the note you write, if you write one; and an email address only where there is one to record, meaning the address on your own account if you were signed in to Nemi, or one supplied with the request. Your raw IP address is not stored. The sender is told that somebody asked them to resend that link and is shown your note; they are not shown an address, and the line deliberately does not name you, because nobody proves who they are on a public page. The hash is there so that pressing the button twice counts as one request rather than two, not so that you can be recognized, and it is specific to that one link. One request per visitor per link is kept, it is marked as answered when the sender restores the link, and it is deleted with the link.
- When you upload files through an upload link or a Beam drop box: the files themselves and technical data about the upload. These files belong to the workspace of the Nemi user who requested them. A direct Beam works differently and is described in Section 3.11.
- When you fill in a Nemi form: the answers you submit, which are delivered to the Nemi user who created the form.
- When you comment on or approve a review round: the name you type, an email address if you give one, what you write, and where in the file you pinned it. All of it is visible to the Nemi user who sent you the link, which is the point of it.
- When you join a meeting from a link: the name you type, the times you joined and left, and anything you write in the meeting chat. What you say and show in the meeting itself is encrypted between the participants, and no server of ours can see or hear it (Section 3.9).
3.7 Connected Calendar Accounts (Optional)
Nemi Calendar can connect to an external calendar so your events appear alongside the ones you create in Nemi. Connecting an account is always your choice, it never happens automatically, and you can disconnect at any time in your calendar settings. We support:
- Google Calendar. We request only two permissions: the read-only list of your calendars, and read and write access to the events in the calendars you enable. We do not request access to Gmail, Google Drive, Google Photos, your contacts, or any other Google service, and we cannot read them.
- Microsoft Outlook Calendar. Your profile name and email, and read and write access to your calendar events.
- ICS feeds. The events published by a calendar URL you give us. These are read-only.
- Spotify (optional). Read-only listening history, shown as entries on your timeline. Nothing is written back to Spotify.
For a connected account we store the calendar list, the event data needed to display and sync your calendar (title, description, location, times, recurrence, attendees, and the provider's event identifiers), and the access and refresh tokens for the connection. Tokens are encrypted with AES-GCM before they are written to our database, so a database dump alone cannot read your calendar.
Calendars are bound to your personal account rather than to a workspace, so connecting a calendar does not expose it to the other members of a workspace you belong to. Sync is two-way: changes you make in Nemi are sent back to the connected provider, and changes made in the provider are pulled into Nemi. When you disconnect an account or delete your Nemi account, the stored tokens, calendars, and events for that connection are deleted.
3.8 Photos in Nemi Gallery
Photographs can carry more about you than the picture itself. Nemi Gallery is built around that fact, so this section sets out exactly what happens to a photo you add.
- Compression happens on your device. In most browsers your photo is converted to AVIF locally and only the converted, smaller file is uploaded. The original never leaves your device. If your browser cannot do the conversion (some browsers cannot, and most cannot read iPhone HEIC photos), the original is sent to our server, converted there, and the uploaded original is discarded immediately afterwards. It is never stored.
- The original is not kept. We store the converted photo and a small thumbnail. This is deliberate and irreversible; see Section 4a of our Terms.
- Camera metadata is read out of the photo and stored separately. Converting a photo discards what the camera wrote into it, so before that happens we read: the capture date and time, the camera make and model, the lens, the exposure settings (shutter, aperture, ISO, focal length), the orientation, and, if your camera recorded them, the location coordinates and the altitude. These are stored as data in your library so the app can sort your photos by when they were taken and show you their details.
- You can drop the location before it is uploaded. Gallery has a setting that removes the coordinates and the altitude on your device, before anything is sent to us. When it is on, we never receive the location of new photos at all. It applies to photos added afterwards; it does not change photos already in your library.
- A library belongs to a workspace, and everyone in that workspace can see it. If you are in a shared workspace, the other members see the same grid, the same albums and the same trash, and they can add to it. Your name is on the photos you uploaded. If you want a library only you can see, keep it in a workspace with no other members. A previous version of this policy said Gallery was bound to your account alone; that stopped being true when Gallery moved to workspaces, and this is the correction.
- Photos can be moved or copied to another of your workspaces. A member of two workspaces can send photos from one library to the other, within limits that follow from who is allowed to erase a photo. Moving one takes it out of the first library, so the people there stop seeing it, and because that changes who can erase it for good, you can only move the photos you uploaded yourself, unless you own the library, in which case you can move any of them. Copying leaves the original where it is and is open to anyone who can see the photo. Either way you need permission to add to the destination, so a member who is there in a view-only role cannot. A moved photo keeps its uploader, so it is still your photo and still billed to you; a copy has you as its uploader. Either way the photo arrives with everything stored about it: the capture time, the camera details and the location, if it still carries one. Photos in the trash cannot be moved or copied.
- A photo can be embedded into a document. Any member who can see the library can place a photo into a document, spreadsheet, canvas, or form. From that moment the photo is visible to whoever can see that document, which can be more people than the workspace: a published page or a share link shows it too. The embed is a reference rather than a copy, so it uses no extra storage, and erasing the photo for good removes it from every document that embedded it at the same time.
- We do not run facial recognition and we do not identify or name people. We also do not use your photos to train models (Section 5), and no photo of yours is ever sent anywhere to be analyzed. Searching by what is in a picture works differently from how people usually assume, and Section 3.8a explains exactly how.
- Deletion. A deleted photo sits in the Gallery trash for 30 days and is then permanently removed, along with its metadata. Any member of the workspace can move a photo to the trash and any member can bring it back; permanently erasing one is limited to the person who uploaded it and the workspace owner.
- What happens to a shared library when you leave. Deleting your account deletes the photos YOU uploaded, wherever they are, including out of a workspace you shared with colleagues, where they will simply stop being there. Photos other members uploaded into your workspace are theirs and do not go with your account. If a shared library matters to your team, that is worth knowing before somebody closes their account.
Photographs of identifiable people are personal data about those people, and a photograph can also reveal things that count as a special category of personal data under Article 9 GDPR. You decide what you upload, so Section 5a applies to Gallery as it does to the rest of the Service: we do not profile you on what your photos contain, and Gallery is not the place for photographs that carry medical or comparably sensitive information.
3.8a Searching your photos by what is in them
Gallery can find the picture of a cat when you type "cat", without anybody having tagged it. That normally means a company is running your photos through its own image recognition. We are not, and because the difference is the entire point, here is the actual mechanism.
- Your photos are uploaded and kept. That is the library, and it is not what this section is about. Section 3.8 describes what we store: the converted photo and a thumbnail, never your original file. This section is about the one extra thing that searching by content would normally require, which is a company running your photographs through image recognition. That is the part that does not happen here.
- The reading happens on your device and nowhere else. When a photo is added, your browser runs a small model over it, on your own machine, at the same moment it is already compressing it. Your photo is stored by us, but it is never sent anywhere to be analyzed, never handed to a third party for that purpose, and never read by our servers. We could not do it on our side if we wanted to: it is your device that does the work, and it is the only thing that ever looks at the picture.
- What the reading produces is a list of numbers. The model turns the picture into roughly five hundred numbers, about half a kilobyte, and those numbers are the only thing that reaches us because of it. They are not a description, not a list of tags, and not something a person can read. The photo cannot be reconstructed from them. An earlier version of this section said "what we store is a list of numbers", which was about the search and could be read as a claim that we do not store your photographs. We do, exactly as Section 3.8 sets out, and this is the correction.
- In Gallery's search field, your search never reaches us either. When you type "cat", your device turns those words into the same kind of numbers, and only those numbers are sent. We compare them against the numbers we hold and send back the photos that match. So we do not learn the picture and we do not learn what you were looking for.
- Searching from the Nemi AI attachment picker works differently, and this corrects an earlier version of this section. When you look for a photo to attach to a message in Nemi AI, what a photo looks like is still matched with numbers your device makes from your words, exactly as above. The picker also sends the words you typed to our servers, where they are compared with the file names, camera makes and models, and lens names we already hold for the photos in that workspace's library. A year, or a month next to its year, is taken out of the words first and sent as a range of dates instead. This is a text lookup over those details and nothing else: no picture is analyzed for it. The picker sends the words in the body of the request rather than in a web address, and we use them only to answer that search and do not save them. An earlier version of this section said your search never reached us, but the picker already sent your words, in the web address of the request, to match file names, and that was not disclosed. A tab opened before this change can still send them that way until it is reloaded, and a web address can appear in the server logs described in Section 7.
- What that list of numbers can still do, honestly. It is a representation of what is in the picture, so it is a content index and we are not going to call it anything softer. Somebody holding it could test a guess against it, in the same way your search does, and learn that a photo probably contains a cat, without ever seeing the photo. It cannot produce a name, a face, or an identity, and we do not use it for anything except answering your own searches.
- It is per workspace, like the rest of Gallery. A search covers the library of the workspace you are in, which the other members can search too.
- Deletion. The numbers are deleted with the photo. Deleting a photo, or your account, removes them at the same moment and by the same mechanism.
3.8b Showing a library on a screen
Gallery can put a library on a television or a spare monitor as a slideshow. The screen has no Nemi account on it, which is unusual enough to be worth setting out in full: it is the one place in the Service where photographs are shown on a device that never signed in.
- The screen is added by you, not by itself. The screen displays a six character code and you enter that code in Gallery. Until somebody who is signed in does that, the screen has no workspace behind it and shows no photographs at all. The screen also holds a second value that is never displayed, and both are needed to start it, so somebody who photographs the code cannot use it.
- What the screen can see is only photographs. It receives the photo and, if you switch it on, a caption that is the date the photo was taken or the album name. It never receives the camera details, the location, the file name, who uploaded a photo, comments, reactions, the names of the people in your workspace, or anything in the trash. It cannot download a photo, cannot browse your albums and cannot reach anything else in your account.
- A screen is not a viewer. It does not appear as a person in the library, and nobody in your workspace is shown as looking at a photo because a screen is showing it.
- What we store about a screen. The name you gave it, what you told it to show, when it was added and by whom, and the last time it checked in. That is all. We do not record where the screen is, what it is, who walks past it or how long anybody looked at it, and there is no history of what it displayed: the last check-in time is overwritten rather than added to.
- A code that nobody uses. A code stays valid for ten minutes and is then deleted automatically. It is stored with the hash of the screen's second value rather than the value itself.
- Anybody in the room can see the photos. This follows from the feature rather than from anything we do, and it is the thing worth thinking about before you set one up. Put a screen where you are content for the library to be seen.
- Ending a screen. Press End next to it in Gallery. It stops immediately: the permission it holds and the connection it is using are both cut at that moment, and it drops out of the list. The record of it (the name, what it showed, when it was added and when it last checked in) stays with us, marked as ended, until you delete your account.
3.9 Meetings in Nemi Meet
Nemi Meet connects the people in a meeting directly to one another. What that means for your privacy is unusually good in one respect and worth understanding in another, so both are set out here.
- No server of ours can see or hear what is said or shown. Audio, video and shared screens travel from each participant's browser to the other participants' browsers, encrypted between the participants. On most networks they go directly. On a network that will not allow a direct connection they pass through a relay we operate, described below, which forwards the encrypted stream without being able to read it. Either way we cannot listen to a meeting, watch one, or make a recording of one from our side, and there is no setting that would let us. This corrects an earlier version of this section, which said the media never passed through our servers at all. That was not true on the networks where the relay is used: there the encrypted stream does pass through a server we run, although nothing on it can be read and nothing is kept.
- A participant can record, on their own device. Whoever presses record has their browser paint the call as they are receiving it and mix the audio they are hearing, and the resulting video file is uploaded to their own Nemi files, where it counts against their storage and where they can share or delete it like anything else. So a recording of a meeting you attended can exist, and it can exist without your agreement: it is made by another participant, not by us, and we hold the finished file the same way we hold any file that person uploads. Everyone in the meeting is shown that recording is in progress, but that indicator is an announcement by the recorder's browser and not something we can verify or enforce. Recording stops when that person's tab closes, and guests without an account are never offered it. If you would rather not be recorded, the moment to say so is in the meeting.
- Participants can see each other's IP addresses. This is how a direct connection is made: to reach each other, the browsers in a meeting exchange the network addresses they can be reached on, and those addresses are visible to the other participants. It is a property of the technology, not a choice we made, and it is the trade for keeping the media out of our hands. If you do not want to reveal your address to the other people in a meeting, do not join it.
- When a direct connection is impossible, a relay forwards the encrypted stream. On some networks, typically corporate ones, browsers cannot reach each other directly. A relay server we operate then forwards the traffic. It forwards only: the encryption is between the participants, so the relay passes packets it cannot read, and it stores nothing.
- What we do process. The meeting's name and join code; who joined it, under what name, with which account if any, and when they joined and left; and the technical messages that let the browsers find each other. Chat messages are stored, so that someone who joins late can read what was shared. Reactions, raised hands and who is muted exist only while the meeting is running and are never written down.
- Live captions send the meeting's audio to a transcription service, and that is the one place a meeting does. Captions are off unless the host of the meeting switches them on, and only the host can. When they do, the host's browser mixes the microphone audio of everybody in the meeting into one stream and sends it, live, to Soniox, a speech service, in its European Union region. Soniox is named in Section 6.1 and in Annex 3 of our Data Processing Agreement. The audio does not pass through our servers on its way there and we never hold it: it goes from the host's browser to Soniox, and what comes back is text. So while captions are on, what is said in the meeting is heard by a company other than the participants, and that includes what a guest says, and it includes anything said before somebody noticed the indicator. That is why the switch is the host's and why every participant, guests included, is shown a "Captions on" marker in the meeting for as long as they are running. The text does travel through our servers, because it is the same channel that carries the chat; we pass each line to the other participants and store none of it. When the host leaves, the finished sentences are written into the meeting notes described below, which are an ordinary document belonging to the host and outlive the meeting. The transcription separates the voices it hears and we match each voice to a participant by who was speaking at the time, so the transcript carries names. That matching is done in the host's browser and the record it is based on is never sent anywhere; what is sent is the name it arrived at, on each line, along with the line. Captions use the host's monthly voice minutes, the same allowance as dictation (Section 3.9a), so we record how many seconds of voice the host's account has used in the current month and how many of them were captions; those are numbers of seconds and nothing else.
- The whiteboard and the meeting notes. These are ordinary Nemi documents, not something Meet keeps of its own. They belong to the host, they are stored in the host's workspace and they outlive the meeting. Opening the whiteboard gives everyone in the meeting, guests included, a link that lets them draw on that document, so anything you put on the board is visible to the other participants and stays with the host afterwards. The host can revoke that link from the board itself at any time.
- A file shared in a call is an ordinary share link. When a participant sends a file into the chat, a normal Nemi share link is created for it in that person's account, and everyone in the meeting, guests included, is shown a card that opens it. The link stops working after 24 hours, the call keeps its last 20 shared files for people who join late, and until it expires the link works for anyone who has it, like any share link. Sending a file this way needs a signed-in account; guests can receive but not send.
- A meeting can be attached to a calendar event. When a host creates the meeting from an event in Nemi Calendar, the join link is written onto that event, which also carries it to a connected Google or Outlook calendar like any other change to the event. Afterwards the event shows the host their meeting notes and, if the host recorded, their recording. Those links are visible to the host only; the notes and the recording themselves are ordinary documents and files and are shared, or not, like any other.
- Guests. You can join a meeting from a link without a Nemi account. We then process the name you type, the fact that you attended, and anything you write in the chat. We do not create an account for you.
- Deletion. Deleting a meeting deletes its chat and its attendance record and stops the link working. Deleting your account deletes the meetings you created.
A meeting link is the key to the meeting, in the same way a share link is the key to a file: anyone who has it can join, subject to the password, waiting room and lock that the host can switch on. Treat it accordingly.
A change, stated rather than made quietly, September 16, 2026. Until this date, live captions worked in a completely different way, and everything this page said about them was true of that way: each participant switched captions on for themselves, their own browser transcribed their own microphone, and no audio ever reached us or any company we chose. That feature has been removed and replaced by the one described above, which transcribes the whole meeting through a service we chose. We are stating it rather than editing the paragraph and moving on, because the change is in the direction that matters: a part of Nemi that sent nothing now sends the audio of a conversation to a third party, on one person's decision, for everybody in the room. What has not changed is the rest of a meeting: the audio, video and screens of the call itself still travel between participants, encrypted, and no server of ours can see or hear them.
Correction, August 22, 2026. Until this date, this section described what a meeting transmits and stored without mentioning live captions at all, which was an omission rather than a false statement, but a reader could have finished it believing that nothing said in a meeting reaches us in any form. Captions have always worked as described above: no audio reaches us, the transcribed text passes through our servers unstored, and it is written into the host's meeting notes at the end. The same note added on August 22 first said the audio never left the speaker's device at all, which was our error and is corrected in the text above: whether it does depends on whether the speaker's browser transcribes on the machine or through its vendor's service, and only the second of those is under nobody's control but the browser's.
Correction, August 10, 2026. Until this date, this section and the retention table in Section 7 stated that Nemi Meet had no recording feature and that a meeting was never recorded. That was wrong. Device-side recording exists, and a recording made that way is stored in the recorder's workspace. Nothing about how meetings are transmitted has changed: the media still travels directly between browsers and we still cannot record from our side. What was inaccurate was the claim that no recording could be made at all. The text above now describes what the product does.
3.9a Dictation
Where your plan includes voice minutes, a microphone button appears in Nemi AI, in documents and in fields where you write something long, such as a description, a note or a message. Pressing it lets you speak instead of type. It is the second place in Nemi where audio leaves a device, after live captions in Section 3.9, and it works in the same way:
- Your microphone audio is sent to Soniox while you dictate, and only then. Your browser asks for the microphone when you press the button. From the moment it is granted until you stop, your browser sends what your microphone hears, live, to Soniox, a speech service, in its European Union region, the same provider and region as captions. Soniox is named in Section 6.1 and in Annex 3 of our Data Processing Agreement. The audio does not pass through our servers and we never hold it. The microphone is yours, so anything else it picks up in the room while dictation runs is sent too. Dictation stops when you press stop or Escape, when you leave the page, and on its own after a minute in which no words were heard.
- The text comes back to your browser and nowhere else. The words are written into the field or the document you are dictating into, where you can read and change them. We do not receive or store the text separately: it becomes part of whatever you then save, send or ask, and from that point it is processed exactly as typed text would be (a document is a document, a message to Nemi AI is a message to Nemi AI under Section 3.18). Nothing dictated is sent anywhere on its own; you still press send.
- Your browser's language preference is sent as a hint. So that a person dictating in German is not transcribed as if they spoke Dutch, the languages your browser prefers are sent along with the request, reduced to two letter codes such as "de" or "nl".
- What we record. Dictation is metered against a monthly allowance of voice minutes that belongs to your account, whichever workspace you are in, and is shared with live captions in meetings you host. We record how many seconds of voice your account has used in the current month and how many of them were dictation. That is a count of seconds and nothing else: no audio, no text, no record of where you dictated or when.
3.10 Trace: what a sender can see about a link you opened
A sender can switch on Trace for a share link. It is off unless they choose it, and it changes what is recorded about the people who open that link, so it is set out here in full rather than summarized.
- What is recorded about your visit. A salted, truncated hash of your IP address, under the same salt and the same correction described in Section 3.6, and nothing at all in its place where that salt is not configured; the country and city that address resolves to, looked up in a location database on our own servers so the address is not sent anywhere to be placed (until October 4, 2026 no country or city was in fact recorded, although this sentence said so, because the lookup depended on information our servers never received); whether you are on a desktop, a phone or a tablet; your browser and operating system; the page that referred you; and, if the sender typed your email address for that link (on its list of allowed addresses, or as the address they sent it to), that address. Your raw IP address is not stored. This corrects how Trace behaved until October 3, 2026: this sentence said your address was recorded only if you reached the link through an invitation addressed to you, but in practice the address of any signed-in Nemi user who opened a traced link was recorded and shown to the sender, including on links posted publicly and on links sent to an @username, whose address the sender was never meant to learn. That has stopped, and the addresses collected that way have been deleted from the visits they were attached to.
- How long you spent, and where. While the file is open and in the front of your screen, your browser reports how long you spend on each page of a document, each slide, or each ten seconds of audio or video. The sender sees that as a reading time and as a picture of which parts held your attention. Time when the tab is behind another window, minimized, or on a locked phone is not counted.
- It is an estimate and it is labelled as one. Reading time is measured by your own browser and reported to us, so it can be incomplete or wrong. The sender is shown it as an estimate. Opens and downloads are recorded by our server and are exact.
- Downloads carry a code. Every download of a traced link is given a short code that identifies that download, so a sender can tell which copy of a file a leak came from. Where the link is also watermarked, that code is baked into the image you receive.
- Repeat visits are grouped. A hashed key ties your visits to the same link together, so a sender can see one viewer who came back three times rather than three viewers. That key is specific to that one link: it cannot be used to recognize you on a different link, on a different sender's link, or anywhere else in the Service.
- The sender decides, and the sender is responsible. Trace exists because the sender wants to know whether their document was read. We provide the tool; the sender chooses to point it at you. In most cases that makes them the party responsible for telling you, and our Terms require them to. Only the sender of that link can see its trace. We do not use it for anything of our own.
- A sender can see one person's opens across their own links. Where a sender addressed several links to the same email address, we can show them that address's opens and downloads gathered on one page. The grouping is by the address the sender themselves typed, never by the per-link key above, which still cannot recognize you across links, and it never includes visits by people who did not identify themselves. It shows the sender nothing that was not already visible to them link by link.
- Deletion. Trace data is deleted together with the link it belongs to, and immediately when the sender revokes the link.
3.11 Direct transfers in Nemi Beam
A direct Beam sends a file from one browser to another without it ever reaching us. That is unusually good for your privacy in one way and has one consequence worth knowing, so both are here.
- We never receive the file. The bytes travel from the sending device straight to the receiving device, encrypted. We are not in the middle, we do not store a copy, and there is nothing on our servers to hand over, scan or recover afterwards. What we do process is the short code that introduces the two devices to each other and the technical messages that let them find each other, none of which contain the file.
- The two devices can see each other's IP addresses. This is the same trade Nemi Meet makes and for the same reason: to reach each other directly, the two browsers exchange the network addresses they can be reached on. If you do not want to reveal your address to the person on the other end, use a share link instead, which goes through our servers.
- When a direct connection is impossible, a relay forwards the encrypted stream. On some networks the two browsers cannot reach each other. A relay we operate then passes the traffic along without being able to read it, and stores nothing.
- Nothing survives the transfer. Both devices must be open at the same time, and when the tab closes the transfer is over. There is no copy to come back for, and neither we nor the sender can recover it.
- A Beam drop box is different. The permanent drop box at your Beam address does go through our servers, because it holds files for you while you are not there. Those files are stored like any other upload and Section 3.3 applies to them.
3.12 Vault folders
A vault is a folder that is encrypted on your own device before anything is uploaded. It exists so that there is a place in Nemi whose contents we are not able to read, and the honest description of it includes what it does not protect.
- We cannot read what is in it. The key is generated in your browser and unlocked there by your passkey or your passphrase. It never reaches us in a usable form. We hold the encrypted file and an encrypted copy of its real name, and we are not able to decrypt either, with database access, with storage access, or with both. That also means we cannot produce the contents in response to a legal request, however the request is worded.
- What is still visible to us. That the folder exists, how many files are in it, how large each one is, when it was created or changed, and who the members are. Encryption hides the contents, not the fact of them.
- Features that read files do not work in a vault. Previews we generate, thumbnails, conversion, compression and malware scanning all require reading the file, so none of them run on a vault file. Previews that your own browser can render happen on your device.
- Access is granted by a device, not by us. Adding someone to a vault happens in an existing member's browser, which re-encrypts the key to the new member. We route the result and learn nothing from it, and there is no way for us to add ourselves.
- Losing your key means losing the files. If you lose your passkey or forget your passphrase and you no longer have your recovery code, the files cannot be recovered. Not by you, and not by us. This is the direct consequence of the guarantee above and there is no support process that can undo it. Section 4d of our Terms says the same.
- Removing a member is not a wipe. It stops them reading anything from that point on. Somebody who already opened the vault has already seen what was in it, and no software can reach back and unsee that.
3.13 Pages hosted on an embed link
An embed link serves a file at a URL any website can point at. Where that file is a web page, the page is served as a page: its HTML, its stylesheets and its JavaScript run in the browser of whoever opens it. This section is for the person opening such a page, because what happens on it is not written by us.
- The page is somebody else's code, running in your browser. It was written by the Nemi customer who published the link, not by Nemi. It can do what any web page can do, including asking other websites for things, which tells those websites your IP address and that you loaded this page. We do not review or approve what is in it.
- We do not see what happens inside it. Our record is the same one we keep for any embed: that the link was opened, and when. What the page then does in your browser does not reach us.
- The page cannot reach your Nemi account. It is served in a sandbox that puts it in its own isolated origin, so it cannot read your Nemi session, your cookies or anything stored in your browser by Nemi, and it cannot act as you. That is a deliberate limit on the feature and not something the page's author can switch off.
- It cannot store anything in your browser either. Cookies and local storage are unavailable to it, which is a side effect of the same sandbox: a hosted page has no way to remember you between visits.
3.14 Links sent from a customer's own domain
On Creator and higher, a workspace can connect a domain it owns, so the links it sends look like share.theircompany.com instead of nemilab.com. The pages behind those links are still ours and still work exactly as this policy describes. Two things are worth stating plainly.
- What we store about the domain. The hostname, a random verification string, when it was checked and whether it is working, plus which workspace and which person connected it. Checking it means asking the public DNS system for two records on that hostname. Nothing about the people who later open the links is stored because of this.
- Who issues the certificate. To serve the link over HTTPS, a certificate has to exist for that hostname. We obtain it from Let's Encrypt, run by ISRG, and the only thing they receive is the hostname itself. Hostnames in public certificates are published in Certificate Transparency logs, which is how the certificate system works for every site on the web and is outside anyone's control; a domain a customer connects is therefore a public fact.
- For the person opening such a link. Your browser connects to a hostname the sender chose, but the service answering it is Nemi. What is recorded about your visit is the same as for any other link and is set out in Sections 3.6 and 3.10. The sender does not learn anything extra about you because they used their own domain.
- Signing in never happens on such a domain. Only public links are served there. The app, and every screen that asks you for anything, stays on nemilab.com, so a page on a customer's domain can never be a Nemi sign-in prompt.
3.15 Your folio, a page you publish
A folio is a public page about you: your name, a headline, a description, where you are, the work you want to show, links to other places, and an address people can write to. It belongs to your account rather than to a workspace, there is one per account, and it is not published until you publish it. Everything on it is something you typed or uploaded on purpose, which is what makes this section shorter than the ones above it.
- Who can see it. Nobody, until you press Publish. After that, anyone with the address can open it, and so can anyone that address is forwarded to. Before you publish, the page and the pictures on it answer to you and to nobody else.
- What is published is what you last published. The editor saves as you type, so nothing you write is at risk, but those edits are a draft that only you can see. Visitors keep getting the version you last pressed Publish on, and a copy of that version is what we store to serve them. Until 20 September 2026 there was no draft: every keystroke was immediately the public page.
- Taking the page down is immediate and is not a draft. Pressing Take offline stops the page, its project pages and its pictures answering at once, without waiting for anything to be published.
- Search engines are a separate decision. A published folio asks search engines not to list it, and stays out of our sitemap, until you switch that on yourself. We never turn it on for you, and publishing does not imply it. Once a page has been listed, switching it back off stops us serving the page but does not empty a search engine's own copy of it.
- What we record about your visitors: almost nothing. We count how many times a folio was opened, as a single number the owner can see. No visitor address, no location, no device, no referrer, no per visit row. This is deliberately unlike the analytics on a share link (Sections 3.6 and 3.10): a portfolio is not a delivery and does not need to know who read it.
- The pictures and videos. They are stored like any other file you upload, under Section 3.3, and count towards your storage. A photo you pull in from Gallery is not copied: your folio points at the photo already in your library, and erasing it there removes it from the page too.
- Fonts. A folio can be set in any font from the Google Fonts library. We fetch that font from Google on our own server and serve it to the visitor ourselves, so the visitor's browser never contacts Google and Google does not receive the visitor's IP address. Until October 4, 2026 the visitor's browser fetched the font from Google directly, and this section said so.
- On your own domain. If your workspace has a connected domain (Section 3.14), your folio can be its home page. Which folio a domain may show is decided by us, not by the page: it is always the folio of the person who owns that workspace, and every other address on that hostname is sent back to nemilab.com.
- Turning it off. Unpublishing stops the page, its project pages and its pictures from answering, immediately. Nothing is deleted, and publishing again restores the same address. Deleting your account deletes the folio with it.
3.16 What a sender can put on the page you opened
The page behind a download link is laid out by the workspace the link came from, which may be the person who sent it or a colleague of theirs: which blocks are on it, what they say, and how the whole thing looks. One such page serves every link that workspace sends. This section is for the person opening such a link, because what is on it was not written by us.
- The words and the links are theirs. A sender can put text, a picture wall, their own contact details and buttons that lead to other websites on the page. We do not review any of it. Following one of those buttons takes you to somebody else's site, which then knows your IP address and that you came from this page, exactly as any link on the web does.
- What we record about your visit does not change. It is the same as for any other link and is set out in Sections 3.6 and 3.10: the page being opened, downloads and their timestamps, and a salted, truncated hash of your IP address. A page with more on it does not collect more.
- A box asking you to agree before downloading is the sender's, not ours. Where a sender asks for one, it appears when you press a download on that page, and the download starts once you tick it. It is not a contract with Nemi, we are not a party to whatever it refers to, and we do not record that you ticked it.
- Nothing on the page can read your Nemi account. A sender chooses from blocks we wrote; they cannot add code, scripts or trackers of their own. That is a limit of the feature rather than a setting, which is the difference between this and a page hosted on an embed link (Section 3.13).
3.17 Badges, streaks and the workspace score
Nemi keeps a record of things you do in it, so it can show you badges, a security streak, a health score for a workspace, and a look back over the year. This section says exactly what that record is, because it is the one part of the Service that exists to be shown back to you.
- What is recorded. One row per event, holding your account id, the workspace it happened in where there is one, what kind of thing it was, a number (a count, or a size in bytes), the time, and a short note. The note holds only what the badge needs: a file's name for an upload, a link's id for a share, the name of an action you took from the keyboard. It never holds a file's contents, a message, a password or anything a recipient typed.
- Running totals. Alongside the events we keep counters: files uploaded, links made, downloads received, conversions run, bytes saved, minutes in a meeting, actions your AI assistant took. These are numbers, not lists.
- The workspace score. Calculated when you open it, from things already in the Service: how many links are public with no password and no end date, whether anything failed a virus scan, who holds access they have not used, duplicate files, and whether the workspace owner's account has a passkey and a second address to recover with. Only the resulting number and the date are stored. It is visible to the members of that workspace and to nobody else. Two of its findings are about the workspace owner's account rather than about the workspace, so members are told that the owner's address is unverified or that their account has no passkey; the score shows nothing else about the owner. The owner is the person whose plan and whose account govern the workspace, and Section 6.2 covers what the members of a workspace see about them because of that.
- Keyboard coaching. If we notice you doing something with the mouse that has a keyboard shortcut, we count it so the Service can tell you the shortcut. What is stored is the name of the action, such as "new folder". We do not record keystrokes.
- You can turn it off. One switch in Settings stops the recording described above and hides badges, streaks, the score and every milestone message. The setup quests keep running, because they are worked out from your files, links and documents rather than from this record, and because they grant storage that is part of your plan.
- Nothing here is public unless you say so. A separate switch, off by default, puts your badges, how many you have and the month you joined on your profile card, your folio and a block you can add to your share page. Your score, your streak, your quests and anything naming a file or a link never appear on a public page at all.
- It is never used to decide anything about you. We do not use it for advertising, we do not sell it, we do not train models on it (Section 5), and it plays no part in support or moderation decisions. The one exception is described in the next point.
- The one thing it does decide. How long your account has existed, whether your address is verified, whether you have a passkey, how many files you have uploaded, whether you pay, and whether uploads of yours have been found to contain malware together set a "trust level" that widens the free plan's limits on links and invitations as an account establishes itself. It only ever widens them from the starting position, it is recalculated from those facts each time rather than stored, and it exists to make automated abuse expensive rather than to rank users.
3.18 Nemi AI, the assistant inside Nemi
On the Pro, Max and Business plans, Nemi includes an assistant you can ask to do things for you: find a file, write a document, make a link, look at a photo, write the words on your public page. It runs on a language model that we do not host ourselves, which means the parts of your data it needs to answer leave our servers. This section says exactly which parts, where they go, and what we keep. Nothing here happens unless you open the assistant and send it a message. Looking for a file or a photo to attach sends your search words to us, not to the model, before you send anything; Section 3.8a says how that works for photos.
- What is sent to the model. The message you typed, the rest of that conversation, and the results of the actions the assistant took for you. Those results contain your data: file and folder names, the text of a document, the cells of a spreadsheet, the questions and answers of a form, the title and time of an event, the details of a photo, and, if you ask it about your Folio, everything on that page: its headline, its about text, your location, the projects on it, the links you list and the contact address you publish there. If you ask it about your account or your settings, they contain those too: your email address, which plan you are on, how much storage you are using, and your appearance and accessibility preferences. If you ask it about a workspace, they contain the names and roles of the people in it, which is somebody else's data leaving on your instruction, so it sends names and roles and not their email addresses. A file you attach to a message is sent to Nemi and held for 24 hours on our EU storage, outside every workspace: it is scanned by the same scanner every upload goes through, it does not appear in your files, it counts toward nobody's storage, nobody else in a workspace can see it, and it is deleted after 24 hours unless you ask the assistant to save it, at which point it becomes an ordinary file in the workspace you name. Its size does count toward your own monthly upload volume, on your own plan and whichever workspace you have open, because storing it costs us the same as storing an upload however soon it is deleted; a file the assistant makes from it does not count. Deleting your account deletes these files at once. The 24 hours was not always true, and this version corrects it: until now, the attached files of an account deleted within those 24 hours, and a file whose deletion failed during the hourly clean-up, could stay in our storage with no record left pointing at them. They are now deleted with the account, a failed deletion is retried every hour, and the clean-up also removes anything held in that storage for longer than 30 hours, including files left behind before this change. The model is sent its name, type and size so the assistant can act on it, and our own conversion service receives the bytes only when you ask for it converted. Any image you attach, or ask it to look at, is re-encoded before it is sent, and scaled down if it is large, so the original is never sent and neither is its metadata: no location, no camera details. A correction: until October 3, 2026 a small picture that needed no scaling was passed on as it was, metadata included, although this section already said the original was never sent. Every picture is re-encoded now. Until this version this section said an attached picture never left your device; it now goes to Nemi for the length of the conversation, and we say so rather than change it quietly.
- What you have open, and what you have selected. So that "convert this" or "tidy up this paragraph" means something, a message carries what you were looking at when you sent it: the document, spreadsheet, canvas or form you have open, the folder the file browser is showing, the files you have ticked, the file open in the preview, and the photo you have open in Gallery. Your browser sends identifiers and nothing else. We look every one of them up against your own access before anything leaves, so a page cannot describe to the model a file you are not allowed to see, and an identifier that no longer resolves is dropped rather than guessed at. What reaches the model is therefore the title of the thing you have open and whether you may change it, and the name, type and size of the files you have selected or are previewing. We state this separately because it is a record of what you were doing at the moment you asked, which is information about you rather than about a file.
- What is never sent. Your password, your payment details, your session, and the contents of a Vault folder. The assistant reaches a Vault no more than a connected assistant does, which is not at all. It also cannot reach a connected calendar account, for the reason set out in Section 6.3. A file's contents are only sent when you ask the assistant to read that file: it does not read your storage on its own.
- Where it goes. To OpenRouter, through its gateway in the EU, which passes the request to Microsoft, which runs the model on Azure in the EU data zone. Both are named in Section 6.1 and in Annex 3 of our Data Processing Agreement, and no other company may serve you: the request pins Azure's EU zone and forbids the router from going elsewhere. At the EU gateway the request is decrypted inside the EU and may only be passed to hosts in the EU, so your message and the answer to it are processed in the EU from end to end, and OpenRouter does not log their content there. OpenRouter itself remains a United States company, which is why Section 6.1 still lists the safeguards for it. Until this version this point said the routing step ran outside the EU. It did, and it no longer does. Every request also requires zero data retention: the router may only pass it to an endpoint on its zero data retention list, so the host keeps nothing of your message or of the answer once it has replied, and a request that cannot be served that way fails rather than going elsewhere. Every request also forbids its use for training. Nothing you send to the assistant is used to train a model, by us, by OpenRouter or by Microsoft. We do not send your data to any AI provider except when you use this feature, and turning it off is as simple as not using it.
- What we keep, and where. Your conversations are stored in Nemi, on your own account: the messages, the actions taken and their results. They belong to you and to nobody else, not even to the other members of your workspace, and you can delete a conversation or all of them at any time. Deleting your account deletes them with it. We also keep one record per request holding the model used, the number of tokens, and what it cost, because the feature has a weekly spending limit that has to be counted and because it is how we detect abuse. That record holds no message text.
- It acts as you, with your permissions. The assistant can only do what you can do. Every action it takes is checked against your role in the workspace it touches, exactly as if you had done it yourself, and an action you are not allowed to take is refused. Changes it makes to a document or a spreadsheet are attributed to "Nemi AI" so your collaborators can see which lines it wrote. When you have that document open, its changes go into the same live editing session your own typing goes into, so they appear as it makes them and everybody else in the document sees them arrive exactly as they would see yours. A document you are only allowed to read is refused rather than changed, and it tells you why. Your Folio is the one thing it works on that belongs to your account rather than to a workspace, so it only ever reads and writes your own page and never a colleague's, and it cannot publish one: turning a draft into a page strangers can open stays a button you press.
- It can be wrong, and one press puts a turn back. A language model can misunderstand a request or state something untrue. It can create, change and delete things in your account, so read what it tells you it did. Our Terms of Service say more about this.
- What we store so that a change can be undone. When the assistant changes something, we write down what would put it back, at the moment it does it, so that one press under its answer can reverse the whole turn. That record holds the previous state of the thing that changed and nothing more of it: the name a file had before it was renamed, the folder it was in before it was moved, the identifier of the trash entry a delete created, the identifier of a file it made, and the previous values of exactly the spreadsheet cells it filled in. It is your own workspace data, it stays in Nemi on your own account, and nothing in it is ever sent to the model or to anybody else. It is deleted 30 days after the change, and deleting the conversation deletes it straight away. We also write down, in the same place, the changes we cannot reverse, so the count you are shown is honest about them; those entries hold a short description and no previous content. Undoing is available to you in Nemi and not to an assistant you connect from outside, which records none of this.
3.18a AI forms
On the plans that include Nemi AI, the person who creates a form can make it an AI form. The people filling it in then answer in a conversation: an interviewer run by the same language model as Section 3.18 asks the form's questions one at a time and, on open questions, may ask one or two short follow-up questions. This section is written for both sides: the person who made the form, and the person answering it.
- The person answering is told. The form says, at the top and at the bottom, that an AI interviewer asks the questions, and there is a switch to fill in the regular form instead. After that switch nothing more from that visit is sent to the model.
- What is sent to the model. The form's title, description and questions, the note its creator wrote about what they want to learn, the answers given so far in that conversation and, if the form asks for it, the name the person gave. For a question answered by attaching a file, only the fact that a file was attached is sent, never the file.
- Where it goes. The same route as the assistant, with the same limits: OpenRouter's gateway in the EU, and Microsoft's Azure in the EU data zone, with zero data retention by the host and no training on it (Section 3.18 and Section 6.1).
- What is kept. The answers are saved in the form's response sheet exactly as for any other form. Choices, ratings, dates, email addresses and files are saved exactly as the person picked or typed them. Typed answers (a name, and open questions) are filled in by the interviewer at the end of the conversation, from everything the person said, in the language of the form: one answer per question, including what they added in reply to a follow-up, translated when they wrote in another language, keeping what they said without adding to it. A reply that is not an answer, such as a question back about what a question means, is not saved at all. Unless the creator has switched it off, the interviewer also writes down, in an extra column called Additional notes, anything the person said that would be useful to the creator but answers none of the questions, in the language of the form; the person sees these notes on the review card before sending, and switching to the regular form sends none. Before sending, the person sees every answer as it will be saved and can switch to the regular form to change one. Until this version this point said the model never wrote or reworded an answer and that follow-ups were saved word for word; that is no longer how it works, and we say so rather than change it quietly. While the conversation runs, it is held in our server's memory so that each message can build on the ones before it, and so that the final answers are written from what was actually said rather than from anything a browser sends. It is never written to disk or to a database, it disappears after two hours without activity at the latest (or when our server restarts), and nothing of it is kept apart from the answers. Each request also leaves one usage record on the form creator's account (the model, the number of tokens and what it cost), which holds no answer text and nothing about who was answering.
- Who pays for it, and what happens when that runs out. The conversations use the Nemi AI allowance of the person who created the form, which is why only that person can make a form an AI form. The creator can limit how much of their weekly allowance one form may use and set a date after which it stops using AI. When that share is used up, the date has passed, the allowance is used up, or Nemi AI is not available on their plan, the form is filled in without the interviewer (one question at a time, or all on one page, as the creator chose), and the person answering is not told anything about the creator's plan or usage. Each usage record names the form it was for, so the share can be counted; it never names the person answering.
- A sign-in or a password before the conversation. The creator can ask for either or both before the interviewer starts. When a Nemi account is asked for, we check on each message that the person is signed in; we do not store who they are with the form, the answers or the usage record, and the creator does not learn it unless the form itself asks for a name. A password is stored only as a one-way hash, and entering it gives the browser a signed pass that expires after 12 hours and stops working when the creator changes the password. Neither applies to the regular form, which anyone with the link can still fill in.
- Writing a form with Nemi AI. When you ask Nemi AI to write the questions of a form, the description you type is sent to the model along the same route, using your own allowance.
3.19 Rooms, and what a guest leaves in one
A Room is a page one of our users hands to a client at a single unguessable link. There is no account behind it, so what we process about a visitor is what the visitor puts there, plus the one thing every link records. This section is written for both sides: the person who opened the room, and the person who owns it.
- The name you type. It is optional, it is not verified, and it is the whole of your identity in a room. It is shown to the room's owner next to anything you send: your uploads, the items on their list that you provided, and anything you write. It is also visible to anybody else holding the same link, because a room is one shared page rather than a private channel per visitor.
- Files you upload. They are stored like any other upload under Section 3.3, they belong to the room's owner and count against their storage, and they land in that person's workspace. Uploading is only possible where the owner has allowed it.
- What you write. A room can have a thread. What you write there is stored with the room, shown to the owner, and shown to everybody else holding the link. It is plain text, it cannot be edited or deleted by you afterwards, and it is deleted when the room is deleted. Do not put anything in it that should not be readable by everyone who has the link.
- What you provided. An owner can put a list of things they still need on the room. When you answer a line, we store that it was answered, when, the name you had typed, and the file you sent if it was answered with one. Removing that file from the room reopens the line and removes the link between the two.
- That you opened it. An open event, recorded at most once per visitor per ten minutes and kept for the life of the room, holding a salted, truncated hash of your IP address under the same salt and the same correction described in Section 3.6, and nothing at all in its place where that salt is not configured. Your raw IP address is not stored. The owner sees this as two numbers, how many opens and how many separate visitors, and as a line saying the room was opened. It never names you, it is not reversed, and a room deliberately records less about a visit than Trace does on a share link (Section 3.10): no location, no device, no browser, no referrer.
- A correction, stated rather than made quietly. Until this version this policy described what a Room holds only through the general rules on uploads and on visitors to a link. Rooms now also carry a thread and a list of requests, which means text you write and a record of what you provided are stored and shown to the owner. Both are new, and the four bullets above are the full statement of what that means.
3.20 Presence, and the ring around your profile photo
The circle drawn around your profile photo can show what you are doing in Nemi right now. This section sets out exactly what that is, who sees it, and how to switch it off. It applies to accounts only: a guest opening a link has no account, no ring and nothing recorded here.
- What we store. One row per account, holding one word and one timestamp: whether you are in a meeting, working on a document, moving files, or simply have Nemi open, and when your browser last said so. It is overwritten every time, so there is no history: we cannot tell you, or anybody else, what you were doing yesterday, because we did not keep it.
- What it deliberately does not hold. Which meeting, which document, which file, which workspace, and which page you are on. The ring says "in a meeting"; it cannot say which one, because that is not stored.
- Who can see it. Only people you already work with in Nemi: somebody you are connected with (Section 3.1), or a member of a workspace you are in. Nobody else can ask for your ring, and an account address on its own gets nothing. Until September 26, 2026, having you in their contacts was enough, and anybody who had shared a file with you had you in their contacts without you agreeing to it; that is what connections replace. Your browser tells us what you are doing only while a Nemi tab is open and in front of you; a tab in the background says nothing, which is why the ring goes quiet by itself when you walk away.
- How full your storage is, is only ever shown to you. Your own ring also carries how close your account is to its storage limit. That signal is filtered out on our servers for every other viewer, whatever your sharing setting says, so it is never sent to anybody else at all.
- Switching it off. Settings, under Style: one switch turns off what other people see. Off is silent, which means that to everybody else you look like somebody who is not in Nemi right now, rather than like somebody who has hidden their presence. Your own ring keeps working on your own screen.
- The ring replaced one that showed your plan. Until this version, the ring around a profile photo was coloured by the subscription that account was on, and was visible to anybody who could see the photo. That is gone.
3.21 Offline mode, and content kept on your own device
On the paid plans you can switch on offline mode, which keeps a copy of documents and files on the device you are using so that Nemi opens and works without a connection. This section is about that copy. It is the one place in the Service where your content is deliberately stored somewhere we do not operate and cannot reach, and that cuts both ways: it is outside our infrastructure, and it is therefore outside our protection.
- It is off until you switch it on, on each device separately. Nothing is stored on a device that has not asked for it. The switch is in Settings, under Offline, and it applies to the device you press it on and to no other. Signing in somewhere new does not carry it across, deliberately: a copy of your work on a borrowed laptop should be a decision you make on that laptop.
- What is copied. The documents, spreadsheets and canvases you open or mark to keep, including their full text and every edit that makes them up; the contents of the files you mark to keep, as whole files; and, where you use them, a read-only copy of your contacts and your calendar events. It is stored in your browser's own storage, on your own hardware.
- It is your device, not ours. We do not hold this copy, we cannot read it, and we cannot delete it for you remotely. Anybody who can use that device and reach that browser profile can open what is in it, which includes anybody you share the machine with and anybody who takes it. If the device is not yours alone, or is not encrypted, that is the thing to weigh before switching this on. Device encryption and a screen lock are your protections here, not ours.
- How long it stays. Until you remove it. There is no expiry. You set a storage budget for the device, and when the copy grows past it the least recently opened items are removed to fit, except for anything you explicitly marked to keep and anything holding edits that have not reached us yet, which are never removed automatically. The Offline screen lists everything the device is holding, with sizes, and removes any of it on one press.
- Switching it off deletes it, and so does signing out. Turning the switch off removes the whole copy from that device, along with the stored parts of the application itself. Signing out now does the same. Until 19 September 2026 it did not, and this page said so: the copy belonged to the device rather than to the session, and we told you to switch offline mode off yourself before leaving a shared machine. That was a burden we could carry for you and a trap if you forgot, because the next person to sign in on that machine inherited the copy, the switch already on, and the storage it was using. Signing out now clears the documents, the files, the cached application and the setting. Your theme and accessibility settings are kept on purpose, so the screen you are sent to stays readable.
- Edits made offline live only on that device until it reconnects. If you type while disconnected, that work exists in one place: the device in front of you. It is sent as soon as a connection returns and the document is open, and the Offline screen says how many documents are still waiting. Until then, losing or wiping the device loses those edits, and we have no copy to restore from.
- Which parts of the application are stored, and which are not. To open without a connection, the device keeps a copy of the program files Nemi is built from and one page that is identical for every visitor and contains no account data at all. No page carrying your content or anybody else's is ever stored this way. While you have a connection, the Service is always fetched fresh rather than read from that copy.
- Which content qualifies. Documents and files belong to a workspace, so whether they may be taken offline follows the plan of the person who owns that workspace, in the same way every other workspace limit does. Your contacts and your calendar belong to your account and follow your own plan. That is why some of your workspaces may be available offline while others are not.
- What it does not reach. A vault folder is never copied to a device by this feature, and neither is anything you have not opened or marked. Offline mode does not change what you are allowed to see: it stores a copy of what you could already open, and access is still checked against your account every time you are connected.
- It is new in this version. Until 17 September 2026 the Service kept nothing of your content on your device beyond what a browser holds to display the page you were looking at, and our help pages said there was no offline mode. Both are now out of date, and this section is the statement of what changed.
3.22 The Nemi apps for iPhone
Nemi Files, Nemi Calendar and Nemi Gallery are also iPhone apps. They are the same Service as the website, with the same account, and everything in this policy applies to them. This section covers what is different on a phone: what the apps can reach on your iPhone, and what of it ever reaches us.
- Signing in. You sign in with a code we email you, exactly as on the website; there are no passwords. The app then holds a device token, which is kept in the iPhone's Keychain, sent only to nemilab.com, and valid for 30 days. The Nemi apps on the same iPhone share that Keychain item, which is what lets a second Nemi app offer "Continue as" without asking for another code; no other developer's app can read it. Every device token appears among the signed-in devices in your account settings, and signing it out there, or "log out everywhere", ends it at once. Signing out in an app deletes its token from the iPhone.
- Apple Health, in Nemi Calendar (optional). If you switch on workouts, Nemi Calendar asks Apple Health for permission to read your workouts and the heart rate recorded during them, so it can show them beside your day. It only reads, and never writes to Apple Health. This data stays on your iPhone. It is read when the timeline is drawn and is never sent to us, stored by us, shared with anybody, or given to the assistant in Section 3.18. You can withdraw the permission at any time in the Health app or in iOS Settings.
- Music in Nemi Calendar. The songs beside your day come from the Spotify connection described in Section 3.7, through our servers, and nothing about them is read from the iPhone itself.
- Your photo library, in Nemi Gallery (optional). Photo backup asks iOS for access to your photo library, and you can give it full access or only the photos you pick. It reads photos to back them up and never changes or deletes anything in Photos. The conversion described in Section 3.8 happens on the iPhone where it can: the photo is converted there and only the converted file is sent. A photo the iPhone cannot convert is sent as it is, converted on our servers, and the original is discarded straight afterwards, as on the website. Shared albums are not backed up, because those photos belong to whoever shared them. The app keeps a list on the iPhone of which photos are already backed up, so it does not send them twice, and deletes it when you sign out.
- Backup while you are not looking. With backup on, the app asks iOS to let it continue in the background, for example overnight while the phone charges, and shows its progress on the lock screen while it runs. That progress display is drawn by iOS on your iPhone from numbers the app gives it; nothing extra is sent to us for it.
- Searching your photos, in Nemi Gallery. Photo search on the iPhone works as described in Section 3.8a. The search model is downloaded from nemilab.com once, on your request, and runs on the iPhone: it reads each photo there and turns what you type into a list of numbers there, and only those numbers are sent, never the words you typed or an extra copy of the photo.
- The camera, in Nemi Files. The camera is used when you scan a document, take a photo into a folder, or scan a Beam code. A scanned document or photo is uploaded to the folder you chose, like any other file. When the camera is looking for a Beam code, the picture is read on the iPhone and only the code it finds is used; the camera image itself is never sent or kept.
- Face ID, in Nemi Files. Face ID is used to show an open vault again after you have been away from the app. The check is done by iOS; the app is only told whether it succeeded, and we never receive anything about your face.
- No tracking, no analytics, no advertising. The iPhone apps contain no analytics, crash reporting, advertising or tracking code from anybody, ours included, and do not use the advertising identifier. They talk to nemilab.com and to nothing else, apart from three things: the storage links our servers hand them to upload and download your files; the sign-in page of a calendar or music account you choose to connect, which opens in Apple's own secure browser window; and a picture that is kept somewhere else, such as a Spotify album cover in Nemi Calendar or a profile photo that comes from a Google account. Your iPhone loads that picture from where it is kept, so that company sees your IP address as it would for any image on the web, and nothing else about you.
3.23 Building apps on Nemi
If you apply to build apps that offer "Sign in with Nemi" (Section 6.3a), we store what you write in your application: the name you build under, your website and what you plan to build, together with whether we approved, declined or suspended it, the note we wrote with that decision, and when. What you wrote about your plans and our note are encrypted at rest like other things people write in Nemi. For every app you register we store its name, description, logo, website, links to its privacy policy and terms, the addresses it may send people back to, the permissions it may ask for, its review status and our notes, a one-way fingerprint and the last few characters of each secret it uses in place of the secret itself, and the email addresses of the people you invite to test it. We use this to decide whether to let you build, to show your app to the people who sign in to it, and to email you about our decisions. The people you invite to test an app are told nothing by us; you are responsible for having their agreement to give us their address. Your application and the records of your apps are deleted when you delete your account. When you delete an app, its record is deleted together with its secrets, its testers, every approval people gave it and every key it held.