What happens to your data.

MASS LLC (The MASS Lab) operates KnowMessenger. This notice describes what the product does with your data across the web app, the desktop app, the iOS app, and the APIs behind them. It is written against the running code, not from a template.

The iOS app is a native shell around the same service, not a separate product with its own collection. It can reach KnowMessenger's own origins and nothing else, over a fixed list of API routes rather than an open browser. It does keep you signed in between launches: four session cookies are stored in the iOS Keychain, marked so that they are readable only after the device has been unlocked once since it was switched on, only on that device, and never synced to iCloud or included in a backup. They are destroyed when you sign out, when you delete your account, when they expire, and whenever the server rejects them. On Android nothing is stored at all, so closing the app signs you out there. Where a behaviour below differs on the phone, the paragraph says so.

Where a behaviour is not yet implemented, this notice says so rather than describing the intention as if it were the product.

Creating an account collects an email address, a password, and — optionally — a display name. Passwords are handled by Amazon Cognito; KnowMessenger never stores or sees your password.

Signing in sets four first-party cookies. Three carry session tokens and are HTTP-only, so page scripts cannot read them: an ID token and an access token that live one hour, and a refresh token that lives thirty days. The fourth holds your username and is readable by the page purely so the interface can greet you. Two short-lived marker cookies coordinate silent session refresh; both are cleared on sign-out.

There are no analytics, advertising or session-replay cookies, and no third-party tracking scripts. The content-security policy the server sends only permits scripts from KnowMessenger's own origin.

On the default “Managed” backend, your messages, the conversation history you are continuing, and any vault content the assistant reads for you are sent to Amazon Bedrock, an Amazon Web Services product, in an AWS region (us-east-1 unless configured otherwise). Bedrock serves the request; KnowMessenger does not call a model vendor directly on this path.

The models offered on that backend are built by Anthropic (the Claude family), Moonshot AI (Kimi), Z.ai (GLM) and MiniMax. They run inside Amazon Bedrock, so your prompt reaches AWS; the model builders are named here because you are choosing whose model reads your words.

If you switch the backend to “Your key”, KnowMessenger stops using Bedrock for that conversation and calls your chosen provider directly — Anthropic at api.anthropic.com, or OpenAI at api.openai.com — authenticating with the API key you supplied. Your messages then reach that provider under your own account and their terms, not ours. On this path the assistant has no access to your vault: it is text only.

That API key is stored in your Token Holder vault under a path namespaced to your own user, not in KnowMessenger's database, and it is resolved server-side for each turn rather than travelling with each request from your browser.

If you switch the backend to “Local agent”, the turn runs a command-line AI tool already installed on your own machine. KnowMessenger supplies no credentials to it and refuses the turn if any of its own vendor credentials are present in the environment being handed over; that backend is structurally unreachable on our deployed servers.

KnowMessenger does not use your conversations to train models. What each provider does with data you send it is governed by that provider's own terms, which you should read before choosing a backend.

Because these are third parties, the app asks you to acknowledge this disclosure once, and records that acknowledgement against your account before third-party AI features are used.

On the hosted service, each conversation is stored in a DynamoDB table partitioned by your user id. Messages either sit on that record or, when the larger-thread storage mode is enabled for a stage, are written as a single JSON object in an S3 bucket under a key prefixed by your user id, with the record keeping a short preview and a pointer.

Files you attach to a chat are uploaded to a separate S3 bucket under a prefix scoped to your user, using a short-lived upload URL the server mints for you. Uploads are capped at 25 MB.

Chat attachments and stored conversations move to cheaper storage after 30 days and are deleted 365 days after they are written; superseded versions are removed after 90 days and abandoned uploads after 7. Recorded stories are kept differently — see “Recorded stories”.

Deleting a conversation removes its database record and makes a best-effort delete of the stored message object. One gap is open and stated here rather than glossed: files you attached to that conversation are not swept along with it, and are removed by the bucket's own expiry rather than by the delete. Deleting your whole account does reach them — see “Your choices”.

