← Back to Jogg Mini
SECURITY

Security — Jogg Mini

by MokingBird
Security Document | MokingBird

Status: Implementation-aware public document Product: Jogg Mini Operated by: MokingBird Oy ("Mokingbird") Last Updated: July 19, 2026

1. Security Philosophy

Jogg Mini follows a practical layered-security model built around:

2. Security Architecture: Four Layers

┌─────────────────────────────────────────────────────┐
│  Layer 4: CLOUD SECURITY                            │
│  (Supabase RLS and role-scoped access controls)      │
├─────────────────────────────────────────────────────┤
│  Layer 3: TRANSMISSION SECURITY                     │
│  (HTTPS/TLS transport and PKCE OAuth where used)     │
├─────────────────────────────────────────────────────┤
│  Layer 2: DATA ENCRYPTION                           │
│  (Layered local storage and hashed PIN flows)        │
├─────────────────────────────────────────────────────┤
│  Layer 1: DEVICE SECURITY                           │
│  (PINs/locks, biometrics, session timeout)           │
└─────────────────────────────────────────────────────┘

3. Layer 1: Device Security

PIN-Based Access Controls

Jogg Mini implements account/device protection with PIN/lock flows:

| PIN Type | Length | Storage | Purpose | |----------|--------|---------|---------| | App PIN (optional) | 4 digits | Device-side secure storage | Lock app access on shared devices | | Parent PIN | 6 digits (where enabled) | Hashed in backend (Supabase) | Protect parental dashboard and sensitive settings | | Teacher PIN (optional) | 4 digits | Device-side secure storage | Protect teacher profile access on shared devices |

PIN hashing: Parent PIN values are hashed before backend storage in PIN-enabled account flows. Local device-side parent lock secrets use Flutter Secure Storage (backed by iOS Keychain and Android Keystore).

Biometric Authentication

Jogg Mini supports optional Touch ID and Face ID (or equivalent device biometrics) as an alternative to the app PIN. Biometric data is handled entirely by the device operating system (iOS Secure Enclave, Android Keystore) — Jogg Mini never accesses or stores biometric data.

Device Integrity

Device integrity hardening (including jailbreak/root detection) may be introduced or enabled per release. This document does not treat it as a guaranteed always-on control across all builds.

Auto-Lock and Session Timeout

The app automatically locks the parent dashboard after a configurable idle period, requiring PIN or biometric re-authentication. This prevents unauthorised access when a device is left unattended.

Secure Key Storage

Authentication tokens and sensitive device-side secrets are stored using:

4. Layer 2: Data Encryption

Local Data Protection (Hive and Other Local Storage)

Jogg Mini operates offline-first. Local data is stored using layered local storage mechanisms. Sensitive secrets are protected with secure storage, while other app data uses standard local storage/caching layers appropriate to sensitivity.

Important Distinction: Storage Tiers

Not all local data is treated identically. Jogg Mini uses different local storage layers:

| Data Type | Storage Layer | Sensitivity | |-----------|---------------|------------| | General app preferences, onboarding state | SharedPreferences / local prefs | Low | | Offline progress, question cache | Hive/local cache (protection varies by build) | Medium | | Parent/teacher lock secrets, auth tokens | Flutter Secure Storage (Keychain/Keystore) | High |

We describe Jogg Mini as using layered local-storage practices rather than claiming all local values are stored in the same way. Sensitive secrets use secure storage; general preferences use standard app storage.

File and Report Protection

Export/report handling follows platform and application-level protection controls available in the active build. Protection details can vary by feature and deployment.

5. Layer 3: Transmission Security

HTTPS/TLS Transport

Communication between Jogg Mini clients and backend services uses encrypted HTTPS/TLS transport provided by platform networking stacks and backend endpoints.

Certificate Pinning Position

Certificate pinning is not treated in this document as a universal, guaranteed control across all builds/environments.

JWT Token Management and PKCE

Authentication uses JWT tokens with automatic refresh via PKCE (Proof Key for Code Exchange) OAuth flow:

6. Layer 4: Cloud Security

Supabase PostgreSQL

All user data is stored on Supabase (PostgreSQL 15), hosted in the European Union. Supabase has a Data Processing Agreement (DPA) with MokingBird Oy.

Row-Level Security (RLS)

PostgreSQL Row-Level Security ensures every database query is automatically scoped to the authenticated user's data. No user can access another user's data through the API.

Example RLS policy:

-- Parents can only read their own kids' profiles
CREATE POLICY "parents_see_own_kids"
  ON kid_profiles FOR SELECT
  USING (parent_id IN (
    SELECT id FROM parent_profiles
    WHERE user_id = auth.uid()
  ));

Role Separation at the Backend

Access is separated by role:

Backups and Operational Logging

Backup and operational logging controls are provided through backend infrastructure and application operations as configured. Exact backup cadence/retention and log implementation can vary by environment and deployment stage.

7. Authentication Security

Age-Based Authentication Model

| User | Authentication | |------|---------------| | Child <13 | No login — parent selects child profile | | Teen 13–15 | Google or Apple Sign-In (OAuth PKCE) | | Parent | Google or Apple provider identity (Supabase Auth session) | | Teacher | Google or Apple provider identity (Supabase Auth session) | | Guest | No authentication — local session only |

Parent PIN Flow

Parent PIN-enabled account flows use hashed backend PIN storage:

OAuth Security

OAuth sign-ins use the PKCE flow, which:

8. Children's Data Protections

Given that Jogg Mini primarily serves children, we implement additional protections:

9. Quiz and Classroom Security

Teacher and organiser quiz flows use controlled join mechanisms:

10. Analytics and Diagnostics

Jogg Mini may include analytics and diagnostics tooling depending on deployment:

11. Data Deletion and Account Control

Security includes authenticated user control and an explicit deletion design. Child-profile deletion controls exist in parent surfaces, while the complete idempotent deletion worker, parent/teacher/hybrid account purge, provider disconnect, export warning and retention evidence can be seen in https://joggmini.mokingbird.xyz/delete. Logout ends the current Supabase session; the product must not claim global session revocation unless the backend confirms it.

12. Implementation Notes and Honest Boundaries

We describe security as it is implemented, not aspirationally. Current implementation notes:

These distinctions are intentional and reflect a risk-proportionate approach to storage security.

13. Security Roadmap

Mokingbird's technical roadmap includes continued hardening:

14. Third-Party Security Compliance

| Provider Category | Security Reference | |----------|-----------------| | Supabase | Provider-published security/compliance materials (for example SOC and DPA documentation) | | Billing providers (where used) | Provider-published payment/security compliance materials | | Analytics/diagnostics providers (if enabled) | Provider-published security/privacy documentation |

15. Reporting Security Issues

To report a security vulnerability or concern:

Email: [email protected]

We take all security reports seriously and aim to respond within 48 hours. We follow responsible disclosure practices and will not take legal action against researchers acting in good faith.

Mokingbird (MokingBird Oy) — Security Document v1.3 — July 2026

Published by MokingBird Oy.