Balance — Child Safety Standards

Effective date: 19 July 2026 Last updated: 19 July 2026

Reviewed annually: next scheduled review by 9 June 2027.

This is the public Child Safety Standards statement published by BabaYaga Program, TOO ("BabaYaga Program", "we", "us", "our") for the Balance Android application (package com.babayagaprogram.balance). It satisfies the published-standards requirement of the Google Play Families Policy "Child Safety Standards" program and the equivalent obligations under U.S. federal law (18 U.S.C. § 2258A; the Trafficking Victims Protection Act), the UK Online Safety Act 2023 (Part 5), Australia's Online Safety Act 2021, the EU Digital Services Act (Regulation (EU) 2022/2065) where applicable, and the consumer-protection statutes of every country listed in Section 18 of our Privacy Policy.

It is read together with — and complemented by — our Privacy Policy, our Children's Privacy Notice and Direct Notice to Parents, our Terms of Service, and our Subscription Terms.

1. Our standard

BabaYaga Program has zero tolerance for child sexual abuse and exploitation ("CSAE") and for child sexual abuse material ("CSAM", as defined in 18 U.S.C. § 2256(8) and the equivalent definitions in EU law) on or through the Balance Service.

We design Balance to make child sexual abuse and exploitation impossible to commit through the Service, we cooperate fully with national child-safety authorities and hotlines, and we keep this standard under continuous review.

2. Designated Child Safety contact

The Child Safety Officer has personal authority to escalate, to retain external counsel, and to preserve evidence under our internal CSAE Incident Response Protocol (Section 9). The Officer also signs every report we file with a national hotline or law-enforcement authority.

This designation, with the named individual, is the point of contact required by Google Play's Child Safety Standards declaration.

3. The architectural reality the rest of this statement rests on

Balance is not a social network. The Balance app does not contain — and we do not plan to introduce — any of the following surfaces:

• public profiles, friends lists, public usernames, friend-finding, contact-import;
• chat, direct messages, group messaging, comments, replies, mentions, posts, stories, livestreaming;
• public photo galleries, public video galleries, public posting of any user-generated content;
• discovery, recommendation, or search of users or content across households;
• shared rooms, voice rooms, video rooms, or any other multi-user communications space.

There is no Balance surface where one user can find, contact, communicate with, or send content to another user who is not in the same paired family. The kid uses Balance only with the parent who has paired the kid's device.

