Security and privacy in Mataki
Mataki keeps programme assessments on the device that made them and asks its server only to confirm who you are. This page describes every protection Mataki has, as built, including the limits.
Assessments stay on your device
- Assessments are stored in your browser on the device you use. They are not uploaded.
- They are encrypted with AES-GCM (256-bit) under a key derived from your password, or your data passphrase if your organization signs you in, with PBKDF2-SHA-256. Neither is stored.
- You can choose a four-digit PIN to unlock them on that device while you stay signed in. Five wrong tries remove it, and it never outlasts the sign-in.
- Mataki locks the screen after a period without activity, so notes are not left open on a shared or unattended device.
Passwords and sign-ins
- Before your password leaves the browser, Mataki seals it to the server’s public key (ECDH on P-256, then AES-256-GCM), inside the https connection. Only the server can open it, and it keeps only a bcrypt hash.
- A sign-in lasts at most 90 days from when you signed in. Using it never extends it. An account can be signed in on at most three devices.
- Its secret changes at least once an hour while in use, and a copied secret used later ends the sign-in for everyone holding it.
- Signing out, changing the password, deleting the account or an administrator’s action ends a sign-in at once on the server. A device learns of it the next time it connects.
- After five wrong passwords from one network, signing in to that account from that network pauses for 15 minutes. Thirty from all networks together pause it everywhere for 15 minutes, except from networks the account signed in from before and from browsers still signed in to it.
- A network that sends 100 wrong passwords in an hour, to any accounts, is blocked from the whole server for an hour.
- A confirmation link works only with the password chosen when the account was created, so someone who registers your email cannot have their password confirmed by your click.
Signing in with your organization
An organization can connect its own sign-in service to Mataki. Each organization has its own configuration, with its own credentials, and it stays off until Mataki’s super administrator turns it on. Only email addresses in the organization’s own domains can use it.
- OpenID Connect: every sign-in carries a single-use random state value, a nonce and a PKCE code challenge, and Mataki refuses any return that does not match. The identity token’s signature is checked against the organization’s published keys, along with its issuer, audience, time and nonce, and an email the organization has not verified is refused. Mataki asks only for the openid and email scopes, and profile if the organization wants names filled in.
- SAML 2.0: the assertion must be signed with the organization’s certificate, addressed to Mataki, in answer to a request Mataki made, and within its time limits. Responses Mataki did not ask for are refused.
- Both return only to two fixed addresses registered with the organization. The return is bound to the browser tab that started it, so a stolen return link does not sign anyone else in.
- Mataki never sees the organization password. The client secret Mataki holds for an organization is sealed on the server.
- Once an organization signs in an account, that account’s Mataki password stops working, so the organization alone controls access. A registration someone else made for the address, never confirmed, is set aside.
Accounts and administrators
A new account works only after its owner confirms the email address with a link, valid for 48 hours, and an administrator for the account’s place approves it. Administrators see only the accounts in their own area. Each person can see everything they gave at registration, edit it, and delete the account from Account settings.
- The administration pages are at an unguessable address that only signed-in administrators receive. The super administrator can change it at any time.
- Nothing there opens without a verified sign-in from an account with administrator rights, checked by the server on every request.
- Every administrative view and action, every sign-in and failed sign-in, and every account change is written to an audit log with the time and who acted.
- The address changes by itself when an administrator loses their rights or their account.
- A temporary password from an administrator works for 72 hours, and only to set a new one. When an administrator marks an email confirmed, the password chosen at registration stops working, and the person receives a temporary one.
How the server defends itself
- A firewall checks every request before it reaches Mataki’s code. It refuses methods Mataki does not use, known scanning tools, and requests that carry path traversal, null bytes, stream wrappers, script or SQL injection, shell commands or addresses of internal services.
- Addresses that Mataki has never had, which scanners try first, and guesses at the administrators’ address count as strikes. Five strikes in an hour block the network from the server for a day. Requests that another website makes a visitor’s browser send never count, so no page can get its visitors blocked.
- Registration, email confirmation, sign-in and single sign-on each have their own rate limits per network and across the whole site.
- Registration has a hidden field and a minimum time to fill in, so automated sign-ups are quietly discarded.
- Every server address that Mataki does not serve answers with the same plain error page.
What the browser may load
- Mataki loads no third-party scripts, fonts, images or frames on any page. There are no analytics, advertising, chat or social media tools.
- A content security policy lets scripts run only from Mataki’s own files. Inline scripts and inline event handlers cannot run, nothing loads from another origin, and no other site can put Mataki in a frame. Any breach of the policy is reported to Mataki’s fault log.
- Mataki sets one cookie, the sign-in cookie, which scripts cannot read. The cookie statement has the details.
The connection to the server
- Mataki works only over https. The server tells browsers to use https for two years on usemataki.app and all its subdomains, and asks to be on the browsers’ built-in https list. Every .app domain is on that list already, so browsers never make a plain http request to it.
- Passwords and temporary passwords are also sealed inside each request and reply, so they stay protected even where a network inspects https traffic.
- Certificate pinning, where a client accepts only one certificate, is not available to websites: browsers removed it because a mistake could lock every visitor out. Mataki relies on the protections above, and on public certificate transparency logs, which record every certificate issued for its domain.
Errors that reveal nothing
When something fails, you see a plain message and a reference number, never a file path, query, database detail or software version. The full details go to Mataki’s central fault log, where the reference number finds them. The server does not announce its software or version.
What the server records
The server keeps a log of sign-ins and account actions with the account email, who acted, the place, and a salted one-way hash of the network address. Faults are recorded with what failed, where, the kind of request and the account key, never the values you typed. When the app meets a fault it sends a short description, with emails and phone numbers removed. Mataki collects no location, contacts or analytics.
Deleting an account
- When you delete your own account, every sign-in ends at once, you receive a data report of everything the server held about you, and everything on the server that names you is erased. Your email and account key are replaced in every log and in the records of anyone you approved as an administrator. The server checks at once that nothing remains and records the result, an email confirms the erasure, and the hourly sweeper checks the account folder again within 24 hours.
- When the super administrator deletes an account, it stops working at once and can be restored for 60 days. After that it is erased in the same way.
The tracking link
Updates from code holders and what each place sees are encrypted in the browser before they are sent, with keys that come from the tracking codes. The server receives a code id and a proof derived one way from the code, never the code or the keys.
If something goes wrong
Scalentric Limited keeps an incident response plan for Mataki. Its emergency controls can end every sign-in on the server at once, pause new registrations, and replace the server’s keys and the administrators’ address. If a breach puts personal data at risk, Scalentric Limited notifies the Nigeria Data Protection Commission within 72 hours, as section 40 of the Nigeria Data Protection Act 2023 requires, and tells the people affected when the risk to them is high.
Your part
Enter aggregate figures and themes only: no names of patients, caregivers or health workers. Under the Nigeria Data Protection Act (2023), you and your institution are the data controllers for what you enter.
Limits
- A forgotten password or data passphrase cannot be recovered by anyone, and neither can the assessments it protects. An administrator can reset a password on the server, but data on a device stays locked with the old one.
- A device that stays offline cannot learn that its sign-in was ended until it reconnects. In that time the encryption and the screen lock protect its data.
- A four-digit PIN is a convenience. Someone who copies the browser’s storage could try every PIN, so use one only on a device you control.
- Confirming an email proves the address belongs to the person, not their job. Administrators approve only people they know work in the place they chose.
- Mataki runs on shared hosting. The host’s own security, and the email service that sends account emails, are outside Mataki’s code.
Report a security problem
If you find a weakness in Mataki, write to info@scalentric.org with what you found and how to see it. Please do not read, change or delete other people’s data, and ask for written permission before any test that could affect other accounts or the service. The same address is in security.txt.
The full details are in the privacy notice, the terms of use and the data processing agreement.