The desktop app is different by construction. When KnowMessenger runs as a local host — the packaged desktop app, or a developer running it offline — conversations are written to files on your own machine, under a KnowMessenger folder in your home directory, and are not sent to our servers. There is no sync feature today: local history stays local, and if syncing is ever added this notice has to change before it ships.

When you record a story, the recording is uploaded in one-megabyte pieces to a storage bucket used only for stories, under a prefix scoped to your user. Each piece is checked when it arrives, and the recording is kept in the format your browser made it in; it is not converted. A story can be up to 20 minutes and 24 MB, and an account can hold up to 500 stories, counting any in the trash.

Your recordings are kept until you delete them or close your account. They are not on the 365-day clock that applies to chat attachments and stored conversations, and nothing deletes a saved recording on a schedule. They are stored in a single region (US East), with no second copy elsewhere, so we do not promise to keep them forever; you can download the original at any time to keep a copy of your own.

Deleting a story moves it to a trash for 30 days. While it is there only you can see it: it cannot be played, downloaded or shared, and you can restore it. After 30 days it can no longer be restored or opened. The stored recording, including any earlier stored versions, is then removed in two ways: when you next open your trash, and by a scheduled cleanup that is built but currently switched off. Until that cleanup is switched on, a recording in a trash that is never reopened can remain in storage after its 30 days, unreachable. You can also delete a story from the trash for good at any time.

You can share one story with one person by email. We email them a link from themasslab.com, sent through Amazon SES; we keep only a one-way hash of the address and a masked hint such as m••••@example.com, never the address itself. The link opens nothing on its own: it works once, expires after 7 days, and after the person signs in it gives that one account access to that one story. Whoever signs in with it first becomes the person it is shared with, so the story's sharing list shows you who that was, and you can stop sharing at any time; that takes effect on their next request, including partway through listening. People you share with can listen, but cannot download the story, share it on, or see anything else in your account. Email invitations are built but not switched on yet; until they are, sharing says so and sends nothing.

Closing your account removes every story at once, including stories in the trash and any unfinished uploads.

Audio never leaves your device. The recording is transcribed and analysed on your own machine, and KnowMessenger holds no API key for that step; what reaches our servers is transcript text and the short cards produced from it.

Transcript text is stored in a dedicated S3 bucket, separate from chat storage, under a key scoped to your user and session; session records, cards and your Jamie settings are rows in the same DynamoDB table as the rest of your account.

Four defaults apply before you change anything, and an unrecognised stored value falls back to them rather than to the permissive option: capture is announced to the room, speakers are not separated, retention is the shortest setting, and captured material is never used for training.

Retention is your choice among three settings: 7 days, 90 days, or no automatic deletion. A session is judged against the stricter of the setting that applied when it opened and your current setting, so relaxing the setting later never extends how long already-captured material is kept.

Being precise about how that deletion actually runs: it happens when you use Jamie — the app sweeps your expired sessions as it serves your requests, deleting the transcript, then the cards, then the session record. A scheduled sweep that would also reach accounts which have stopped being used is built and deployed, but it currently ships switched off. Until it is switched on, material belonging to an account that goes quiet can outlive its retention window. Individual cards additionally carry a database expiry as a backstop; session records do not.

Deleting a Jamie session deletes its stored transcript along with it.

Your knowledge base lives in a Token Holder vault that you control, not in KnowMessenger. When the assistant needs to read or write a file there, it asks Token Holder; if it lacks permission, it stops and submits a grant request that you approve or refuse in your wallet. KnowMessenger cannot read outside the paths you have granted.

KnowMessenger writes an append-only audit entry for significant actions, submitted to a separate, shared audit service run by the same parent organisation. An entry carries the action name, the tenant it belongs to, your account identifier, a trace id, and a small bag of structured details — for a chat turn: which backend and model ran, why the turn stopped, and token counts. The text of your messages is not part of it.

