Privacy & data locality in WorldScript — what stays local, what can reach the cloud, and what is encrypted?

[qnbs]

Why this exists

Issue #549 asks for a precise privacy and data-locality explanation, while #445 is the future native protected-storage authority. This Q&A is intended to clarify current behavior without promising future R-15 functionality.

Current product boundary

Browser/PWA project storage: project data is stored locally in the browser's IndexedDB/related local storage path. Optional IndexedDB at-rest protection is a separate capability and does not mean every browser-stored project is encrypted by default.

Transitional desktop filesystem storage: the current Tauri/transitional desktop project-file path remains plaintext until R-15. There is no current tauri-plugin-stronghold or OS-keychain-backed project-storage authority. Local desktop storage is therefore not represented as already encrypted project storage.

Future R-15 native protected storage: #445 defines the renderer-neutral encrypted desktop-storage program and its durability/recovery requirements. It is planned work, not a claim that the current desktop project-file path is already protected.

API credential protection: API credentials are handled separately from project documents through the app's credential-protection path and are encrypted at rest according to the current platform-specific mechanism. Credential protection must not be generalized into a claim that project files are encrypted today.

Collaboration transport: real-time collaboration transport uses the repository's E2E-encrypted collaboration path, including authenticated encrypted data channels. Transport protection does not change the storage authority or guarantee that every participant's local copy is encrypted at rest.

Browser-local AI: explicitly selected browser-local WebGPU/WASM or equivalent local inference keeps the inference payload on the user's device, subject to the model/runtime and browser capabilities. There is no hidden local-to-cloud fallback.

Local-network Ollama: an explicitly selected Ollama or other local-network endpoint receives data over the user's configured local network path. That is local-network processing, not a WorldScript-hosted cloud proxy, but network and endpoint trust remain the user's responsibility.

Direct cloud providers: when the user explicitly selects a cloud provider, the relevant prompt or document context is sent to that provider under the provider's service and retention terms. The app does not imply that a direct provider call is local processing.

WorldScript-hosted proxy paths: WorldScript is an offline-first client and does not currently operate a general project-data proxy. Any future feature that introduces a WorldScript-hosted proxy must disclose that path separately; it must not be inferred from the local or direct-provider descriptions above.

Role perspectives

Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, or evidence of consensus.

• 🔐 Security explainer: distinguish storage, transport, credentials, inference location, and future protected-storage claims.
• ✍️ Privacy-focused author: make data locality and provider choice understandable before writing or AI actions occur.
• 🌐 Browser/native distinction: explain what the PWA, transitional desktop, and future R-15 authority each do today.

Questions

• Which privacy boundary is still unclear?
• Which provider, local-network, or browser-local choice needs a more visible explanation?
• What recovery and encryption evidence would make the future R-15 boundary trustworthy?

Relationship to implementation

#549 remains the current privacy/data-locality discussion and issue authority for its scope. #445 remains the future native-storage authority; this Q&A does not imply that R-15 is implemented, does not change either Issue's priority or acceptance criteria, and does not provide an accepted answer automatically.