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) shown next to your name where the Service displays senders and collaborators.
- 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.
- 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.
- 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. That is fixed: a contact you added by username now holds the handle, the display name and a link to the account, and no address, and the suggestion list only ever shows an address you supplied yourself. Contact rows written before this change keep the address that was copied into them, because we cannot tell those apart from the addresses their owners typed in themselves. If you would rather your address were not in somebody's contacts, they can delete the contact, and deleting your account removes it everywhere. 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 filled with rows from other parts of Nemi you can read, such as form responses, a folder's file list, your own calendar, or your own share link statistics. 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. Embedding is always started by a person who could already read the source, and it is their choice, the same as pasting.
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.
- 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 never reaches us (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.
- 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.
- 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.
- We never receive what is said or shown. Audio, video and shared screens travel from each participant's browser straight to the other participants' browsers, encrypted, without passing through our servers. 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.
- 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 are transcribed on the speaker's device, and the text does pass through us. Anybody in a meeting can switch on captions for themselves. Their own browser transcribes their own microphone, using the recogniser built into that browser. No audio reaches us and none reaches the other participants. Where that audio goes instead is the browser's decision and not ours, and it is worth knowing: most browsers transcribe by sending the audio to a speech service the browser vendor runs, so switching captions on in such a browser sends your own voice to your browser's maker, on your own instruction, in a request we are not part of and cannot see. Where the browser can transcribe with a model on the machine itself, Nemi uses that instead and the audio then genuinely goes nowhere; it does so automatically when the vendor service cannot be reached. What is sent to the meeting either way is the resulting text, and unlike the audio that does travel through our servers, because it is the same channel that carries the chat. We pass each line straight on to the other participants and store none of it. Everyone in the meeting is shown who is captioning. When the person captioning leaves, the finished sentences are written into the meeting notes described below, which belong to the host and outlive the meeting, so a caption is not only shown live: it is kept, by the host, in the same way the chat is. Captions are one switch per person, so nothing you say is transcribed unless you switched them on yourself.
- 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.
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.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; whether you are on a desktop, a phone or a tablet; your browser and operating system; the page that referred you; and, if you reached the link through an invitation addressed to you, your email address. Your raw IP address is not stored.
- 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 4b 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.
- 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. When it is, the visitor's browser fetches that font file from Google, and Google receives the visitor's IP address as part of that request, exactly as it would on any other website that uses those fonts. Google is not processing anything on our behalf here and receives nothing about the visit beyond what a font request carries. Choosing one of the fonts we serve ourselves avoids the request entirely.
- 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 page shows one, ticking it releases the buttons on that page. 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 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.
- 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. Any image you attach, or ask it to look at, is downscaled and re-encoded before it is sent. Your display name and the name of the workspace you have open travel with it so the answer makes sense.
- 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, a United States company, 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. So the model runs inside the EU and the routing step in front of it does not, and we say both because the second one is a transfer whether or not the first sounds reassuring. We send every request with an instruction that it may only be served by a host that does not retain what it is sent, and we do not permit it to be used to train a model. 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.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: someone in your contacts, 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. 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.