Security & Trust Overview

EEZ SECURITY & TRUST OVERVIEW — Version 3.1
This describes product/security principles; it is not a guarantee that any system is invulnerable.

Employee-first privacy

EEZ is designed around workers rather than employer surveillance. Private earnings and Employment-scoped information are not automatically exposed to coworkers or employers.

Server-side authorization

Sensitive operations are designed to be enforced on the server, including personal storage, earnings/financial preferences, team/messaging actions, schedule publication, block/report enforcement, account deletion, and subscription ownership.

Employment isolation

Schedule and earnings state is scoped to the appropriate Employment so one job does not silently expose another job's data.

Shared schedule revisions

Schedule Group publication uses revision-aware updates to reduce stale overwrites. Manual user edits to their own shared Employment schedule carry provenance and may propagate to all Schedule Groups currently sharing that Employment.

Messaging safety

EEZ supports block/unblock and reporting. Blocks are enforced across applicable direct-interaction paths and relevant push delivery. Reports use bounded categories/references and do not automatically suspend users.

Authentication

EEZ supports Sign in with Apple and may support additional authentication methods. Authentication and session state use server-side validation and bounded challenge/session handling.

Secrets

Production secrets belong in secure server configuration, not shipped client code. Release builds should exclude staging/operator credentials and local StoreKit configuration.

Rate limits and abuse controls

EEZ uses bounded request/message/report limits and authorization checks intended to reduce automated abuse and resource exhaustion.

Subscriptions

The client does not locally invent paid access. Server-side purchase/lifecycle state controls authoritative entitlement projection.

Account deletion

Deletion revokes access, coordinates server cleanup, clears local account state, and preserves only limited shared/safety/security/purchase-lineage records where necessary.

Diagnostics

Diagnostics should be bounded and sanitized. Secrets, tokens, private keys, authorization codes, full signed payloads, and unnecessary private content should not be logged.

Recovery

Backend changes involving durable state should use append-only migrations and migration-compatible recovery rather than destructive rollback assumptions.

No absolute guarantee

No software or cloud service can guarantee perfect security, availability, or accuracy.