# Threat model — opencode-mobile

Date: 2026-05-24
Version: 0.2.3

---

## Assets we protect

| Asset | Sensitivity | Storage |
|---|---|---|
| opencode server URL | Medium — reveals network topology | `expo-secure-store` (`opencode_connections`) |
| HTTP Basic auth password for opencode server | High — grants full server access | `expo-secure-store` (`opencode_password_<id>`) |
| User prompts sent to the AI model | High — may contain proprietary code or PII | In-flight only (not persisted on device) |
| AI responses / generated code | High — proprietary output | In-flight only (not persisted on device) |
| Sentry DSN | Low — public by design; quota-abuse risk | Bundle (EXPO_PUBLIC_) + SecureStore (consent state) |
| Biometric/PIN auth settings | Low | `expo-secure-store` (`opencode_auth_settings`) |
| Telemetry consent decision | Low | `expo-secure-store` (`opencode_telemetry_consent`) |
| Session IDs | Low — server-assigned, ephemeral | In-memory only |
| Notification preferences | Low | `expo-secure-store` (`opencode_settings`) |

---

## Attackers and attack scenarios

### 1. Network observer (passive MitM)

**Capability:** Can observe network traffic between phone and opencode server.

**Attack scenarios:**
- Intercept HTTP traffic on local LAN (e.g., corporate Wi-Fi, coffee shop).
- Read user prompts and AI responses in cleartext if server is accessed via `http://`.

**Defenses:**
- HTTPS: When user provides an `https://` URL, standard TLS verification via `expo/fetch` applies. No `rejectUnauthorized` overrides.
- Documentation: App UI explicitly recommends using `https://` when TLS is configured; the quick-connect form defaults to `http://` only for LAN/Tailscale where the user has a trusted network path.
- Tailscale: Most users access local servers over Tailscale (encrypted mesh VPN), making cleartext HTTP safe in practice.

**Residual risk:** Users who expose their opencode server on a public IP via HTTP (not HTTPS) without Tailscale have no transport-layer protection. This is documented as user responsibility.

---

### 2. Malicious deep link (`opencode://`)

**Capability:** Any installed app or web page can fire `opencode://` deep links at the app.

**Attack scenarios:**
- Inject a malicious server URL via deep link to phish the user into connecting to an attacker-controlled opencode server.
- Cause the app to navigate to an attacker-controlled session ID.

**Defenses:**
- Current deep link handling uses `expo-router`. The only parameterized routes are `/session/[id]` and `/connection/[id]`. Neither auto-connects to an external URL via deep link; server URLs are only stored via the explicit "Add Connection" UI.
- No deep link handler was found that auto-creates a connection from URL parameters.
- Notifications navigation (`router.push('/session/${data.sessionId}')`) uses server-assigned session IDs only, not user-supplied URLs.

**Residual risk:** Low. No auto-connect-from-deep-link path exists. If this is added in future, validate scheme+host against stored connections before navigating.

---

### 3. Lost or stolen device

**Capability:** Physical access to a locked device.

**Attack scenarios:**
- Read server URL and password from device storage.
- View AI session content / conversation history from lock screen notifications.
- Bypass app authentication.

**Defenses:**
- All sensitive data in `expo-secure-store` (iOS Keychain with `kSecAttrAccessibleWhenUnlockedThisDeviceOnly`; Android Keystore-backed EncryptedSharedPreferences). Data is inaccessible when the device is locked.
- Optional biometric app lock (`requireBiometric` setting). Default off for UX; users with sensitive servers should enable it.
- Notification lock-screen preview: session titles may appear in "Task completed" notifications. No prompt content or AI response content is included in notification bodies.
- **Known gap (M-03):** `permission.asked` notifications can show tool file-path glob patterns on lock screen. Fix pending.

**Residual risk:** Medium. Without biometric lock enabled, a device that auto-unlocks (e.g., trusted location) exposes app contents. Users should be prompted to enable biometric lock during onboarding when a server is added.

---

### 4. Compromised opencode server

**Capability:** Attacker controls the opencode server the app connects to (e.g., via supply-chain, server compromise, or DNS hijacking to an HTTPS server).

**Attack scenarios:**
- Server returns malicious tool permission requests designed to trick user into approving harmful file operations.
- Server returns crafted SSE events to cause client-side errors and exfiltrate stack traces.

**Defenses:**
- App renders server data (session titles, tool permission descriptions) as text only — no `eval()`, no `dangerouslySetInnerHTML`, no JavaScript injection surface.
- Sentry reports are scrubbed of URLs and query params before upload.
- Tool permission requests require explicit in-app user approval. The `permission.asked` UI shows the user what patterns the tool wants to access.

**Residual risk:** Medium. The app trusts the connected server by design. Users are responsible for connecting only to servers they control. This is documented in the UX.

---

### 5. Sentry DSN abuse

**Capability:** Attacker extracts the DSN from the APK/IPA (trivially readable via `strings`).

**Attack scenarios:**
- Flood the Sentry project with fake events, exhausting quota and masking real errors.
- Enumerate org/project metadata via the public DSN.

**Defenses:**
- The Sentry DSN is `EXPO_PUBLIC_` and therefore intentionally public (this is Sentry's documented model).
- `sendDefaultPii: false` ensures device identifiers are not sent.
- Sentry ingest rate-limiting can be configured per-project (deferred enhancement).

**Residual risk:** Low. Quota exhaustion is a nuisance, not a security breach. No user data flows from DSN exposure.

---

### 6. CI/CD supply chain attack

**Capability:** Attacker compromises a third-party GitHub Action used in the build pipeline.

**Attack scenarios:**
- Malicious action exfiltrates `PLAY_STORE_SERVICE_ACCOUNT_JSON` or keystore secrets.
- Tampered action injects malicious code into the APK.

**Defenses:**
- Secrets are stored as GitHub Secrets, not in code.
- `pull_request` trigger (not `pull_request_target`) prevents fork PRs from accessing secrets.
- `KEYSTORE_PASSWORD`, `KEY_ALIAS`, `KEY_PASSWORD` are separate from `KEYSTORE_BASE64`, minimizing damage from any single secret leak.

**Residual risk:** Medium. Third-party actions are pinned to tags, not commit SHAs (see H audit finding M-02). SHA pinning is the recommended fix.

---

## Out of scope

- **Security of the user's opencode server itself.** The server is user-managed; its authentication, file access controls, and model provider secrets are outside this app's threat model.
- **Model provider security.** API keys for Anthropic, OpenAI, etc. are held by the opencode server, not the mobile app. The app never sees model provider credentials.
- **Tailscale or VPN security.** Users connecting via Tailscale rely on Tailscale's security model for transport protection.
- **Device operating system integrity.** Rooted/jailbroken devices can bypass `expo-secure-store`. This is a platform-level threat outside app scope.

---

## Security architecture summary

```
[Phone] ──(HTTPS or HTTP-via-Tailscale)──> [opencode server (user-owned)]
   │                                               │
   │  expo-secure-store (Keychain/Keystore)        │── AI model provider (user's keys)
   │  • server URL + auth password                 │
   │  • biometric settings                         │
   │  • telemetry consent                          │
   │                                               │
   │  opt-in only                                  │
   └──(HTTPS)──> [Sentry ingest] (scrubbed, no PII, no prompts)
```