← Back to Jogg
Security

Security Overview — Jogg

MokingBird | Developed by MokingBird Oy Last Reviewed: June 24, 2026

This document describes Jogg's security posture based on the implemented application code and current integration design.

It is intended for:

1. Security Positioning

Jogg is a learning application with account, progress, quiz, and content features. Security in Jogg is focused on:

2. Security Architecture — Four Layers

Jogg uses a four-layer security model that protects data at every stage.

┌────────────────────────────────────────────────────┐
│  LAYER 1: DEVICE SECURITY                          │
│  Biometric auth · Secure storage · App sandboxing  │
└────────────────────────────────────────────────────┘
                        ↓
┌────────────────────────────────────────────────────┐
│  LAYER 2: DATA ENCRYPTION                          │
│  AES-256-GCM local DB · PBKDF2 key derivation      │
│  RSA-2048 key utilities · Secure key storage       │
└────────────────────────────────────────────────────┘
                        ↓
┌────────────────────────────────────────────────────┐
│  LAYER 3: TRANSMISSION SECURITY                    │
│  TLS in transit · OAuth 2.0 + PKCE where configured                 │
└────────────────────────────────────────────────────┘
                        ↓
┌────────────────────────────────────────────────────┐
│  LAYER 4: CLOUD AND BACKEND SECURITY               │
│  Supabase Row Level Security · User-isolated data  │
│  Authenticated-user-only data access               │
└────────────────────────────────────────────────────┘

3. Implemented Security Controls

3.1 Authentication Infrastructure

Jogg uses Supabase-backed authentication for account and session handling.

Supported sign-in methods:

The app distinguishes between:

3.2 Route and Session Protection

Jogg uses route guards to restrict access to protected screens and flows:

3.3 Local Storage Encryption

Jogg uses encrypted local storage (Hive) for important app data.

The implementation includes:

Encryption keys are generated and persisted through platform secure-storage mechanisms rather than being stored in ordinary app files. Keys necessarily enter process memory while cryptographic operations execute.

3.4 Cryptographic Utilities

The codebase includes a dedicated encryption service with:

3.5 Token Management

Jogg uses a two-token session model:

Tokens are invalidated on logout. Sessions can be managed and revoked from the app's settings.

3.6 Optional User Device Security

Jogg includes user-facing security settings:

Biometric availability and fallback behavior depend on the device operating system; users can select the Jogg PIN option instead.

3.7 Data Portability and User Control

Jogg includes:

The account deletion path removes the authenticated Supabase account, not only local UI state.

3.8 Leaderboard Privacy Controls

Leaderboard participation is opt-in. Users are not placed in public rankings by default.

The app includes separate toggles controlling which leaderboard-related information is shared (XP, streak, quiz metrics). Users can withdraw from the leaderboard at any time.

3.9 Notification Permission Control

Users explicitly control:

3.10 Shared Quiz Identity and RPC Boundaries

Waiting-room membership is stored in Supabase and protected by RLS. Cross-user display-name access is not granted through a broad profile policy; quiz-scoped security-definer RPCs expose only the labels and organizer data required for the relevant quiz. Joined-quiz membership survives device-local cache clearing. Organizer-only attendant/result RPCs verify quiz ownership before returning cross-user data.

3.11 Certificates and Public Verification

Certificate issuance is performed through an eligibility RPC rather than arbitrary client inserts. Public certificate verification uses a restricted verification RPC and certificate code. A public website verification page is still a deployment task; the app and database support verification, but website availability must be confirmed separately.

4. Backend and Data Access Model

Jogg relies on Supabase for backend services and database access.

Security measures at the backend layer include:

5. Security Around Quiz and Sharing Features

Jogg includes multiple quiz and sharing surfaces:

Security-relevant controls include:

6. Privacy-Preserving Analytics

The privacy design supports pseudonymous question-performance analytics using one-way identifiers when that analytics pipeline is enabled. The intended controls are:

7. Threat Model

ThreatMitigation
Unauthorised account accessOAuth 2.0 + PKCE, biometric option, rate limiting
Data theft from deviceAES-256-GCM local encryption, keys in Keychain/Keystore
Man-in-the-middle attackPlatform TLS validation; certificate pinning remains a pre-launch decision
Cross-user data accessSupabase Row Level Security at DB layer
Session hijackingShort-lived session tokens and provider-managed session controls
Lost or stolen deviceBiometric gate + remote session revocation
Fake quiz or share abuseAccount-bound ownership, authenticated access paths

Residual risks (accepted):

8. Current Security Strengths

Based on the implementation, the strongest current security strengths are:

  1. Account-based authentication with multiple sign-in options,
  2. Explicit guest-versus-authenticated separation,
  3. AES-256-GCM encrypted local app storage,
  4. Secure local key storage (Keychain/Keystore),
  5. Optional biometric and PIN app lock,
  6. Real backend account deletion (not cosmetic),
  7. User data export and deletion support,
  8. Opt-in public leaderboard model with granular sharing controls,
  9. Privacy-preserving anonymous analytics design,
  10. Security-aware environment configuration structure.

9. Areas Being Finalised for Production

Some security-related areas are scaffolded or in progress, not yet fully deployed. We are transparent about this:

Public security messaging should accurately reflect what is deployed versus what is in progress.

10. Pre-Launch Security Checklist

Before full public launch, the following items should be confirmed:

  1. [ ] Receipt validation for paid flows,
  2. [ ] Final production certificate-pinning configuration,
  3. [ ] Production secret and environment review (no hardcoded credentials),
  4. [ ] Supabase RLS policy review and audit,
  5. [ ] Account deletion flow end-to-end verification,
  6. [ ] Data export flow verification,
  7. [ ] Notification permission behaviour review,
  8. [ ] OAuth redirect and callback review,
  9. [ ] Backup integration security review (when backup rollout is enabled),
  10. [ ] Final alignment between legal policy documents and actual telemetry and backend behaviour.

11. Responsible Disclosure

To report a security vulnerability in Jogg, please contact:

MokingBird Oy Email: [email protected] Subject: "Security — Jogg" website https://jogg.mokingbird.xyz

We ask that you practice responsible disclosure and give us reasonable time to investigate and address the issue before any public disclosure.

12. Plain-Language Summary

Jogg uses Supabase-backed authentication, AES-256-GCM encrypted local storage, secure device-backed key handling, optional PIN and biometric protection, privacy-aware opt-in leaderboard controls, and in-app export and deletion tools.

Some advanced infrastructure — including payment verification and certain monitoring integrations — is being finalised as part of production rollout.

MokingBird Oy — Security overview current as of April 2026. Updated as the platform evolves.

Published by MokingBird Oy.