Privacy policy
Last updated 19 August 2026
1. Who we are
Mirra is smart-display and digital-signage software: one console that drives screens showing calendars, weather, photos, tasks, Home Assistant and, optionally, a voice assistant. It is built by the team behind Twinview.[Placeholder: legal entity name, company number, registered address, ICO registration number, and confirmation that the contact address below is monitored — it has not been confirmed.] For anything in this policy, write to support@twinassistant.com.
This policy covers the Mirra portal, the software running on your screens, and the voice relay that sits between them. It does not cover Home Assistant, your calendar provider, or anything else you connect — those remain governed by their own terms.
2. What we hold, and why
The table below is the whole list. Mirra is multi-tenant: everything except the plan catalogue and feature flags belongs to your account and is scoped to it.Data What it is Why
Account Your email address, name, role, and a bcrypt hash of your password. We never store the password itself. Signing you in and telling your account apart from anyone else's.Household / organisation The account name, your plan, subscription status, any white-label branding, and the names and greeting preferences of the people you add. Running the service and applying plan limits.
Screens A screen's name, orientation, panel size, app version, platform, when it was last seen, its layouts and its schedule. Showing the right thing on the right screen at the right time.
Photos The image files you upload, plus filename, format, size, album and upload date. Displaying them on your screens.Calendars The connection details you enter — an .ics URL, CalDAV address and credentials, or a Google / Microsoft authorisation. Reading your agenda so a screen can show it.
Home Assistant A long-lived access token, and a last-known snapshot of the entities you expose: entity id, friendly name, domain, state, area, unit and device class. Offering entity pickers in the editor and letting the assistant act on them.
Tasks and reminders The text you type, and when a reminder is due. Showing them, and delivering them at the right time.Assistant transcripts The text of what was said to the assistant and what it said back, with a timestamp and the screen it happened on. So you can review what your assistant has been asked, and so a conversation can follow on from the previous turn.
Usage metering Per turn: input and output token counts, seconds of speech transcribed, characters synthesised. No content. Measuring the AI allowance on your plan.
Presence events A record that a screen recognised a known person (by internal id) or an unknown face, with a timestamp. No image, and no face measurements. Driving presence-triggered scenes and greetings.
Billing Your Stripe customer and subscription identifiers. Taking payment and knowing which plan you are on.
Security log An audit trail of significant actions, with the acting user, a short description, the IP address the request came from, and the time. Investigating account problems and abuse.
API and webhook credentials For API keys we store only a visible prefix and a SHA-256 hash — the key itself is shown once and never stored. Webhook widgets hold a bearer token and the last value posted to them. Letting your own systems read from and write to your screens.
Push notifications If you turn them on: the push endpoint your browser issues, its two keys, and your browser's user-agent string. Sending alerts to your phone or desktop.
3. Photos
Photos you upload are stored in an Amazon S3 bucket, filed under your account's own prefix. On a self-hosted install with no bucket configured, they are written to the server's own disk instead. Either way they are served back to your screens through Mirra rather than from a public URL, and deleting a photo in the portal deletes the underlying object.Photos are not analysed, indexed by content, or used to train anything. Uploads are limited to common image formats and 15 MB each.
4. Calendars
Mirra supports four kinds of calendar connection: a public or secret .ics URL, a CalDAV collection with a username and password, Google Calendar via OAuth, and Microsoft Outlook via OAuth. Google and Microsoft connections are requested read-only.The credentials you provide — CalDAV passwords, OAuth refresh tokens, secret feed URLs — are encrypted before they are written to the database, using AES-256-GCM. Event details themselves are fetched from your provider when a screen asks for them and are not kept in a Mirra table. They can, however, reach the assistant: see section 6.
5. Home Assistant
A Home Assistant long-lived access token grants complete control of your home, so it is encrypted at rest with the same envelope as calendar credentials and is never displayed back to you after it is saved.Mirra's servers do not connect to your Home Assistant. Commands are sent down to the screen on your own network and executed from there. What we do keep centrally is a last-known snapshot of each entity you expose, so that the layout editor can offer a picker and the assistant knows what exists. Historical state stays in Home Assistant; we do not collect it.
6. The voice assistant
The assistant is optional, and there is no always-listening wake word in the product today. The microphone opens only when someone deliberately starts a conversation on the screen.Audio
Audio is captured on the screen as 16 kHz mono and streamed over an authenticated connection to Mirra's relay, which forwards it to Amazon Transcribe to turn into text. Mirra does not write that audio to disk, to a database or to object storage — it is held in memory for the length of the request and discarded. The spoken reply is generated by Amazon Polly and sent back to the screen to play; it is not stored either.What the model sees
The transcribed text is sent to Anthropic's Claude, either through Amazon Bedrock or through the Anthropic API, depending on how your installation is configured. A self-hosted install can be pointed at a local Ollama model instead, in which case nothing goes to either.Be aware that a request carries more than your question. So that the assistant can answer usefully, it may include today's calendar events, your open tasks, upcoming reminders, the names of household members and the state of your Home Assistant entities. The same is true of the short greeting brief that is generated when a screen recognises someone.
Transcripts and metering
The final text of each turn is stored against your account — what was said, what the assistant replied, and the automatic briefs the system generated — and is visible on the Assistant page. Interim speech recognition results are shown on screen but never stored. Alongside them we record token counts, seconds transcribed and characters synthesised, in order to meter your plan's AI allowance; these carry no content, and unlike the transcripts they are not covered by the expiry windows — see section 12.Transcripts expire on a schedule you choose, and are kept for 90 days unless you say otherwise. You can shorten that, lengthen it, or switch expiry off, in the portal; section 12 explains how. There is still no button that deletes a single conversation, so shortening the window is how you get rid of one early — the change is applied immediately rather than at the next sweep. Closing your account deletes them all.
7. Face recognition and presence
A screen can recognise household members so that it can greet them and change what it shows. This is the most sensitive thing Mirra does, so here is exactly how it works.The camera is off by default and has to be turned on for a screen. It is also opened while you are enrolling someone, which you start from the portal.
Recognition runs entirely in the browser on the screen itself. The models are shipped with the app; no video, image or frame is uploaded anywhere for it.
Enrolling someone produces a set of numeric face descriptors. These are the only biometric artefact Mirra creates. They are stored in that screen's own browser database and never leave the device — not to our servers, not to storage, not to any third party. No photograph of a face is stored at any point.
What reaches our servers is a count of how many samples a screen holds for a person, and, when someone is recognised, an event recording the screen, the person's internal id and the time. An unrecognised face is logged only as "someone was there", with no identity attached, and is never greeted.
Deleting a person, or removing their enrolment, in the portal causes the screen to erase the stored descriptors the next time it syncs.
There is no video streaming or recording anywhere in the product. The camera feed is never written down and never sent.Face descriptors are biometric data. Only enrol people who have agreed to it, and make sure everyone who lives or works in front of the screen knows the camera is on. If a child is enrolled, that decision belongs to a parent or guardian.
Note that when a recognised person triggers a greeting, their name and a summary of their day are sent to the language model, as described in section 6. The biometrics stay on the device; the name does not.
8. Payments
Payments are processed by Stripe. Mirra never sees or stores your card number, expiry date or security code — card details are entered on Stripe's own hosted pages and held by Stripe. What we keep is the customer and subscription identifiers Stripe gives us, so we know which plan your account is on. Stripe's handling of your payment data is covered by Stripe's privacy policy.
9. What your screen keeps locally
A paired screen stores the following on the device itself:Its device identifier, its pairing secret and a session token, so it can reconnect after a reboot without being paired again.Face descriptors for anyone enrolled on it, as described above.
Whatever the browser caches while displaying your content — photos, weather responses, fonts — in the ordinary way any browser caches a page.
Unpairing a screen in the portal invalidates its credentials. To wipe the device completely, clear the browser's site data or reflash it.
10. Who else processes your data
We use a small number of providers to run the service. This is the complete list as the software stands. [Placeholder: confirm the data processing agreement in place with each, and the regions actually used in production.]Provider What for What they receive
Amazon Web Services Hosting, database, photo storage Everything described in section 2.Amazon Transcribe Speech to text Audio of what you say to the assistant.Amazon Polly Text to speech The text of the assistant's reply.Anthropic (directly, or via Amazon Bedrock) The assistant's language model Conversation text, plus the calendar, task and home context described above.
Stripe Payments Your card details, name and billing address — directly, not through us.
Google / Microsoft Calendar connections you choose to make An authorisation to read your calendar.
Open-Meteo Weather The coordinates of a weather widget's location. No account data.
Your browser's push service Notifications, if enabled The notification we send you.
Google Fonts Typography in the portal A font request from your browser.
Mirra runs no analytics, advertising or product-telemetry services. There is no tracking SDK in the portal or on your screens, and we do not sell or share your data with anyone for marketing.
11. Cookies
The portal sets one cookie, mirra_session. It is HTTP-only, same-site, expires after seven days, and exists solely to keep you signed in. There are no analytics cookies, no advertising cookies and no third-party trackers, which is why you have not been shown a consent banner.12. How long we keep things
Your account details, photos, layouts, tasks, reminders, people and integration settings are kept for as long as your account is open. Three kinds of record expire on their own, on a schedule your household sets in the portal:Record Default What expires
Assistant conversations 90 days Each turn — what was said and what was answered — is deleted once it is older than the window. A conversation disappears when its last remaining turn does.Presence events 30 days The record that a screen recognised someone, or saw an unidentified face.Security log 365 days The audit trail of significant actions, with the acting user, time and IP.
Each window can be set to anything from 0 to 3,650 days. Zero means keep until the account is closed — it switches expiry off for that kind of record rather than deleting immediately. Only the account owner can change these; anyone in the household can see what they are set to.
Shortening a window takes effect at once: the records that already fall outside it are deleted as the setting is saved, and the portal tells you how many went. Otherwise the sweep runs about once a day, so a record can outlive its window by up to a day — and longer if the server it runs on has been restarting, because the timer that drives it only counts time while the software is up.
AI usage records are kept whatever these settings say. They are the token counts, seconds transcribed and characters synthesised that your monthly allowance and your bill are worked out from, and deleting them would leave invoices that cannot be reconciled. They carry no content — no words, only quantities. They are deleted when the account is closed.
Security log entries that belong to no account — a failed sign-in against an email address that does not exist, for instance — are not governed by anyone's setting, so they are deleted after 365 days.Visitor records are anonymised rather than deleted. A building running a reception desk sets how long a visit keeps the visitor's details — a year by default. After that the visit itself survives without any personal details attached to it, and the visitor's own record goes once no visit points at it any more. The reason for the split is that a building has to be able to say how many people were inside at a given time after a fire or an incident, and deleting the visit destroys exactly that; keeping it without a name answers "how many" while refusing to answer "who". Documents a visitor had on file, and the scans of them, are deleted outright at the same time.
13. Taking a copy, and closing your account
Downloading your data
Anyone in a household can download everything held about it as a single JSON file, from the portal, without asking us and without waiting. It contains the household record and its settings, the member accounts, the people you have added and the fact of their enrolments, your screens, scenes and schedule rules, your devices, albums, tasks and reminders, the full text of your assistant conversations, your presence history, insights, the integrations, API keys and webhooks that exist, your AI usage records, and your security log.Photographs are not inside the file. Each one is listed with a link you can download while signed in. A household with a few thousand pictures could not be packed into a single response, so this is a list of your photos rather than the photos themselves, and it is worth saying so plainly.
Credentials are left out on purpose: password hashes, the encrypted Home Assistant token and API key secrets. The file records that they exist, not what they are — a copy of them sitting in a downloads folder is a worse outcome than the portability it would add. Face descriptors are not in it either, because they never leave the screen (section 7); what appears is the number of samples a screen holds for a person. The Home Assistant entity snapshot, push-notification registrations and any SSO connection are also not included. Taking an export is itself recorded in the security log.
Closing the account
The account owner can close the account from the portal. Because it cannot be undone, it asks for your password and for the household's name typed back before it will proceed. If a Stripe subscription is still running it will refuse until you have cancelled it on the Plan page — cancelling on your behalf would be a billing action you had not asked for, and leaving it running would charge you for an account that no longer exists.Closing deletes the household and every member account in it, the people and their enrolment records, screens, scenes and schedule rules, albums, tasks, reminders, assistant conversations, presence history, insights, integrations and the credentials stored in them, API keys, webhooks, push registrations, the Home Assistant entity snapshot, the usage records, the account's own security log, and the log of messages we have sent on the account's behalf. If the account runs a reception desk it also deletes the visitor book: the visitors themselves and their contact details, their visits and the events recorded against them, the documents they had on file, the permits to work, the parcels, and the companies in the building. Photo files and profile pictures are removed from storage, and so are scanned visitor documents and signed permits — not just their rows in the database. Your screens are unpaired and go back to showing a pairing code, so the hardware stays usable.
Three things outlive it, and you should know about all three. <strong>A record that the closure happened is kept.</strong> It is written without an account attached — precisely so that deleting the account cannot delete it — and it holds the acting user's internal id, an action name, a short description, an IP address and a time. Nothing of your photos, transcripts or calendar is in it, and it ages out on its own after a year. The account's own security log goes with everything else. Second, the face descriptors held on your own screens are not ours to reach: clear the browser's site data on the device or reflash it. Third, Stripe keeps its own record of payments it has taken, under its own policy.
14. Your rights
If you are in the UK or the EEA you have the right to access your data, correct it, have it erased, restrict or object to how it is used, and receive a copy in a portable form. You can also withdraw consent — for example by turning a screen's camera off, deleting an enrolment, or disconnecting a calendar — at any time, without losing the rest of the service.Most of this is self-service. A copy of your data and the closure of your account are both described in section 13 and both are buttons in the portal rather than requests to us; how long things are kept is section 12; and you can delete photos, people, enrolments, screens, API keys and integrations individually whenever you like. For anything else — a correction you cannot make yourself, an objection, or a question about what is held — write to support@twinassistant.com and we will respond within one month.
If you signed a visitor book that runs on Mirra, this section is not the one you want. You have the same rights — to know what is held about you, to have it corrected, and to have it erased — but the building you visited is the controller of those records and we are only its processor. Write to the building rather than to us: they can produce everything held about you in a few clicks, and erase it. Two things survive an erasure and they are obliged to tell you so. The record that a visit happened is kept without your name, because a building has to be able to say how many people were inside at a given time after a fire or an incident. And a permit to work, if one was ever issued to you, is kept in full and goes on naming you, because it is a health and safety record they are required to be able to produce. If you cannot get an answer from the building, write to us and we will help you reach them.
If you are not happy with our answer you can complain to the Information Commissioner's Office at ico.org.uk.
15. Security
Traffic is served over TLS. Passwords are stored as bcrypt hashes. Integration secrets — Home Assistant tokens, calendar credentials, SSO client secrets — are encrypted with AES-256-GCM before they reach the database. API keys are stored only as a hash. Screens and the relay authenticate with signed, expiring tokens, and every query is scoped to a single account.No system is perfectly secure. If you find a vulnerability, please report it to support@twinassistant.com rather than disclosing it publicly, and we will work with you on a fix.