Yuvomi-App/SECURITY.md

Security policy — native rebuild

The current native client is an incomplete development preview, not an audited release or full PWA replacement. See native parity.

Report vulnerabilities privately to the repository owner through an established private channel. No reporting mailbox has been provided; do not invent one or put cookies, keys, household records or exploit details into public issues. Upstream server vulnerabilities belong in its private reporting channel.

Current native security model

• Native Compose/SwiftUI screens call one configured HTTPS origin. System TLS validation is mandatory and API redirects are refused. No WebView/WKWebView is shipped as the app surface or used as a missing-feature fallback.
• Passwords and second-factor codes exist transiently for the API request; they are not saved to preferences, keychains, logs, artifacts or application state restoration. Server cookies, not passwords, persist the session.
• Android treats every allow-listed native cookie as HTTPS-only, bound to the configured origin/port. This also applies when upstream omits the Secure attribute (SESSION_SECURE=false is upstream's default); no HTTP transport is enabled. Persistent cookies retain their absolute expiry in AES-GCM ciphertext backed by AndroidKeyStore, with the origin authenticated as additional data. iOS uses a private ephemeral URLSession jar and origin-scoped Keychain items protected with WhenUnlockedThisDeviceOnly.
• CSRF tokens follow the upstream API protocol. Only an explicit csrf_invalid rejection allows one refresh/retry. Other permission errors or ambiguous network failures never cause automatic mutation replay. The server remains authoritative for authorization, recurrence, reward accounting and cross-module rules.
• Reads are bounded and timed out. There is no offline mutation queue or native remote push implementation. Missing features are documented, not simulated.
• Logout attempts remote revocation and clears the native local session. Local server removal is not remote revocation. Old prototype WebKit data is not imported; use OS app-data removal/reinstall to erase that legacy installation.
• Android screenshots are blocked. The iOS view is obscured while inactive. The Android integration test temporarily permits a screenshot only of its synthetic private fixture, restores the restriction and never uses real household data.
• The owner-authorized initial signing key is backed up outside the repository. Four repository signing secrets exist, but signing/release changes are parked during the native rebuild. No private key belongs in Git or downloadable CI artifacts. Protect trusted-branch write access and isolate persistent runners.

Mandatory gates

Native transports, secure storage, session erasure, actual Apple SDK compilation, real-device behavior, accessibility, supported authentication flows and dependency resolution need review and evidence before release. OIDC, file transfers, offline storage and the remaining modules are not implemented native capabilities yet. Advisory scans and parser/unit checks are not a guarantee that code is secure.

The superseded prototype policy is retained below as historical context only; it must not be used to claim capabilities of the native rebuild.

---

Historical WebView prototype policy

Development software: no production-readiness claim. Only the current development branch is maintained; no stable mobile release exists yet.

Do not post vulnerabilities, cookies, private URLs, household records or keys in a public issue. Contact the community repository's owner through an established private channel or enable the host's private vulnerability-reporting mechanism before public distribution. No private reporting mailbox has been supplied; we will not invent one. If none is available, request a private contact without including exploit details. Upstream Yuvomi vulnerabilities belong in upstream's private reporting channel, not its public issue tracker. This project cannot promise upstream response times.

Include affected app/OS/WebView/server versions, reproduction steps, impact, and a minimal sanitized demonstration. Never include real credentials.

Security model

• The user selects one HTTPS origin, including its port. A valid TLS chain is required. No certificate-error bypass, HTTP production mode, or custom scheme handler exists. Use a VPN for private-network access.
• Main application navigation is origin-bound. Android also blocks cross-origin subresource and POST requests before the network. External links need a native choice; dangerous URI schemes are rejected. No exported deep-link receiver exists.
• No addJavascriptInterface bridge or native credential store. Android blob exports capture at most 25 MB / eight same-origin Blob references using an origin-restricted document-start script, then pull bounded chunks with evaluateJavascript only after a user chooses a destination. Every pull rechecks origin and lifecycle. No blob fetch or CSP relaxation is used.
• WebView/WKWebView owns persistent HttpOnly session cookies. Native code neither handles passwords nor bypasses the server's CSRF rules. Native Android download code obtains a cookie snapshot only for the configured origin and refuses redirects.
• Live microphone, geolocation and media-capture requests are denied. The trusted app's file input uses explicit system pickers; Android image capture delegates to the camera app with a narrowly scoped content URI and no broad storage access.
• External SSO uses a separate capability-restricted web view and the same OS website cookie store. It does not gain app navigation/file handlers. iOS 18.4+ is required so uploads can be explicitly denied in that untrusted auth window.
• Android backups/device transfer are excluded and screenshots are blocked. iOS hides content when inactive and excludes temporary exports from backups. OS-managed WKWebView storage remains governed by iOS device/backup protection; do not assume the app can exclude every WebKit-managed cookie from an OS backup.
• Server changes stop and destroy the old web context and erase website data. Older Android engines that lack complete browsing-data deletion use an OS app-data reset, which closes the app. A local wipe is not remote session revocation.
• No app logs contain passwords, tokens, cookie headers or raw network exceptions. System/browser diagnostics are outside the app's complete control.

Limitations and release gates

The configured server and any server-installed extension are trusted same-origin code. An XSS or malicious administrator remains able to act as the signed-in user; native origin checks cannot fix compromised application content. Structural metadata probing does not authenticate the Yuvomi product or expose an anonymous version number. Embedded SSO providers that reject web views need a browser session instead; no secure native-session handoff exists upstream. A future handoff needs upstream review and single-use, short-lived, session-bound exchange semantics.

Downloaded files saved by the user remain outside app erasure. Android network downloads are capped at 100 MB / 120 seconds; generated blob exports at 25 MB / 45 seconds. iOS checks declared size before downloads and actual size before export (100 MB); an unknown/chunked size may consume disk before rejection. This resource-limit gap requires review and device testing before release.

Android WebView Safe Browsing remains enabled. The installed engine/OS may perform its own security checks; this app does not implement or log those network services. Keep the OS and WebView patched. OSV advisory checks are build-time, never runtime, and do not prove the absence of vulnerabilities. See docs/security-review.md.