Halaman ini merupakan terjemahan yang disediakan agar dapat dibaca. Versi bahasa Inggris-lah yang berlaku secara hukum. Leila reads a family's mail and holds information about named children. That is a serious thing to be trusted with, so this page describes the specific measures behind it — including the places where we are not yet where we want to be. It is written to be checked, not to reassure.
This describes how we protect your data. Our privacy policy describes what we collect and why, and our data deletion page describes how to get rid of it. This one is about the engineering.
It is not a certification. We do not hold SOC 2 or ISO 27001, and we will say so plainly here until we do. Section 13 lists what else is missing.
Everything is encrypted in transit, over TLS, with no unencrypted fallback. Our domains are served over HTTPS only.
Everything is encrypted at rest, including backups. School portal credentials carry a second layer on top of that — see section 5.
Access is granted to a named person for a specific task, not to a role that everybody holds. It is logged and it is reviewed.
Every internal system that can reach customer data requires multi-factor authentication. Production credentials are separate from everything else. Live family data is never copied into a test or development environment; our test suites run against synthetic households.
Our own administrative tools sit on their own address with their own sign-in. Sessions are opaque tokens stored only as a hash, so a copy of our session table does not yield a working session. The cookie is host-only and cannot be presented to a sibling subdomain. Passwords are stored with a slow key-derivation function, and repeated failures lock the account rather than merely slowing it.
Separation is enforced by the database, not by our application code. Every table carries row-level security, and it is forced rather than merely enabled — meaning it applies even to the account that owns the table, which is the usual way this protection is quietly bypassed.
We test this against a real database rather than asserting it in a comment: a test signs in as one household and attempts to read another's children, and fails if the database lets it. It is the layer least likely to be exercised by anything else we write, and the only one standing between a bug in a single route and one family reading another's information.
If you connect a school portal, we store the username and password, because signing in to a portal requires replaying them. They cannot be hashed the way a password we only need to verify can be, and we will not pretend otherwise.
They are held under a second layer of encryption whose key is not in the database. A stolen copy of the database alone does not yield them.
They are decrypted only at the moment a task you approved is running. They are never written to a log, an error report or a backup in readable form, and they are never sent to an AI model. The model that reads a portal page never receives the credential that opened it.
Disconnecting a portal erases the credential immediately rather than marking it inactive.
Leila uses AI model providers to read and summarise school messages, under contracts with zero-retention and no-training terms: what we send is not kept by them and is not used to train anything.
Credentials, OAuth tokens, payment details and our own secrets are never included in what we send. Nor are they written to logs or crash reports.
A one-time login code is never logged, and an error returned to you never carries a provider's raw message, because those messages routinely contain the recipient's phone number or email address.
This one is specific to what Leila is, and it is worth understanding. Everything Leila reads arrives from outside: school emails, WhatsApp forwards, newsletters, PDFs, portal pages. Somebody else wrote all of it. A sender can be spoofed and a school portal can be defaced.
So none of it is treated as an instruction to Leila, however it is phrased and whoever it claims to be from. A message telling her to fetch a URL, ignore what she was told, change how she behaves, or reveal what she knows about a family is not an unusual request. It is an attack, and she carries on with the actual task and flags the message for a person.
A page is not more trustworthy for claiming to be urgent, official, from the school's IT department, or from us. Nothing we tell Leila ever arrives inside something she fetched or read.
Leila prepares; you approve. A reply, a form submission or a payment is shown to you in full, with every value she intends to enter, and waits.
Actions that cannot be taken back — a submission, a payment — require a separate confirmation each time, even where you have approved similar things before. This is a security control as much as a product one: the damage an attacker could do by influencing what Leila reads is bounded by the fact that she cannot act alone.
Secrets live in the deployment environment and are never committed to our source code. Our mobile app physically cannot carry a server-side key: the app refuses to start if one is found in its configuration, which turns a dangerous mistake into an obvious one.
Incoming webhooks from our payment, email and messaging providers are verified by signature over the exact bytes received, before anything in them is parsed or trusted.
Card details never reach our servers. Payments are handled by Stripe, which is PCI DSS Level 1 certified; we receive a reference and the outcome, never a card number.
We run error monitoring that strips personal data from what it records.
If a breach occurs that is likely to result in a risk to you, we will notify you and the UAE Data Office without undue delay, and tell you what happened, what we did about it, and what you should do. We will not wait until we have a complete picture to tell you something is wrong.
A short list, each under a written contract limited to what they need: Stripe for payments, a cloud provider for hosting and storage, an email and messaging platform for transactional messages, and AI model providers under zero-retention, no-training terms.
Kami akan mengirimkan daftar terkini atas permintaan yang dikirimkan ke privacy@hileila.com. Jika kami menambahkan penyedia layanan yang secara signifikan mengubah cara penanganan data Anda, kami akan memberi tahu Anda sebelum layanan tersebut mulai beroperasi.
Relying on a provider does not move the responsibility to them. Where a measure on this page depends on a provider, it is still ours to verify.
We have not had an independent penetration test. We intend to, and we will date it here when it happens.
We hold no security certification. Section 1 says so for the same reason this section exists: a security page that lists only strengths is not describing a real system.
We are a small team. We do not run a 24-hour on-call rotation, so an issue reported at three in the morning is answered in the morning.
Portal credentials are reversibly encrypted and necessarily so, as section 5 explains. It is the single most sensitive thing we hold, and it is the thing we would most like not to have to hold at all.
Write to security@hileila.com. If you have found a vulnerability, we want to know before anyone else does.
We will acknowledge within 2 working days and keep you informed. We will not threaten or pursue anyone who reports a genuine issue to us in good faith, who does not access or alter data belonging to another family, and who gives us a reasonable opportunity to fix it before telling the world.
We have no bug bounty budget. We will credit you here if you want to be credited.