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), so your data can never be intercepted 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.

Pseudonymisation

The primary database never stores real names in entity tables. Instead, each child, character, and place is recorded under a non-identifying pseudonym (e.g. “Profile_a7f2b3c1”). The real name exists only in an isolated, encrypted mapping and is decrypted solely when it needs to be shown to the authenticated parent. Names appear only as pseudonyms in log output, are never cached in plaintext on-device, and are never included in error reports.

Hashed lookups

When we need to match or deduplicate names, we use a one-way SHA-256 hash of the normalised name. This allows operations like uniqueness checks without ever decrypting or exposing the plaintext.

AI name isolation

When generating stories through AI, we apply a three-stage tokenisation pipeline so that real names never reach any 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 at display time on your device.

No voice storage

Audio from a child’s microphone is streamed for real-time processing and never recorded, saved, or persisted by Story Gliders. Once our speech provider returns results (such as pronunciation scores), the audio is discarded immediately. No recordings exist on our servers.

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. Automated scripts scan client bundles to ensure no secrets are accidentally shipped.
• 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 tracking scripts: we do not load analytics trackers, advertising scripts, or third-party beacons. This eliminates an entire category of supply-chain risk and reduces the attack surface of the application.

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 pseudonyms 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: ISO 27001 and SOC 2 certified. Audio is processed transiently and not retained by Microsoft after processing. We have not opted in to human review of audio data.
• Anthropic (Claude): SOC 2 certified. API data is not used to train models. Inputs and outputs may be retained for up to 30 days for trust and safety purposes only.
• OpenAI: SOC 2 certified. API data is not used to train models. Inputs and outputs are retained for up to 30 days for trust and safety monitoring only.

All processors are bound by data processing agreements that include confidentiality and security obligations. We share only the minimum data necessary — real names are never sent to any third-party service. See our Privacy Policy Section 12 for full details on each provider.

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, eliminating contact-related risks entirely.
• 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 eliminates 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: pronunciation scores and practice history are stored in the browser’s local storage and never leave the device unless explicitly synced.

6. Secure development practices

• Code review: all changes are reviewed before reaching production.
• Secret scanning: automated checks prevent accidental exposure of API keys or encryption secrets in client-side code.
• Dependency auditing: we regularly audit third-party packages for known vulnerabilities and apply updates promptly.
• 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 will notify affected users and relevant supervisory authorities within the timeframes required by applicable law (72 hours under GDPR; without unreasonable delay under other frameworks).
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 security@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 within 48 hours.
• 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.
• GDPR / UK GDPR: data protection by design and by default, lawful processing bases, data protection impact assessments, and breach notification obligations.
• UK Age Appropriate Design Code: 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: security@storygliders.com
• Privacy questions: privacy@storygliders.com
• General support: support@storygliders.com