41 — Telemetry-Zero Proof

The exhaustive list of every network call the Locara framework, runtime, CLI, and reference apps make. The point is to make the “no telemetry” claim verifiable: a security researcher can read this doc, audit the code, and confirm.

This document is normative. Adding a network call requires updating this doc; un-listed network calls are bugs.

Principles

Default-zero. No code path in the framework, runtime, or CLI makes a network call without explicit user action or app-manifest declaration.
Apps follow the manifest. A Locara app with net: false makes zero network calls, period. The macOS App Sandbox enforces this at the kernel level.
Aggregate only. When the registry needs aggregate data (install counts, app popularity), it computes from anonymized version-check pings. Never per-user.
Listed here = audited. Every network call exists in this doc with a justification. No “minor” telemetry hidden in dependencies.

Categorical claims

Component	Network calls?
Locara framework crates (`locara-core`, `locara-storage`, etc.)	None. Pure-local code. No HTTP client embedded.
`@locara/sdk` and `@locara/components`	None. Pure JS/TS. No telemetry hooks.
`locara` CLI	Only on explicit commands (see below). No background pings.
Each Locara app at runtime	Only what the app’s manifest declares. `net: false` → zero.
Locara website	Static HTML/CSS/JS only. Browser fetches images + manifests as the user navigates.

Exhaustive list of network calls

From the `locara` CLI

Command	When	Endpoint	Payload	Why
`locara init --from-prompt`	User runs the command with a prompt	User’s chosen LLM API (`ANTHROPIC_API_KEY` or `OPENAI_API_KEY` env var)	The prompt text	User explicitly opted into LLM scaffolding. Locara doesn’t proxy this; the CLI calls the user’s chosen API directly.
`locara model add <id>`	User runs the command	Hugging Face Hub or Locara CDN	None on outbound; downloads model artifact	User explicitly added a model.
`locara verify`	User runs the command	Locara registry’s `/v1/models/:id` API	Model ID lookup	Verifies model hash declared in manifest matches registry record. Read-only; no PII.
`locara publish`	User runs the command	Locara registry submission API	`{ repo_url, commit_sha, manifest_signature, publisher_token }`	User explicitly publishing.
`locara doctor`	User runs the command	None	None	Local-only diagnostics.
(any other command)	—	None	—	All other CLI commands (init w/o prompt, dev, test, simulate, build) are local-only.

From a Locara app at runtime

Trigger	When	Endpoint	Payload	Capability required
Update check	Daily by default (configurable per-app)	Locara registry’s manifest API: `GET /v1/apps/{publisher}/{name}/latest`	None outbound; receives `{version, hash}`	None — the runtime makes this call independent of the app’s `net` capability, since it’s framework-level. The user can disable per-app or globally.
Revocation check	On app launch	Locara registry’s revocation API: `GET /v1/revocations`	None	Same as above.
Model fetch on first use	When a declared model is needed but not yet cached	Locara CDN or Hugging Face	None outbound; downloads weights	None — the runtime fetches; the app doesn’t see this.
App-declared `net` calls	When the app code makes a network request	Whatever the app’s `net.allowed_hosts` declares	App’s payload	`net: { allowed_hosts: [...] }` declared in manifest. Apps with `net: false` cannot make this call (kernel-blocked).
Tool-declared `net` calls	When a tool requires network and the app declares it	Per the tool’s manifest + app’s allowlist	Tool’s payload	Same as above; tools cannot exceed app capabilities.
Tauri’s standard updater	App-bundle update download	Locara CDN	None outbound; downloads new `.app` bundle	None — runtime-level.
Sigstore provenance verification	On app first launch	Sigstore public log (Rekor)	Lookup of attestation by signature	None — runtime-level.

That’s it. Every single network call is in one of these tables.

From the Locara website

The website (locara.app) is static HTML hosted on Cloudflare Pages.

When	Endpoint	Payload	Notes
User loads a page	Static files from `locara.app`	Standard HTTP	Cloudflare retains access logs per their policy; we do not analyze them for tracking.
User clicks “Download”	Static `.dmg` from `cdn.locara.app` (Cloudflare R2)	Standard HTTP	Anonymous download; no auth required.
Catalog listings + app pages	Pre-rendered at build time from registry data	None	Fully static; no runtime API calls.

The website does NOT:

