Security

1. Data protection

We apply multiple layers of protection to ensure that personal information — especially children’s names — remains secure even in the unlikely event of a data breach.

Encryption in transit

All communication between your browser and our servers is encrypted using TLS 1.2 or higher. HTTPS is enforced on every connection with HTTP Strict Transport Security (HSTS), which is designed to protect your data against interception in transit.

Encryption at rest

Children’s real display names, character names, and place names are encrypted using AES-256-GCM (authenticated encryption with a 256-bit key). Each name entry has its own random initialisation vector and authentication tag. The encryption key is held separately from the database, so database access alone cannot reveal names.

Name protection

A child’s, character’s, or place’s real name is stored as AES-256-GCM ciphertext directly in its database record — the plaintext name is never written to the database. A separate, natural-sounding privacy alias is stored alongside it in its own column and is the only name used for AI content generation. Real names are decrypted server-side only when they need to be shown to an authenticated parent. Names appear only as encrypted ciphertext in log output and are never included in error reports. Personalised story titles shown in your child’s reading history may contain a first name and are cached in your browser’s local storage to power offline progress views; this on-device cache is cleared automatically when you sign out, and you can clear it at any time from your browser settings.

Hashed email lookups

For account uniqueness and invitation matching, we store a one-way keyed hash (HMAC-SHA-256) of the normalised email address rather than the plaintext, so duplicate accounts and invitations can be matched without exposing the email. Names themselves are protected by AES-256-GCM encryption rather than hashing; where we need to de-duplicate names, that is done server-side for the authenticated family.

AI name isolation

When generating stories through AI, we apply a three-stage tokenisation pipeline so that a child’s name and their chosen character names are replaced with aliases before any prompt reaches an AI provider:

1. Aliasing: real names are replaced with natural-sounding fictional aliases before any prompt is sent.
2. Tokenisation: after the AI returns text, aliases are replaced with opaque entity tokens for storage.
3. Resolution: tokens are resolved back to real names only within your authenticated session — in your browser, or server-side for an authorised parent or tutor request — so the stored story text itself never contains real names.

Free-text you enter yourself — such as place descriptions, story problems, quests, or notes — is sent to the AI as you typed it. We replace the child’s name and chosen character names with aliases, but we cannot detect other people’s names typed into free-text fields, so please avoid entering real names there.

No voice storage

Voice features work in one of two ways. For live word-by-word reading tracking, audio is streamed directly from the browser to our speech provider and never reaches our servers. For pronunciation scoring and spoken-comprehension answers, a short recording is sent to our servers, held only in memory for that single request, forwarded to our speech provider, and then discarded. In neither case is any audio recording written to disk or stored in our database — no audio recordings are retained on our servers. We also do not perform speaker recognition or voice identification, and we never create, derive, or store a voiceprint or any other biometric voice template.

2. Application security

• Server-side secret management: all API keys and encryption keys are stored as server-side environment variables and are never exposed to the browser. An automated check scans our client bundles for accidentally exposed secrets and surfaces any matches in continuous integration.
• Input validation: all API inputs are validated and sanitised on the server before processing.
• Rate limiting: sensitive endpoints (such as speech-service token minting) are rate-limited to prevent abuse.
• Security headers: we enforce HTTP security headers including Content Security Policy, Strict Transport Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy to protect against common web vulnerabilities.
• No advertising or analytics trackers: we do not load analytics trackers, advertising scripts, or behavioural-tracking beacons. The only third-party browser script we load is Cloudflare Turnstile, a privacy-preserving bot-protection check used on our public sign-in, sign-up, and waitlist forms; it is not used for advertising or cross-site tracking. Keeping our third-party script footprint this small reduces our supply-chain attack surface.

3. Infrastructure

• Environment isolation: development, staging, and production environments are fully separated with distinct credentials and databases.
• Least-privilege access: access to production systems and databases is restricted to the minimum set of personnel required, using role-based access controls.
• Secure logging: application logs are monitored for anomalies but never contain children’s real names or other personal identifiers. Names appear only as encrypted ciphertext in log output.
• Database security: database connections are encrypted, network access is restricted, and regular backups are maintained.

4. Third-party security

We work with a small number of carefully selected providers. Each undergoes a security and privacy review before integration. Our current providers:

• Microsoft Azure Speech Services: speech-to-text, pronunciation assessment, and text-to-speech. Audio is processed transiently and, under Microsoft’s terms, not retained after processing. We have not opted in to human review of audio data.
• Anthropic (Claude): story and narrative generation. API data is not used to train models, and inputs and outputs may be retained for a limited period for trust-and-safety purposes only.
• OpenAI: illustrations, quizzes, content moderation, and fallback story generation. API data is not used to train models, and inputs and outputs may be retained for a limited period for trust-and-safety monitoring only.
• Cloudflare (Turnstile): a privacy-preserving bot-protection check on our public forms. We send the challenge response and the requester’s IP address for verification; no child profile data is sent.

