Privacy

Matter is software your firm installs and runs. Documents, matter files, notes, the semantic search index, deadline records, time entries and edit history are written to storage your firm controls. None of it is transmitted to us.

Vaults are encrypted at rest. Where a matter is encrypted, the key belongs to your firm: either bound to a Windows account or derived from a firm passphrase we never see. If you enrol a vault in recovery escrow, we hold one half of a recovery key and never the other. Recovery needs an officer of your firm and us acting together, and neither of us can act alone.

Diagnostics and performance logs are written on the machine and are not sent anywhere. Activity capture, which records how someone works and never what they write, is off unless your firm’s policy permits it and the individual turns it on for themselves.

This is the part a reader is most likely to assume does not happen, so it is stated plainly: licensing is not local. When a machine is activated, and each time its licence is renewed, it contacts our licence service and sends

• the activation code
• a device identifier
• the operating-system user name of the person activating
• the computer’s name, which becomes the device label your administrators see
• the application version, and a public key that pins the device

A computer name and an OS user name frequently identify a person. We use them for one purpose, which is showing your administrators which devices hold seats so they can label and revoke them, and your firm can see the same list in its own portal. No document content, no file name, no matter name and no client name is part of this.

Accounts exist for firm administrators and for our own staff. There is no public signup: an account is created only by invitation. We store your name, email address and role, a hash of your password rather than the password, and, if you enable it, a two-factor secret. Sessions record a hash of the session token, the browser’s user-agent string and timestamps.

Actions taken in the console and the portal are written to an audit log that names the actor and what they did. It exists so that a firm can see who changed what about its own account, and so that we can explain a change when asked.

We keep a server-side record of requests to this site. It includes the full IP address, the time, the path, the HTTP method and status, the user-agent string, the referring host, and a reverse-DNS lookup of the address. An IP address is personal data and we are not going to describe it as anything else. We keep it to understand who is interested in the product, and to see abuse.

The landing page, and only the landing page, loads Google Analytics. It is not loaded on the sign-in page, the console, the firm portal, an invitation link, a guest channel, a data room, or on this page. That boundary is enforced in code and tested, because those URLs contain things that should not be handed to an analytics vendor.

These are optional features a firm turns on. When it does, documents and messages reach our infrastructure as ciphertext. The key that opens them is placed in the fragment of the link your firm shares, the part after the #, which a browser does not transmit to a server. The recipient’s browser decrypts locally.

The practical consequence: somebody with complete access to our database, ourselves included, reads opaque bytes. We can see that a room exists, how large its documents are, when they were fetched and through which link, and we can delete them. We cannot read them. Document identifiers inside a room are chosen so that we cannot even tell whether two different rooms hold the same document.

If your firm connects a calendar, a mailbox or a contact directory, it does so with its own consent and, on the recommended path, its own registered application. The permissions requested are read-only: calendar events, mail messages, your profile, your contacts and relevant-people lists. There is no send, write or delete permission anywhere in the product, and a build check fails if one is ever added.

Those connections are made by the application on the firm’s machine, not by us. The access tokens are sealed to that Windows account on that machine, and are never sent to us or handed to the embedded browser. Mail, calendar entries and contacts fetched by a connector are stored in the firm’s own matter files.

We do not sell personal data and we do not use it to train models. Matter’s AI features run on the firm’s machine by default; where a firm configures a cloud model instead, it uses its own account with that provider and the traffic does not pass through us.

The first three are removed by a scheduled job that acts on a retention date stamped onto each record as it is written, so a record carries its own expiry rather than depending on a rule somebody might later change.

If you are in the UK or the EEA you have the right to ask what we hold about you, to have it corrected or deleted, to object to how we use it, and to complain to your data protection authority. Where your firm is our customer, your firm is the controller of its own matter data and we act on its instructions; for the account and website data described in sections 3 and 4, we are the controller.

Ask us at hello@mahe.one. Because of how the product is built there is one limit worth knowing in advance: for encrypted vault contents, and for hosted rooms and channels, we can delete what we hold but we cannot produce it in readable form, because we cannot read it either.