Information Security Policy

1. Scope and accountability

This policy covers all personal information handled by Aljundi Lab Corporation in connection with the Super Siblings mobile app: parent account data, subscription records, crash and analytics data, and partner invitations.

Accountable individual: Mulham Aljundi, Aljundi Lab Corporation. Reachable at eng.mulhamjundi@gmail.com.

Aljundi Lab Corporation is a small company. Rather than describe controls we do not have, this policy states what is actually in place.

2. The risks this policy addresses

1. Unauthorised access to a family's account — someone reading or altering another family's data
2. Exposure of children's information — the most sensitive category, and the one the architecture is built to make impossible
3. Credential compromise — a stolen parent password or leaked service key
4. Loss or corruption of data — accidental deletion, provider outage
5. Vulnerable dependencies — third-party code with known flaws
6. Device access by a child — a child reaching billing or settings screens

3. Controls in place

3.1 Data minimisation — the primary control

The strongest protection for children's information is not to hold it. Children's names, ages and preferences are stored in the app's private on-device database and are never transmitted to us. The family record that does sync to our servers structurally excludes child data: the serialisation that produces the remote payload omits those fields entirely, and Firestore security rules reject any family document carrying a field outside an explicit allowlist. There is no code path by which a child record can reach a server, and the server would refuse it if there were.

A breach of our servers therefore cannot expose information about any child, because no such information is there.

Scope note — device backup. Where the device owner has iCloud Backup or Android Backup enabled, the operating system includes the app's private storage in that user's own backup. This is outside our control and outside our access: the backup resides in the user's Apple or Google account under their credentials, encrypted by that provider. We do not disable it, because doing so would destroy a family's data on device replacement. It is recorded here because a security policy that quietly omits it would be inaccurate, and because the distinction — the user's own backup versus our systems — is the one that matters when assessing our risk.

3.2 Encryption

• All network traffic uses TLS 1.2 or higher. The app makes no unencrypted requests.
• Data at rest in Google Cloud Firestore is encrypted using Google-managed AES-256 keys.
• On-device data is protected by the operating system's own file encryption (Data Protection on iOS, file-based encryption on Android).

3.3 Access control

• Authentication is delegated to Firebase Authentication using Google, Apple, or email and password. We never see or store a Google or Apple password.
• Firestore security rules deny every read and write that does not come from the authenticated owner of the record. The default is deny; access is granted explicitly, per collection.
• Operations that must not be client-controlled — issuing partner invitations, applying subscription state — run in Cloud Functions with server-side validation. The client cannot write those records directly.
• Administrative access to the Firebase project is limited to the accountable individual, protected by two-factor authentication.

3.4 Secrets

• No private key, service-account credential or API secret is committed to source control or shipped inside the app.
• Server-side secrets are held in Firebase Functions secret storage.
• The Android upload keystore and its password are stored offline and in a password manager, never in the repository.
• Parental gate PINs are never stored in clear text. They are hashed with SHA-256 and a per-record random salt.

3.5 Child-facing safeguards

• Kid mode locks navigation so a child cannot reach settings, billing or account screens from inside an activity.
• Settings and billing sit behind a parental gate.
• The app contains no advertising SDKs, no third-party trackers, and no web browser or external links reachable from kid mode.

3.6 Dependency and code security

• Dependencies are pinned in pubspec.lock and Podfile.lock so builds are reproducible.
• Dependency advisories are reviewed before each release, and any package the publisher has retracted is replaced rather than pinned.
• Static analysis and the automated test suite must pass before a release build is produced.
• Release builds are code-shrunk and obfuscated.

3.7 Availability and backup

• Firestore is managed by Google with multi-region replication.
• The app is offline-first: activities are cached on the device, so a provider outage does not stop a family using it.
• Backups inherit the same encryption as live data and are deleted on a rolling 30-day cycle.

4. Retention and deletion

Retention periods are set out in the Privacy Policy, which is where the amended COPPA Rule requires them to live. Deletion is available to any parent from Settings → Account → Delete my account, and is honoured within 30 days.

5. Vendor management

We use Google (Firebase) and RevenueCat as processors. Both are assessed on their published security posture and contractual commitments before use, and both are reviewed at the annual review below. Neither is permitted to use our data for their own purposes.

6. Incident response

If we suspect a breach of personal information:

1. Contain — revoke affected credentials, tighten rules, take the affected function offline if needed.
2. Assess — determine what data, whose, and how much, within 72 hours of becoming aware.
3. Notify — inform affected users and the Office of the Privacy Commissioner of Canada where the breach poses a real risk of significant harm, as PIPEDA requires, plus any other regulator with jurisdiction.
4. Record — log every breach, including those not requiring notification, and retain the record for 24 months as PIPEDA requires.
5. Fix — address the root cause and record what changed.

Report a suspected vulnerability or breach to eng.mulhamjundi@gmail.com. We will acknowledge within 72 hours. We will not pursue legal action against anyone who reports a vulnerability in good faith and does not access more data than necessary to demonstrate it.

7. Annual review

This policy and the risks it names are reviewed at least once a year, and after any material change to the app's architecture or to a vendor relationship. The review checks that stated controls are still in place, that retention periods are being honoured, and that vendors remain appropriate.

Last reviewed 1 August 2026. Next review due 1 August 2027.