Safety model
The safety claim must be tied to a specific mechanism.
UuLApp targets one of the internet’s structural weaknesses: services often cannot reliably distinguish a child from an adult who claims to be a child.
Threat → control
What UuLApp is designed to prevent.
| Risk | Protocol control | Remaining safeguard needed |
|---|---|---|
| Adult opens a “child” account with a false birthday | No UuLApp minor status without school certification | Service must refuse self-declared status as equivalent |
| Adult appears in minor gaming/chat pool | Service filters by verified child credential and permitted age group | Correct implementation and moderation |
| Child claims to be older | Age band originates from school records, not self-declaration | Credential lifecycle and school updates |
| Credential stolen or shared | Revocation, strong authentication and device/session protections should be required | Secure implementation by credential and service providers |
| False credential issued by insider | Auditable school issuance, enrolment reconciliation, expiry and revocation | Institutional controls and sanctions |
| Bullying between minors | Age verification alone does not solve it | Reporting, moderation, education and school/parent support |
| Harmful content | Age group can support safer content settings | Platform content governance remains necessary |
Scope of “100%”
100% school certification for every UuLApp minor credential.
UuLApp’s strongest defensible rule is binary: a valid UuLApp minor credential is school-certified or it is not a UuLApp minor credential. Participating services then use that status to design child-only interaction. This does not mean a service is immune to hacking, credential theft, bullying or every form of online harm.