security(truth): consolidate user-visible security/privacy claims across storage, providers, PWA, collaboration & supply chain

[qnbs]

Purpose

Create one security-truth reconciliation owner for WorldScript Studio. This issue does not invent a new crypto/security subsystem; it closes the documentation/product-truth gap between several already-authoritative implementation trackers whose claims surface together in Help, README, security docs, locale text, release notes and diagnostics.

This is the canonical S10 security truth consolidation tracker. Implementation/security work remains owned by its specialist issues.

Why a separate integration tracker is needed

Current security truth spans materially different authorities:

• native encrypted-storage future authority: security(core/R-15): renderer-neutral encrypted desktop storage, durable migration & identity binding #445 / R-15;
• browser/PWA security and storage semantics: pwa(first-class): harden offline reliability, lifecycle, performance, install/update UX & browser-native AI #478 and pwa(storage): engineer a durable IDB+OPFS storage tier with persistence, quota & recovery UX #482;
• provider routing/privacy truth, including the Claude web proxy distinction: pwa(first-class): harden offline reliability, lifecycle, performance, install/update UX & browser-native AI #478 / current provider architecture;
• API-key storage vs project-data encryption vs collaboration crypto: separate mechanisms with different guarantees;
• security-sensitive locale corrections: i18n: propagate desktop API-key/storage security-doc corrections to 14 remaining locales #382;
• supply-chain/provenance truth: supply-chain: document trust-policy gaps across Docker/GHCR, Tauri release artifacts, and pnpm dependency provenance #529;
• vendored collaboration transport security maintenance: chore(security): upstream y-webrtc diff check — vendor fork audit #60;
• current Tauri filesystem recovery/storage behavior: Desktop: 'Reset Database & Reload' recovery button doesn't clear corrupted Tauri project files #515 lineage and the native roadmap.

Without a single reconciliation gate it is easy for one surface to say “encrypted”, “local”, “never sent to WorldScript”, or “stored in IndexedDB/OPFS” more broadly than the actual selected runtime/backend guarantees.

Required truth model

Maintain a small explicit matrix for every security/privacy claim that users can encounter:

Claim class	PWA/browser	Tauri transitional desktop	Qt/Core target	Evidence owner
project/manuscript at-rest protection	exact current behavior	exact current behavior	#445 contract	#445/#482
API credential protection	exact keystore mechanism	exact desktop mechanism	future Core/OS integration as admitted	implementation/docs
provider request routing	direct vs proxy per provider	direct vs proxy per provider	target adapter behavior	provider architecture
collaboration transport crypto	exact y-webrtc/vendor-fork contract	same where used	renderer-neutral semantics if retained	#60/collab docs
local AI	local browser / Ollama / cloud distinction	desktop path	Qt/Core path	#478/#483
cache/service-worker persistence	exact PWA scope	n/a	n/a	#478/#485
release/supply-chain provenance	web/deploy artifacts	Tauri/Qt binaries	target release pipeline	#529

Do not mark a row complete from documentation alone; tie it to implementation/evidence maturity.

Surfaces to reconcile

Audit at minimum:

• README.md security/privacy wording;
• SECURITY.md;
• AUDIT.md current security truth;
• docs/SECURITY-THREAT-MODEL.md;
• docs/IDB-ENCRYPTION.md and relevant native/storage docs;
• PWA/security documentation;
• Help/FAQ security copy and locale source files;
• provider-selection/settings copy;
• release notes / updater / deployment docs where guarantees are stated;
• diagnostics/status UI that labels work as local/cloud/encrypted/protected;
• manifest/service-worker descriptions where relevant.

Required distinctions

Never collapse these into one generic “encrypted/local/private” claim:

1. API-key credential encryption;
2. project/manuscript at-rest encryption;
3. collaboration transport encryption;
4. filesystem/browser origin isolation;
5. local-AI execution;
6. local-network Ollama execution;
7. cloud-provider execution;
8. WorldScript-hosted proxy traversal;
9. release artifact signing/provenance.

Change-control rule