Three kinds of entry do carry content-derived detail, and all three are named here rather than the easiest one. When you attach a file, the entry records its filename, content type, size and storage key, so access to an attachment can be reconstructed later. When you report content, the entry records the free text you wrote about it — that is the operator's record of a complaint, and unlike your own copy of the report it is not removed when you delete your account. And when the desktop app opens a terminal session, the entry records the working-directory path on your own machine.

Audit submission is best-effort and bounded: it is abandoned after 500 milliseconds so it can never stall your request, and it does nothing at all on a deployment where the audit endpoint is not configured. An audit record is therefore evidence that something happened, never proof that everything did.

Audit entries are kept as compliance evidence and are not on the 365-day storage clock that applies to conversations and attachments. They are also outside account deletion, by design: deleting your account removes your own records, and the operator's audit record of what was done on the account is retained. The deletion screen says so before you confirm, and it is the one thing on this page that a deletion does not undo.

Your IP address is used to rate-limit requests, and a rate-limit event is logged with the request method, path class, tenant and how long the caller must wait. Request logs do not contain message content.

There is a voice input button on the guided-lens screens. It uses your browser's own speech-recognition engine, and depending on the browser that engine may send audio to the browser vendor for transcription; KnowMessenger receives only the resulting text and never the audio. Two limits belong here rather than in a footnote: every response this service sends carries a permissions policy that disables the microphone, and the button is deliberately absent from the chat composer because the speech engine is not available inside the desktop and iOS app shells. Treat it as a control that is present in the code and off on this deployment.

The app counts product usage — which features were used, and how many turns ran — and stores those counts against your account. Four dimensions travel with each count: an identifier for this installation, which surface you are on, the app version, and the build id. The installation identifier is sixteen random bytes generated the first time the app runs and kept in this site's own storage in your browser. It is deliberately not a fingerprint: nothing about your device, screen, timezone or network goes into it, it is never shared with anyone, it is never used to follow you across apps or websites owned by other companies, and clearing site data destroys it. Counting is on unless the build was made with it switched off. Message text is never part of a count.

Paid plans are billed through Stripe. Stripe's hosted checkout receives your email address so it can prefill the form, plus identifiers for your tenant, product and plan. Card details go to Stripe directly; KnowMessenger never receives or stores them.

If your account was created for you through MASS Lead Connect, KnowMessenger receives provisioning and deprovisioning events for it over a signed webhook, and refuses any message whose signature or timestamp does not check out.

Every response carries a content-security policy, strict transport security, MIME-sniffing protection, and a rule forbidding the site from being framed by another page.

Stored data sits in AWS-managed encrypted storage, and the account database is configured for point-in-time recovery.

You can change your chat backend, replace the API key stored for you, change Jamie's retention and capture settings, delete an individual conversation, and delete an individual Jamie session together with its transcript. There is no button today that erases a stored API key outright — replacing it is the available action, and removing it is one of the requests a person handles.

You can delete your whole account from inside the app, under Settings → Data (linked from Settings → Account). It is a button, not a request: it cancels any subscription first, then works through every store the account touches — your conversations and their stored message objects, your uploads, your Jamie sessions, transcripts and retention record, your access grants, your remaining account rows, your usage counts, your export bundles, and finally your sign-in identity. Before you confirm, the screen shows you a preview of what will be visited and, separately, what a deletion run on our servers provably cannot reach. It cannot be undone and there is no recovery window.

Two things a deletion run does not reach, both shown on that screen before you confirm rather than discovered afterwards. Conversations written by the desktop app live on your own computer under a local-only identity, so a deletion performed on our servers cannot touch them — remove them from inside the desktop app. And the operator's audit record of actions on your account is retained by design, as described under “The audit record”.

For anything the product cannot do for you, use the form on the support page.

KnowMessenger is not directed to children, and accounts are not knowingly created for them.

This notice is dated 2026-09-11. Because its factual claims are tied to the code that backs them, a change to how data flows is meant to force a change here — but the date above is the only promise that it has been reviewed.