fix(blog): correct CSP description and trust key path after source audit

CSP now accurately reflects http://127.0.0.1:* allowance for local
blob store. Trust key path uses platform config dir, not hardcoded path.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: rgbkrk

content/blog/security.mdx

@@ -58,7 +58,7 @@ Widget state updates are validated, typed, and routed through a `CommBridgeManag
 
 ### Content Security Policy
 
-The iframe also enforces a Content Security Policy. External resources (scripts, stylesheets, widget ESM modules) must load over HTTPS — no plain HTTP. This means anywidgets that fetch code from the web are required to use secure connections.
+The iframe also enforces a Content Security Policy. Scripts and stylesheets can load over HTTPS or from the local blob store (`127.0.0.1`). This keeps anywidgets functional — they can fetch ESM modules from the web over HTTPS or load assets served by the daemon locally — while blocking arbitrary HTTP origins.
 
 For organizations with stricter requirements — locking down `connect-src`, restricting script sources to specific domains, disabling `unsafe-eval` — these are levers we'd like to expose. If tighter output policies are something your team needs, [we'd love to hear about it](https://github.com/nteract/desktop/issues).
 
@@ -70,7 +70,7 @@ But "immediately" is dangerous. That's code you didn't write, asking to install
 
 nteract won't install anything without explicit approval. When you open a notebook with dependencies, the runtime doesn't start. You see the full package list. You click "Trust & Start." Only then does installation begin.
 
-The trust signature is an HMAC-SHA256 over the dependency metadata, signed with a key that lives only on your machine (`~/.config/runt/trust-key`, permissions `0600`). If anyone — human or agent — modifies the dependencies after you've approved them, the signature invalidates and nteract asks again.
+The trust signature is an HMAC-SHA256 over the dependency metadata, signed with a key that lives only on your machine (in your platform's config directory, permissions `0600`). If anyone — human or agent — modifies the dependencies after you've approved them, the signature invalidates and nteract asks again.
 
 We also run typosquatting detection. If a notebook asks for `reqeusts` instead of `requests`, you'll see a warning. It's not perfect, but it catches the obvious supply chain attacks that prey on typos.
 
@@ -92,6 +92,14 @@ Any process with filesystem access to the Unix socket can connect to the daemon.
 
 This is the same trust model as SSH: if you can access the socket file, you're authorized. Agents that run on your machine, as your user, get the same access you have. It's a deliberate trade-off. We're not trying to protect you from tools you chose to run — we're trying to protect you from untrusted content inside notebooks.
 
+## Your data stays on your machine
+
+nteract is local-first. Your notebooks, your outputs, your environments — they live on your filesystem, not on someone else's server. There's no cloud sync, no account to create, no telemetry phoning home with your code.
+
+The Automerge documents that back your notebooks are stored locally by the daemon. The blob store that holds your images and data frames is a directory on your disk. When you close the app, everything is right where you left it. No one else has a copy unless you explicitly share one.
+
+This matters for security in a way that's easy to overlook. Every cloud-hosted notebook service is a target — for attackers, for subpoenas, for data breaches. With nteract, there's no central server holding thousands of users' API keys, datasets, and credentials. Your data is yours. The attack surface is your machine, which you already control.
+
 ## Why Tauri
 
 <TauriComparison />
@@ -113,6 +121,7 @@ Our approach is defense in depth:
 1. **Outputs can't escape their iframe.** Even if a kernel produces malicious HTML, it can't touch the host app.
 2. **Dependencies require explicit trust.** No silent installs, no unsigned packages slipping through.
 3. **The daemon has no network surface.** Unix sockets with restricted permissions.
+4. **Your data never leaves your machine.** No cloud, no accounts, no telemetry.
 
 None of these are revolutionary ideas individually. But notebooks have operated without *any* of them for over a decade. We think it's time to raise the bar.