Legal
The documents a customer's compliance team asks for, in one place: the data processing agreement, who processes what, where it lives, how long it is kept, and how it is protected. Questions: security@go-looma.com.
Data processing agreement · Sub-processors · Data residency · Retention · Security · What Usher keeps · Site terms · Privacy notice
Site terms
What a site's owner agrees to when adding a site: that Usher may access the site and act on its forms as its owner's rules allow, that the site is theirs to add, and that they indemnify Looma. Accepting them is part of adding a site, and each site's record keeps the version accepted, when, and by whom. Read the site terms.
What Usher keeps
- Nothing a person types is stored. Their own assistant fills the form; Usher puts their answers in the site's format inside one call and keeps none of them, or, for an assistant with no browser, fills it for them and forgets them.
- Maps describe forms, not answers. The site's log holds field names and the person's decisions, never the values.
- Medical questions are filled only if the site allows it, and only with the person's own answer, which they confirm.
The same three lines as the front page and the security document in the code (docs/security.md); a test keeps them identical.
Data processing agreement
A draft for counsel to settle before a customer signs it. Its facts are the code's; its terms are a starting point.
- Parties and roles. The customer (the site owner) is the controller of the personal data that passes through its forms. Usher (usher.run) is the processor, acting only on the customer's documented instructions: the rules the customer sets for agents on its forms, and this agreement.
- What is processed. On the customer's behalf Usher processes: the structure of the customer's forms (maps: labels, field types, buttons; never values); agent sessions (which agent, which page, which fields were filled by their meaning, which decisions a person confirmed; never the values); and the customer's owners' names and email addresses for sign-in and notices. What a person types into a form is entered into the customer's own site inside one call and is not stored by Usher; a test checks this after every kind of fill.
- Instructions. Usher acts on the customer's rules (which agents may act, what needs a person's confirmation, what is forbidden, how long sessions are kept) as set in the customer's dashboard, and processes nothing beyond what those rules and the service need.
- Confidentiality. Only the people who run Usher can reach customer data, under a duty of confidentiality, and only to run the service or at the customer's request.
- Security. The measures in the security summary below, kept current with the code at https://github.com/rhys-looma/Usher.
- Sub-processors. Those listed below. Usher gives the customer notice of a change to the list before it takes effect, and the customer may object.
- Data subjects' rights. Usher helps the customer answer a request to see, correct or delete personal data: a site's owner can read and delete their site's sessions, and remove the site, from the dashboard; anything else by request to security@go-looma.com.
- Breach. Usher tells the customer without undue delay, and within 72 hours of learning of it, of a personal data breach affecting the customer's data, with what is known and what is being done.
- Deletion. Sessions are deleted on the retention schedule below. When the customer removes a site or closes its account, the site's maps, rules and sessions are deleted. On request Usher confirms deletion in writing.
- Audit. The code is open at https://github.com/rhys-looma/Usher, the security document describes what it does, and the customer may ask for the information needed to show compliance, and for an audit at reasonable notice and no more than once a year unless a breach or a regulator requires one.
- Transfers. Customer data is held in eu-west-2. Where a sub-processor is outside the UK and EEA, the transfer rests on the sub-processor's standard contractual clauses or UK addendum, and only the data named in the list reaches it.
- Term. This agreement lasts as long as the customer uses Usher and until the customer's data has been deleted.
Sub-processors
| Who | What | Where |
|---|---|---|
| Amazon Web Services | Runs the registry, its database and its backups, and sends owners' emails (SES). | London (eu-west-2) |
| WorkOS | Site owners' sign-in: holds their email address and name. | United States |
| Stripe | Takes payment for plans: card details never reach Usher. | United States and Ireland |
| Sinch | Sends and receives text messages for sites that turn texts on: the person's phone number and what they text, for the conversation only; Usher keeps neither. | Sweden and the EU |
| Meta (Muse Spark) | Labels the structure of forms when a map is built: field labels and types, a masked screenshot, never a value. | United States |
| Baseten (Muse Spark Open) | A second opinion on field risk, from the same structure. | United States |
Data residency
Usher runs on Amazon Web Services in London (eu-west-2): the registry, its Postgres database, its backups and its logs. Nothing a customer's site sends is stored outside eu-west-2. The structure of a form (never a value) is sent to the model sub-processors above when a map is built, and not kept by them under their terms for API use.
Retention
- Sessions. Agent sessions are deleted after 90 days, or after the shorter time a site's rules set (retention.session_days). The registry runs the deletion every hour.
- Map checks. The keeper's record of map checks is deleted after 90 days.
- Interest form. Messages from the "I run a site with forms" form are kept until the sender asks for them to be deleted.
- Accounts and sites. An account's people and audit trail are deleted with the account; a site's maps, rules and sessions are deleted when the site is removed.
- What people type. What a person types is never stored, so there is nothing to retain or delete.
Security summary
What could go wrong and what stops it, in brief. The full document is docs/security.md, and security.txt says how to report a problem.
- Agents that do not knock. A site's own server checks for a token on consequential endpoints and refuses without one (403 knock_required).
- Stolen or replayed tokens. Tokens last ten minutes, name their site and intent, are accepted once, and carry the agent's key, so a copied token is useless without it.
- Poisoned maps. Maps are kept per origin, match only a page with the same structural fingerprint, stay private until a second identity or the keeper confirms them, and can never weaken the server-side check.
- Changed forms. A drift report triggers the keeper, which rebuilds the map from the live page and holds it for the owner where they ask; a knock on a page whose map is out of date is refused with the reason, never served the old map to fill from.
- Session snooping. Reads need the site's secret key, stored hashed; writes need the session's own token; a site must prove its origin before it sees anything.
- Leaking what people typed. Extraction never reads a field's value, screenshots mask every typeable field, the log records actions by key, and tests search every file, table and line printed after each kind of fill.