[JetSquirrel]

Part of #64. Closes #68, except for the decision under "Your call".

Why

Someone asked in #29 what guarantees their data stays local. "It's open source" is true but leaves them to do the work. This gives them evidence they can check.

What

docs/network-and-privacy.md lists every outbound path: what starts it, whether it's on by default, where it goes, what it sends, and how to stop it. It also covers what's stored locally, the threat boundaries, how to verify a download, how to build from source, and what a change adding a new path must do.

scripts/check-offline.sh, on Linux CI, runs the CLI and the window over local files under strace and fails on any connection beyond this machine. Before that it runs a control: it makes a real connection attempt and fails unless its filter catches it, because "0 attempts" is also what a blind check would report. Latest result: 0 inet attempts, control caught.

tests/network_paths.rs fails when a network API appears in the source without being listed, and when a telemetry or second HTTP client becomes a direct dependency. It's a text search, so a tripwire rather than a proof.

Tests also pin that the base map and the launch update check start off.

Notices: turning on the base map or the launch check now says where requests go. The S3 dialog and the extension Install button say they download.

What I found

• The app has one HTTP client in native builds, ureq, used for updates, tiles and S3. Cargo.lock also lists hyper, quinn and a reqwest fork, but those are only for gpui-kit-assets' wasm build. I confirmed this with cargo tree for Windows and Linux; on macOS I only read the manifest, because cargo tree couldn't resolve that target offline here.
• The README was close but incomplete. It left out extensions and SQL naming remote addresses. Fixed in both languages.
• A .dash file can reach the network when opened, if httpfs is installed. Its SQL can only read, but read_csv('https://...') is a read, and the URL can carry data from other tables. It can also read any local file you can. This is documented, not changed.

Your call

1. Should opening an untrusted .dash warn first? The issue asks for a notice "where a workflow first enables an external data source". The notices here cover S3, extensions, tiles and updates, but not a dashboard that names a remote address. Fixing that is a product decision (warn on open? refuse remote addresses until confirmed?), so I've left it. It's the main gap I'd close next.

2. Updater trust on Windows and Linux. The hash comes from the same server as the package, so it catches corruption but not a compromised server, and those packages aren't signed. The page says so plainly. Whether to sign them is your call.

3. The reply to this is a cool tool but #29. I haven't posted anything there. Suggested text once this is merged:

   To follow up with something you can check: Network and privacy lists every path that can leave your machine, what it sends, and how to stop it. There's no telemetry or crash upload. CI now traces the app over local files on Linux and fails on any connection beyond the machine, and a test fails if new network code appears without being documented. On macOS or Windows, a per-app firewall gives you the same evidence, and you can build from source. One limit worth knowing: a .dash file runs its read-only SQL when opened, so with httpfs installed, only open dashboards from people you trust.

Limits

• The runtime check is Linux only, and proves only those paths on that run. It confirms the window started with a dashboard and a map, but not what it drew.
• Not audited: DuckDB's internals and the other dependencies. The page says so.
• Facts about third parties (Cloudflare R2 behind dl.ducklocal.app, extensions.duckdb.org) come from the repo's scripts and my own knowledge, so please correct anything wrong.

Testing

• check-offline.sh passes on Linux CI.
• cargo test --locked: 460 unit, 4 network-path, CLI and LSP tests pass after merging main, and clippy and fmt are clean.
• Unrelated flaky test: remote::tests::a_missing_or_stale_endpoint_means_no_window failed once in about 10 runs here and passes otherwise. I think a parallel test grabs the freed port, but haven't proven it. It predates this PR, so I left it.

🤖 Generated with Claude Code