In addition, the proof media the kid uploads to mark a task done (Section 4.3 of the Children's Privacy Notice) is end-to-end encrypted on the kid's device before any network call. Plaintext content never reaches our servers and never reaches our storage provider. We cannot view, transcribe, hash, index, or hand over the plaintext content of any proof media. Only the parent's authorised device(s) can decrypt it. This is the strongest possible technical guarantee against the misuse of Balance as a CSAM-distribution channel: there is no third party who could decrypt and re-distribute the content from us — there is nothing to decrypt, on our side or on our storage provider's side.

Together, these two design choices — no multi-user surface, end-to-end encryption — make Balance categorically unsuited to be a vector for CSAE. Every standard in the rest of this document is grounded in that architectural reality.

4. The CSAE conduct we prohibit

We prohibit, on and through the Balance Service:

1. Production, possession, transmission, upload, distribution, solicitation, request, or purchase of CSAM (as defined in 18 U.S.C. § 2256(8), in EU Directive 2011/93/EU in UK Protection of Children Act 1978, and in the equivalent statutes of every country).
2. Grooming of a minor for sexual purposes (as defined in EU Directive 2011/93/EU Article 6; UK Sexual Offences Act 2003 sections 14–15A; the equivalent provisions of every country).
3. Sextortion of a minor.
4. Trafficking in minors and the sexual exploitation of trafficked minors.
5. The purchase, sale, exchange, or live-streaming of sexually explicit content depicting minors.
6. Any promotion, normalisation, glorification, or facilitation of any of the above — including instructional content, "tutorials", communities, contact-discovery aids, encryption services targeted at offenders, or "how-to" content that facilitates contact with a minor for a sexual purpose.

Any of the above, attempted on or through Balance, is a material breach of our Terms of Service (Section 8) and is grounds for immediate suspension, account termination, full data preservation, and a mandatory report to the competent national authority under Section 8 below.

The standards apply regardless of whether the person engaging in the conduct is the parent on the account, the kid on the paired device, a third party who has gained access to either device, or a household member who has been given access by the parent.

5. How Balance prevents the prohibited conduct (the design-side controls)

Each control below is published as part of this Standard so it can be audited against the in-app behaviour.

5.1 No multi-user surface

There is no place in Balance where one user can post content visible to a user in another household. There is no chat. There is no discoverability across households. There is no public anything. The kid's data is visible only to the parent who paired the kid's device. See Section 3.

5.2 Capture-only proof media — no gallery picker, no incoming content

When a task requires photo or video proof, the kid's device opens the camera in capture mode. There is no gallery picker, so a third party cannot trick the kid into uploading pre-existing imagery to Balance, and the parent cannot send imagery into the kid's device through Balance. The capture path is one-way (kid → encrypted-storage → parent).

5.3 End-to-end encryption with a per-file key

Each proof file is encrypted on the kid's device with a fresh per-file key (XChaCha20-Poly1305) wrapped to each authorised parent device's X25519 public key, before any network call. The key never leaves the device unwrapped. This means: even a sub-processor compromise yields ciphertext only; a server-side actor cannot extract plaintext; we are not in a position to redistribute, monetise, or otherwise misuse the kid's proof media. See Section 9 of the Privacy Policy.

5.4 Parent-gated everything

Every consent decision in Balance is made by the parent (a verified adult) on the kid's behalf. The kid does not sign up, does not see legal documents, and does not consent to any data processing. The pairing flow is parent-initiated; the kid's device cannot join a parent account without an invite code generated by the parent.

5.5 No advertising, no profiling, no nudge mechanics directed at the kid

There is no advertising in Balance. There is no kid-directed engagement-maximising design, no autoplay, no infinite scroll, no streak-as-pressure, no recommendation algorithm, no notification stream that runs while the kid is not actively using the app for a parental-control purpose. This deprives an offender of every dark-pattern surface that is typically exploited to draw a minor into prolonged engagement.

5.6 Strict permission hygiene on the kid's device

The Balance app on the kid's device requests only the permissions strictly necessary to deliver parental controls (see our Permissions Register). It does not request access to: contacts, SMS, call logs, location, browser history, microphone outside of explicit proof-video capture, gallery, social-network credentials, or biometric identifiers. An attacker who compromised the Balance app on the kid's device would gain no surface for harvesting the kid's social graph or location.

5.7 Operational logging discipline

Plaintext media, plaintext OTPs, plaintext credentials, and encryption keys are prohibited in our logs by a code-review rule. We do not retain a copy of any image, video, or audio fragment in our server logs.

5.8 No SDK that could read kid content

The kid build of Balance embeds Firebase Crashlytics for crash-diagnostics only — configured per § 6 of the Privacy Policy with no kid-content data, no advertising SDK, no attribution SDK, no behavioural-profiling SDK, and no social-login SDK directed at the kid. The full sub-processor list is in § 6 of the Privacy Policy.

5.9 Sub-processor accountability

Every sub-processor we engage signs a written data-processing agreement that forbids them from using any data we transmit for any purpose other than performing the service we engaged them for. The list and what each sub-processor can see is published in Section 6 of the Privacy Policy and Section 7 of the Children's Privacy Notice.

6. The in-app "Report a concern" button

We provide — or, where the implementation is still rolling out, will provide as that rollout completes — an in-app reporting mechanism that lets any user (parent device or paired kid device) raise a CSAE-related concern from inside the Balance app, in the place where the concern is observed:

• a Report a concern button visible on every proof-media screen and on every kid-detail screen in the parent app;
• a short form: type of concern (CSAM / grooming / sextortion / trafficking / other CSAE / something else) + free-text description + optional contact-back email;
• the form does not require the reporter to share any plaintext image, video, or audio with our backend — the reporter chooses what to include;
• the report is routed automatically to () and to a separate hot-path queue in our internal incident-tracking system;
• the reporter receives an automatic acknowledgement within minutes and a substantive response from a human within one business day, in line with Section 2.

Status at the date of this Standard: the in-app reporting mechanism is scheduled to ship before public release. During any interval before in-app reporting goes live, the mailbox is the operational reporting channel for users, with the same one-business-day acknowledgement target. We do not gate a CSAE report behind the in-app button.

Reports may also reach us through any of:

• Email: .
• Postal mail at the address in Section 2.
• EU representative Prighter, UK representative Prighter.
• National hotline that contacts us under a memorandum-of-understanding (Section 10).

We will not retaliate against any reporter for filing a report in good faith. We will not require a reporter to identify themselves.

7. How we triage a report (the internal incident-response workflow)

Each CSAE report received through any channel in Section 6 is handled under the following internal workflow:

1. Acknowledge the report within one business day, in writing, in the language of the reporter (English by default; Spanish for LatAm reports; we will arrange translation for any other language).
2. Classify within 24 hours, as one of: (a) suspected CSAM possession or distribution; (b) suspected grooming or sextortion of a minor; (c) suspected child trafficking; (d) other CSAE; (e) non-CSAE matter — re-route to the correct queue.
3. Preserve evidence for any report classified (a) through (d): the parent-account record, the kid-account record, the pairing metadata, the encrypted-media metadata (object names, sizes, timestamps in Google Cloud Storage), the relevant server logs, and any voluntarily-submitted material from the reporter. Preservation is for at least the period required by 18 U.S.C. § 2258A(h) (90 days, extendable by 90 days on agency request) and by the equivalent rule in the country of the reported user.
4. Take the immediate-effect action on the same day, based on classification: - For (a) and (b): suspend the parent account, freeze the paired kid's device, lock the encrypted-media objects at the storage layer (Google Cloud Storage object-hold), and preserve the cryptographic chain. - For (c): same as (a), plus immediate escalation to specialised anti-trafficking law-enforcement contacts (Section 10). - For (d): suspend the parent account; preserve evidence; proceed to investigation.
5. Investigate with care for the rights of every named party. Encrypted proof media is not decrypted by us as part of investigation — see Section 8 — but metadata (Section 3) is.
6. Report to the competent national authority within the statutory deadline in Section 8.
7. Notify the affected family where this is consistent with the investigation and with the law of the country (we do not tip off a suspect; we do notify a parent victim where appropriate).
8. Close the file with a written disposition (in the internal incident-response system) and a one-line public-facing entry in the annual transparency report (Section 11).

The Child Safety Officer (Section 2) personally approves every escalation to step 6 or step 7.

8. National reporting obligations and how we discharge them

8.1 United States — 18 U.S.C. § 2258A (CyberTipline / NCMEC)

Where a Balance user is in the United States, where a Balance user is a U.S. minor, or where U.S. jurisdiction otherwise attaches under 18 U.S.C. § 2258A and § 2258B, we file an NCMEC CyberTipline report as soon as reasonably practicable after we have actual knowledge of an apparent violation of 18 U.S.C. § 2252 (CSAM) or 18 U.S.C. § 2422(b) (online enticement of a minor). The report includes the metadata available to us (parent-account email, parent-account creation date, kid metadata, pairing dates, encrypted-media object metadata, timestamps), the reporter's information (where the reporter consented to be identified), the in-app surface where the matter arose, and the preservation tag.

Why our reports may not include plaintext content. Proof media is end-to-end encrypted (Section 3 and Section 5.3). We are unable to attach a plaintext copy of a media file to an NCMEC report because we have no plaintext copy and no ability to produce one. The encrypted ciphertext is meaningless without the parent's media key, which is held only on the parent's device(s) (and, if the parent opted in, in a Google Drive AppData blob the parent can decrypt). We will include the ciphertext metadata; we will preserve the underlying ciphertext for the required period; we will respond to lawful production demands directed at the parent for the key.

We file under 18 U.S.C. § 2258A(a)(1)(A); we do not under § 2258A(f) generally monitor or affirmatively search user communications for CSAM, and § 2258A does not require us to — but where we have actual knowledge, the report is mandatory.

8.2 European Union

Under the EU's existing CSAM regime (Regulation (EU) 2021/1232 "Interim Regulation" insofar as still in force in 2026, and the EU CSAE Regulation proposal where it has been adopted by the date of these Standards), we report to the competent EU authority (the EU Centre under the new Regulation, or the national hotline under the Interim Regulation) on the same basis as Section 8.1: as soon as reasonably practicable after actual knowledge, with the metadata available to us, and with a written explanation that proof media is end-to-end encrypted and that plaintext is not available from us. We cooperate with INHOPE-member hotlines in each EU member state where the user is located.

8.3 United Kingdom

We notify the Internet Watch Foundation (IWF) for UK-located reports of CSAM, and we cooperate with Ofcom under the Online Safety Act 2023 to the extent the OSA's scope applies to Balance (we are not a category-1 service; Balance is not a user-to-user service for OSA purposes because it has no multi-user surface — but the CSAE provisions of the OSA apply to providers in scope, and we apply them voluntarily for symmetry across regions).

8.4 Australia

We notify the eSafety Commissioner in line with the Online Safety Act 2021 (Cth) and applicable industry codes/standards.

8.5 Other countries

We file with the national hotline that is a member of INHOPE or the equivalent national child-protection mechanism. For the additional countries where Balance launches, the first-line national routes are: Brazil — the SaferNet Brasil hotline and Disque 100 (ECA arts 240–241-E); India — reporting under the POCSO Act 2012 and the IT Rules, with the NCMEC CyberTipline route where U.S. jurisdiction attaches; Indonesia — the Komdigi content-reporting channel and KPAI; South Korea — the Korea Communications Standards Commission (KCSC) and police 112; Japan — the Internet Hotline Center Japan; South Africa — the Film and Publication Board hotline and SAPS; Kenya — Childline Kenya 116 and the DCI; Egypt — the Child Helpline 16000. The country annex for each country carries the detail. The country-by-country list of hotline contacts is maintained in our internal CSAE Country Routing Table, reviewed at every annual review (Section 11). The current published version is referenced in the country annex set at child-safety.html.

8.6 Where the reporter is also a public-authority requester

If a national authority requests preserved data directly, we apply our standard production rules: we comply with a properly-issued, lawful production order; we challenge requests that exceed legal authority; we are transparent in the annual report (Section 11) about the number, type, and outcome of such requests, to the extent the law allows us to publish those figures.

9. CSAE Incident Response Protocol — internal commitments

In addition to the report-triage workflow in Section 7, we commit internally to the following operational invariants. The Child Safety Officer (Section 2) is responsible for each.

• Preservation hold on relevant data within one business day of classification (a)–(d).
• No tip-off to a suspect: investigation-related communications never go to the suspect account.
• No retaliatory action against a reporter who acted in good faith — including no removal of the reporter's account, no contractual penalty, no civil claim.
• Continuity of evidence: the Officer signs the chain-of-custody record for every preserved object.
• No plaintext reconstruction: we will not attempt to break, defeat, or work around the end-to-end encryption that protects proof media. We will not retain a master key, a backdoor, or any other means by which we could ourselves decrypt the kid's proof media. The trade-off this implies for child-safety investigations is one we accept as the privacy-by-design baseline — and it is one we have publicly disclosed in our Privacy Policy (Section 9) and in our Children's Privacy Notice (Section 4.3). Where law enforcement needs the plaintext, the only lawful route is a properly-issued production order directed at the parent (the key-holder); we will cooperate in identifying and serving that route.
• Annual external review of the protocol — see Section 11.

10. Cooperation with national hotlines and law enforcement

We work with national child-safety hotlines and law-enforcement bodies on the model of cooperation rather than automatic disclosure. Concretely:

• We receive reports from a national hotline via or via the EU/UK representative. Each hotline that wishes a faster channel can request a dedicated email alias (e.g., a +ncmec@, +iwf@ alias to the same mailbox).
• We file reports with the national hotline that operates under a memorandum-of-understanding with us. NCMEC (US), IWF (UK), Safernet (BR), and INHOPE members in each EU member state are the default first-line contacts.
• We respond to lawful production demands within statutory deadlines, with the constraints noted in Section 9 about plaintext.
• We do not voluntarily disclose user data to any authority outside the lawful-process route.
• We publish numerical disclosures about the volume of reports we send and receive in the annual transparency report (Section 11).

We do not engage in: - bulk content scanning of plaintext (because we have no plaintext to scan — Section 3, Section 5.3); - the introduction of any backdoor, key-escrow, or sub-rosa key-disclosure mechanism into the Balance encryption design; - the sale, lease, or sharing of user data with any commercial intelligence service.

11. Annual review, transparency report, and updates to this Standard

The Child Safety Officer (Section 2) reviews this Standard at least once a year, by 9 June each year, and after any material change to the Balance product surface, the sub-processor list, or the law of a country. The review covers:

• the inventory of in-app surfaces (Section 3) — confirming no new multi-user surface has been introduced;
• the CSAE Country Routing Table (Section 8.5) — confirming each hotline contact is current;
• the in-app reporting flow (Section 6) — confirming click-paths still resolve;
• the incident-response workflow (Section 7) — confirming end-to-end run-throughs work;
• the engagement with national authorities (Section 10) — confirming MoUs and aliases are current.

After every annual review, we publish a Transparency Report at child-safety.html alongside this Standard. The Report contains, for the preceding 12 months:

• the number of CSAE reports received through each channel;
• the number of CSAE reports filed with each national hotline;
• the number of lawful production demands received from public authorities, by country and by type, to the extent the law allows publication;
• the number of accounts suspended for material breach of the conduct rules in Section 4;
• the average acknowledgement time for reports;
• a narrative section reflecting on lessons learned and changes made.

The first Transparency Report is due by 9 June 2027.

Material updates to this Standard are notified in-app at next launch, by email to the parent on the account, and through an updated "Last updated" date and a section-by-section diff on the public page. Non-material updates (typo fixes, minor clarifications, URL changes) are made silently with a date update.

12. How parents and kids can ask for help

If you are reading this Standard because something has happened in your family that you do not know how to handle, please reach out — even if you are not sure whether what you have observed counts as a Balance issue, a parent-side issue, or a wider safety issue. Our Child Safety Officer is the right person to triage it.

• Email: ().
• Phone: .
• For families in the EU/EEA, you may also reach us through our EU representative Prighter at Schellinggasse 3, 1010 Vienna, Austria.
• For families in the UK, you may also reach us through our UK representative Prighter at 20 Mortlake High Street, London SW14 8JN, United Kingdom.

Many countries also offer independent child-safety helplines outside of any specific app. We list the most-used in our country annex set, including the U.S. NCMEC CyberTipline (1-800-843-5678; https://report.cybertipline.org), the UK Childline (0800 1111; https://www.childline.org.uk), the EU 116 111 child helpline family, and the equivalent national lines in every other country. We strongly encourage parents to use these helplines for situations that are broader than the Balance Service.

13. Country annexes

Country-specific child-safety reporting routes, hotline contacts, and any country-specific procedural rules are published in the country annex set that travels with this Standard at child-safety.html. The annex set covers:

• United States (NCMEC CyberTipline + state attorneys-general).
• United Kingdom (Internet Watch Foundation + Childline + Ofcom under the Online Safety Act 2023).
• All 27 EU member states + Iceland, Liechtenstein, Norway (INHOPE-member national hotlines + EU CSAE Centre once operational).
• Argentina, Chile, Colombia, Peru, Uruguay.
• Canada, Australia, New Zealand, Singapore, Philippines, Israel, Hong Kong (SAR), Malaysia, Thailand, Taiwan.
• Andorra, Monaco, San Marino.
• Brazil, India, Indonesia, Pakistan, Bangladesh, Mexico, Japan, Egypt, Türkiye, Tanzania, South Africa, Kenya, South Korea.

Inherited territories follow the parent-country annex (consistent with Section 18 of the Privacy Policy and Section 14 of the Children's Privacy Notice).

14. Quick-reference contacts

• CSAE reports and child-safety enquiries: ( — Designated Child Safety Officer)
• Privacy / DSAR / data export / deletion: (also )
• General help:
• EU representative: Prighter EU Rep GmbH, Schellinggasse 3, 1010 Vienna, Austria
• UK representative: Prighter Ltd (UK), 20 Mortlake High Street, London SW14 8JN, United Kingdom
• Postal: BabaYaga Program, TOO, ul. Ongarsynova 10, kv. 175, Esil district, Astana 010000, Kazakhstan
• Telephone:
• Companion documents:
• Privacy Policy: privacy.html
• Children's Privacy Notice: children.html
• Terms of Service: terms.html
• Subscription Terms: subscription-terms.html

End of Child Safety Standards.