Our providers maintain recognised security certifications (for example, Microsoft and Anthropic publish SOC 2 reports); see each provider’s trust page for current status. Processors that handle personal data are bound by data processing agreements that include confidentiality and security obligations, and we share only the minimum data necessary. A child’s real name is never sent to our AI content-generation providers (Anthropic and OpenAI); the child’s first name may appear in story text sent to Azure Speech Services and as a parameter in progress emails sent via Brevo. See our Privacy Policy Section 12 for the complete list of providers and the data shared with each.

5. Children’s safety

Because our users include children, we apply additional safeguards beyond standard application security:

• Parental gatekeeping: every child profile must be created and managed by a parent or legal guardian. Children never interact with account management or registration.
• No social features: there is no chat, messaging, or child-to-child interaction of any kind, which removes a major category of contact-related risk.
• Content safety: AI-generated stories are moderated for age-appropriateness. Prompts include safety guardrails to prevent unsuitable content from being generated.
• No advertising: the absence of ads avoids risks associated with ad tracking, malvertising, and inappropriate content served through ad networks.
• Data minimisation: we collect only what is needed for the reading experience. We encourage nicknames rather than legal names, and age is optional and approximate.
• Device-local data: some reading data — such as reading preferences and recent paragraph-level pronunciation scores — is cached in the browser’s local storage for fast, offline-friendly progress views, and is also automatically synchronised to our servers so progress is preserved across devices. Word-by-word practice history is stored only on our servers. See our Privacy Policy (Sections 8 and 11) for retention details.

6. Secure development practices

• Code review: all changes are reviewed before reaching production.
• Secret scanning: automated checks (including gitleaks and a client-bundle scanner) run in our CI pipeline to detect and alert on accidental exposure of API keys or encryption secrets.
• Dependency auditing: automated tooling (weekly Dependabot updates and dependency review on pull requests) flags third-party packages with known vulnerabilities, which we review and update as part of our normal workflow.
• Privacy by design: security and privacy considerations are part of the design process for every feature, not bolted on afterwards.

7. Incident response

In the event of a security incident, we follow a structured response process:

1. Detection and containment: we monitor for unusual activity and move immediately to isolate affected systems.
2. Assessment: we determine the scope, cause, and potential impact of the incident.
3. Notification: we notify the relevant regulator and affected individuals of a qualifying personal-data breach within the timeframes required by applicable law (for example, the breach-reporting requirements under Canada’s PIPEDA and Quebec’s Law 25, and Australia’s Notifiable Data Breaches scheme), notifying affected users without undue delay where a breach is likely to result in a real risk of significant harm.
4. Remediation: we address the root cause and implement measures to prevent recurrence.
5. Post-incident review: every incident is followed by a thorough review, and lessons learned are incorporated into our security practices.

8. Responsible disclosure

We welcome and appreciate reports from security researchers. If you believe you have found a vulnerability in Story Gliders, please let us know so we can address it promptly.

How to report

Email contact@storygliders.com with a description of the issue, steps to reproduce, and the potential impact. Please include any supporting evidence (screenshots, logs, proof of concept) that can help us understand and reproduce the issue.

Our commitment

• We will acknowledge your report promptly, typically within a few business days.
• We will provide regular updates on the status of your report.
• We will resolve critical vulnerabilities as quickly as possible.
• We will not take legal action against researchers who report vulnerabilities in good faith and follow responsible disclosure practices.
• With your permission, we are happy to acknowledge your contribution.

Out of scope

The following are not in scope for our responsible disclosure programme: social engineering or phishing attacks against our staff or users, denial-of-service attacks, physical security testing, and attacks against third-party services we use.

9. Compliance

Our security programme is designed to support compliance with the data protection frameworks applicable to our users:

• PIPEDA (Canada): consent-based collection and use, access and correction rights.
• Quebec Law 25 (Canada): privacy by default, a designated privacy officer, breach record-keeping and reporting, and privacy impact assessments where processing is likely to result in a high risk.
• Age-appropriate design for children: privacy protections designed specifically for child users, including data minimisation, no profiling, and transparency.
• CCPA/CPRA (California): no sale of personal information, consumer rights to access and deletion.
• Australian Privacy Act: compliance with the Australian Privacy Principles (APPs).
• COPPA (U.S.): verifiable parental consent, data minimisation, and restrictions on collection from children under 13.

For full details on your rights under these frameworks, see our Privacy Policy.

10. Changes to this page

We may update this security page as our practices evolve. We will revise the “Last updated” date at the top when changes are made. For material changes to our security posture, we will notify users through the parent portal.

11. Contact

If you have questions about our security practices or want to report a concern:

• Security reports: contact@storygliders.com
• Privacy questions: contact@storygliders.com
• General support: contact@storygliders.com

Story Gliders Inc., 430 Wickstead Avenue, North Bay, Ontario P1A 3H1, Canada. Telephone: +1 647-269-3625.