When any underlying authority changes (#445, #478/#482/#485, provider routing, #529, #60, etc.), security-facing documentation must be re-audited before release if the changed behavior affects an existing claim.

Prefer automated drift checks for statements that can be derived deterministically (configured providers/backends/versioned security capability declarations), but do not attempt to mechanically infer nuanced threat-model prose.

Acceptance criteria

• One current cross-surface security-truth matrix exists and names implementation/evidence owners.
• Current PWA, transitional Tauri and future Qt/Core guarantees are explicitly separated.
• Credential encryption, project encryption and collaboration crypto are never conflated.
• Provider routing truth explicitly distinguishes direct, local-network, browser-local and WorldScript-proxy paths.
• Storage-location claims distinguish IndexedDB/OPFS from native filesystem/Core storage.
• i18n: propagate desktop API-key/storage security-doc corrections to 14 remaining locales #382 locale corrections are reconciled without silently translating security claims incorrectly.
• supply-chain: document trust-policy gaps across Docker/GHCR, Tauri release artifacts, and pnpm dependency provenance #529 supply-chain guarantees are reflected only after the corresponding provenance/signing evidence exists.
• chore(security): upstream y-webrtc diff check — vendor fork audit #60/vendor-fork security maintenance is referenced where collaboration guarantees are documented.
• No user-facing surface overclaims R-15 before security(core/R-15): renderer-neutral encrypted desktop storage, durable migration & identity binding #445's authoritative protected path is implemented and evidenced.
• A release-facing checklist/drift gate exists for security-truth-affecting changes.

Non-goals

• implementing R-15 here;
• changing cryptographic algorithms here;
• implementing PWA storage/update architecture here;
• fixing supply-chain: document trust-policy gaps across Docker/GHCR, Tauri release artifacts, and pnpm dependency provenance #529 supply-chain gaps here;
• translating all locales inside this umbrella;
• duplicating specialist issue acceptance criteria.

Specialist issues own implementation. This issue owns cross-surface truth and closure reconciliation.

[qnbs]

Product/UX exploration for this topic now also lives in Discussion #637: #637. This Issue remains the implementation/acceptance tracker; the Discussion does not change priority, roadmap admission, acceptance criteria, or execution sequencing by itself.

[qnbs]

2026-09-11 documentation/security-truth drift — supported version + release-signing vocabulary

A fresh live audit found a concrete user-facing security-truth drift that belongs here rather than in a new docs issue.

Supported-version policy is stale

Current .github/SECURITY.md still says:

| main (v1.27.0) | Full support |
| 1.3.x – 1.26.0 | Best effort |

while the repository's current released desktop line is v1.28.6 and main has moved further with unreleased fixes.

This is not merely cosmetic: SECURITY.md is a user-facing support/security contract. It should not imply that main is tied to an older release line or leave the current supported release ambiguous.

Required reconciliation:

• distinguish main from released stable version rather than encoding a volatile version beside main unless automation/policy keeps it synchronized;
• state the actually supported current stable release line at implementation time;
• keep old-version/best-effort language aligned with real backport/support policy;
• avoid automatically implying that every historical 1.x release remains security-supported if that is not operationally true.

Prefer a low-drift policy such as:

main = development branch / current source
latest stable release = supported release authority
older releases = explicit best-effort or unsupported window

with the exact release value derived/updated through existing release truth rather than hand-copied across multiple docs where practical.

Release-signing wording must remain layered

The current product has distinct trust layers:

Git commit/tag signature
≠ GitHub provenance/attestation
≠ Tauri updater Minisign signature
≠ macOS Developer ID signature/notarization
≠ Windows Authenticode

#574 is the native release-trust implementation owner. #549 should ensure user-facing SECURITY/README/help language never collapses these into a generic "signed desktop app" claim before the relevant platform evidence exists.

In particular, an updater archive carrying a valid Tauri updater signature does not prove the downloadable .dmg/.msi/.exe has OS-native signing/notarization.

Desktop at-rest encryption truth remains unchanged

Keep the existing correct statement from #445: authoritative Tauri filesystem project data is not yet protected by the future renderer-neutral R-15 encrypted-storage authority. Documentation/UI must continue to distinguish Web/IDB protection, credential storage and future desktop project encryption rather than describing all local data as uniformly encrypted.

Suggested acceptance addition

Before #549 closes, include .github/SECURITY.md in the cross-surface truth audit and ensure supported-version, desktop encryption, updater signing, OS signing/notarization, PWA storage and provider-routing claims are all current against their durable owners (#445, #574, #478/#485, #704 and related children).

[qnbs]

2026-09-11 older-audit requalification — Claude proxy claim boundary + interim desktop disk-encryption guidance

A second live audit pass against current source found two residual security-truth details worth carrying here. Several broader claims in the older audit are already satisfied and should not be re-opened.

1. Claude proxy trust-delta documentation is already substantially correct

Current source/docs already do the important things the older audit requested:

• desktop Claude calls Anthropic directly;
• Vercel/Cloudflare Pages use WorldScript's same-origin stateless serverless relay;
• GitHub Pages cannot offer Claude through that relay;
• README/ADR/threat model explicitly say that the API key/message transit infrastructure WorldScript operates and that this is not the same trust model as direct BYOK;
• proxy application code is schema-validated, body-size-capped, same-origin checked, rate-limited and timeout-bounded;
• current proxy code does not intentionally log/cache/persist the API key, prompt or response.

Therefore do not add a duplicate "Claude trust delta" architecture issue.

One wording refinement remains important: scope strong no-logging claims to what WorldScript's application code/configuration can actually prove. Prefer language conceptually equivalent to:

WorldScript's proxy application code does not log, persist or cache the API key,
prompt or response.

Do not imply that no hosting/provider infrastructure can ever produce request/connection metadata unless the relevant Vercel/Cloudflare service configuration and retention contract are independently evidenced.

Keep content secrecy distinct from ordinary connection/platform metadata.

A self-hosted Claude-proxy guide can remain an optional later convenience; it is not required to make the current trust model truthful and does not justify another P1 issue by itself.

2. Interim desktop at-rest guidance while #445/R-15 remains open

Current docs/IDB-ENCRYPTION.md still correctly states that authoritative Tauri project/settings/snapshot/image/Codex/RAG/binder filesystem data is plaintext/LZ-compressed rather than protected by the future R-15 authority.

A repository-wide search did not find explicit BitLocker/FileVault/LUKS guidance. While #445 remains unresolved, consider adding a bounded host-level mitigation note to security/threat-model/help surfaces:

For protection against offline disk theft/forensics on the current desktop build,
use the operating system's full-disk encryption (e.g. BitLocker, FileVault, LUKS)
and maintain verified encrypted backups where appropriate.

Crucially this must be described as a host-level mitigation, not as WorldScript project encryption and not as closure of #445.

Also keep snapshot/history/asset plaintext exposure inside the same desktop truth row rather than mentioning only the primary manuscript file.

Already-satisfied older-audit items

Do not create new work solely to:

• add the basic Claude proxy trust-delta section — it already exists;
• add public-signaling metadata warnings/self-host guidance — current collaboration docs/UI already carry them;
• claim IDB disable/rotation is missing — current browser lifecycle has moved beyond that old state.

The purpose of this comment is to tighten current claims, not expand #549 into new implementation authority.

[qnbs]

2026-09-16 AI/privacy truth-owner update

The earlier security-truth notes correctly treated #704 as the broad provider/model authority at the time. That ownership has since converged and #704 is now terminal/closed. Do not reopen it or keep using it as the active security/privacy truth owner for residual AI work.

Current security/privacy-relevant AI ownership is now:

#711 = Settings/default-off/network admission
#713 = deferred/apply-later project authority
#714 = cancellation/supersession/request lifecycle
#729 = Claude structured-output runtime plumbing
#731 = Claude relay/direct budgets, timeout and real SSE transport
#732 = content-free provider usage/token accounting
#556 = local AI/Voice lifecycle/resource/integrity
#743 = v1.28.7 AI/local-AI release qualification gate

Newly terminal evidence that may be stated narrowly

#744 provides deterministic product evidence for one important Browser-Ollama privacy boundary:

feature disabled
→ Settings/Ollama surface is network-inert
→ no unsolicited local-server request

explicit opt-in + explicit Load/Test action
→ local request is admitted

This supports a scoped claim about admission/network inertness while OFF. It does not prove real Ollama inference quality, model availability, cancellation/resource behavior, or all local-AI privacy claims; those remain under #556/#714/#743 real-runtime qualification.

Claude relay security boundary remains load-bearing

#728/#731 requalification confirmed that the current 20s outbound Claude relay timeout is documented as part of the public unauthenticated relay's CWE-400/resource-exhaustion controls. Any future increase is therefore a security-policy change requiring explicit abuse/resource reassessment and synchronized threat-model truth — not a performance-only constant tweak.

#759 moved provider transport into dedicated adapters, but this is architecture-only. Direct desktop Anthropic traffic versus web same-origin relay remains a meaningful trust-boundary distinction and must continue to be described accurately.

Planning documents are not implemented guarantees

Merged #727/#728/#730 are planning/evidence for #732/#731/#729. Do not let security/privacy/help copy imply their runtime behavior exists until the owning implementation issues are terminally evidenced.

Release truth

#743 remains OPEN / NOT PASS. No public security/privacy prose should describe the v1.28.7 local-AI/runtime surface as fully qualified until that gate reaches explicit PASS.

This addendum updates ownership and evidence only; it does not weaken the existing distinctions between credential protection, project-data encryption, collaboration crypto, local/browser-local/local-network execution, cloud execution, proxy traversal, and release-signing layers.

[qnbs]

2026-09-22 housekeeping — release/security-truth owner update

The 2026-09-16 addendum in this thread said #743 remains OPEN / NOT PASS. That was correct at the time but is no longer current.

Live repository/release truth now is:

• release(ai): gate v1.28.7 on curated local-model and runtime qualification #743 is closed / completed.
• v1.28.8 is the published latest stable release (GitHub Release ID 393654913).
• The v1.28.8 tag is signed/verified and the release publishes the expected updater/install artifacts and .sig files plus latest.json.
• The public v1.28.8 release body has been corrected from pre-tag "release candidate" wording to released truth.

This does not mean the broader security/privacy matrix is complete. Keep these owners active:

• security(core/R-15): renderer-neutral encrypted desktop storage, durable migration & identity binding #445 / Desktop atomic writes: fsync temp file + parent directory before/after rename for true crash durability #357 / Desktop fs-data key-rotation migration is not crash-resumable (mixed-key state possible) #359 / Desktop fs reads/writes don't participate in the encryption-migration admission lock (race window during disable/rotate) #360 / Bind desktop fs-backed ciphertext to its record identity (AAD) to prevent cross-file substitution #361 — renderer-neutral desktop protected-storage/durability/migration/identity work.
• release(native): establish platform code signing, notarization, artifact identity & rollback trust #574 — OS-native release trust, notarization/AuthentiCode, artifact identity and rollback policy.
• test(opt-in): qualify Settings admission, persistence and network/runtime safety for default-off features #711 — default-off/network admission.
• ai(lifecycle): unify Stop Generation, cancellation, supersession and duplicate-request semantics #714 — cancellation/supersession/request lifecycle.
• ai(local): harden Whisper/Kokoro model lifecycle, low-end performance, integrity & Eco-Mode #556 — local AI/Voice lifecycle/resource/integrity.
• supply-chain: document trust-policy gaps across Docker/GHCR, Tauri release artifacts, and pnpm dependency provenance #529 — provenance/SBOM/supply-chain truth.

Historical #743 comments remain release provenance for v1.28.7/v1.28.8 sequencing, not an active security-truth blocker.

#549 remains OPEN / P1 until the cross-surface security-truth matrix and user-facing claims are reconciled against these live owners.

[qnbs]

Current-main user-facing overclaim — English Desktop Help still contradicts live storage/release-trust truth (2026-09-23)

Revalidated directly against locales/en/help.json on current main 2de980dbedf3ea5e2ada0ac8b6d449faf10a2a5e.

Most of the previously corrected English security/privacy copy is now materially better: the API-key FAQ distinguishes Browser/PWA IndexedDB protection from the desktop lifecycle and names the Claude web relay exception; the privacy FAQ distinguishes Browser/PWA IDB/OPFS from Tauri local files.

However, help.docs.tauriDesktop.content still contains two concrete user-facing truth defects:

1. Desktop “Open data folder” wording still says IndexedDB/OPFS

The key currently says the desktop action opens the directory “where IndexedDB and OPFS data are stored”.

That is internally contradictory with the same Help entry's later Data Location section, which correctly says desktop data lives under the Tauri app-data filesystem directory. It is also inconsistent with the current desktop storage authority tracked by #445/#553 and the existing security documentation.

Required correction: describe the action as revealing the desktop app-data directory / local filesystem data location. Do not describe authoritative Tauri project storage as browser IndexedDB/OPFS.

2. Installer copy overclaims OS-native signing

The same Help key currently says:

.dmg for macOS (code-signed)
.msi / .exe for Windows (code-signed)

#574's current evidence does not authorize those generic claims. The repository has distinct trust layers:

Git commit/tag signature
≠ Tauri updater signature
≠ macOS Developer ID signing/notarization/stapling
≠ Windows Authenticode/timestamping

v1.28.8 provides useful exact-SHA/tag/updater-signature evidence, but #574 explicitly remains open for macOS Developer ID/notarization and Windows Authenticode.

Required correction: remove or qualify the OS-native “code-signed” installer claim until #574 has platform-specific evidence.

Closure implication

Treat these two English-source corrections as part of #549's cross-surface truth reconciliation. After the English authority is corrected, #382 must propagate the corresponding semantic truth to non-production locale Help sources rather than copying the stale English wording.

Do not weaken or rewrite historical release evidence; this is about current user-facing product claims.