Run analytics scripts (no Google Analytics, no Plausible, no Fathom — none).
Use cookies for tracking (only minimal preference cookies if the user customizes settings).
Embed third-party iframes that could phone home.
Make XHR/fetch calls to track user behavior.

If we ever want website analytics, we’ll use server-side log aggregation only (no client-side scripts) and document it here explicitly.

From Locara CI (build pipeline)

CI is invoked by locara publish and runs in GitHub Actions. CI does make network calls — but this is the infrastructure, not the user’s machine, so it’s not “telemetry” in the user-facing sense. Still, listed for completeness:

When	Endpoint	Payload
Clone source on submission	GitHub	Standard git operations
Fetch dependencies	crates.io, npm, Hugging Face	Standard package fetches
Submit to Apple notarization	Apple’s notarization service	Signed `.app` bundle
Sign + log to Sigstore	Sigstore	Provenance attestation
Upload artifact	Cloudflare R2	Signed `.app`
Update Postgres metadata	Locara registry’s Postgres	Manifest record

No PII is captured; the CI pipeline operates on artifacts, not users.

What about dependencies?

The framework links significant Rust + JS dependencies. We treat them carefully:

Tauri: does not phone home in any default configuration. Updater plugin is opt-in and configurable; we point it at our own update endpoint.
llama.cpp: zero network calls (it’s a local inference library).
Wasmtime: zero network calls.
SQLite + sqlite-vec: zero network calls.
TypeScript ecosystem: we audit transitive dependencies for telemetry. Anything that phones home is a release-blocker (CI runs npm-audit-resolver and similar).

For the reference apps:

Whisper / Qwen / GLM-OCR / nomic-embed: all run locally; the model files contain no executable telemetry.
Pyodide (when used by code-exec.python tool): runs in Wasmtime sandbox; no network unless tool declares net.

If we ever discover a dependency with hidden telemetry, we either (a) replace it, (b) patch it out, or (c) document it here loudly. The standing policy is no telemetry.

What we never do

These are explicit guardrails. Doing any of them would require an ADR superseding this doc and a public announcement.

❌ Anonymous usage analytics (Mixpanel, Amplitude, Heap, etc.).
❌ Crash reporters that auto-upload (Sentry, Bugsnag, etc.). Crashes log locally; user must explicitly export to share.
❌ A/B testing infrastructure that calls home.
❌ Feature flags fetched from a server.
❌ Marketing pixels, conversion tracking, ads.
❌ Server-side logs that retain IPs longer than 30 days.
❌ Anything that phones home about user behavior, even “anonymized.”
❌ Telemetry that’s “off by default but on if you opt in” (creates a drift target; opt-in telemetry is still telemetry).

How to verify

A security researcher can audit this claim by:

Reading this doc + cross-checking against the codebase.
Network-monitoring an installed Locara app: install Transcribe with net: false; use Little Snitch or tcpdump to confirm zero outbound traffic.
Auditing the framework crates: grep for reqwest, hyper, ureq, surf, fetch in the Locara framework code. Should find zero hits.
Auditing dependencies: check Cargo.lock and package-lock.json against known-telemetry libraries.
Checking the website’s HTML: view-source:locara.app should contain no analytics scripts.

We make this verification easy. The framework is open source under Apache 2.0; the website is open source. Everything is auditable.

Public commitment

This document is a public commitment. Violating it is a project-existential mistake. The privacy thesis dies the moment a user discovers hidden telemetry; we lose the trust we built and have no path to recover it.

Future maintainers: don’t violate this. If a maintainer ever feels pressure to add even “a little” telemetry, treat that pressure as a signal to step back, not as justification for compromise. Sustainable funding does not depend on telemetry; we have explicit alternatives (24-monetization.md, ADR 0010).

Open questions

(open) Should we publish a real-time “no-telemetry canary” page (like a warrant canary) declaring “as of date X, Locara has not added any telemetry”? Cheap; useful trust signal. Probably yes.
(open) Should we run periodic external audits and publish results? Phase 4+ when the budget allows.
(open) What’s the SLA for updating this document? Probably: any PR adding a network call MUST update this doc in the same PR; CI enforces.

Cross-references

13-security-privacy.md § zero ambient telemetry
24-monetization.md — “we will never sell user data”
ADR 0010 — financial sustainability without telemetry
../legal/privacy-policy.md — legal version of these claims