Parlane

Data-sharing consent migration

The next Parlane release requires explicit consent before sending content to an external server. This applies to existing connections as well as new ones. The bundled offline demo needs no external consent.

Publish your actual processing declaration

Add dataProcessing to your manifest with a version, operator name, HTTPS privacy policy URL, data types, purposes, retention, training policy, and an explicit list of recipients. Name the companies handling content, including AI, hosting, speech and logging providers. Do not copy a sample's claims without checking your own providers' terms.

The manifest reference has the complete example; integration kit §2.4 defines the limits and wire contract. Keep your HTTP well-known manifest available before consent, including when also offering MCP.

Check the version before processing content

Require Parlane-Data-Policy: <current-version> on chat, dashboards, actions, capture and server voice. Leave manifests and authentication/bootstrap endpoints available first. Continue enforcing authentication and authorization separately. The header records which declaration the client accepted; it does not identify a user.

app.get('/.well-known/parlane.json', (_req, res) => res.json(manifest));
// Keep authentication in place; this header is not authentication.
app.use(dataPolicyMiddleware(() => manifest.dataProcessing));
app.post('/chat', chatHandler);
app.post('/action', actionHandler);
app.post('/capture', captureHandler);
app.post('/tts', voiceHandler);
app.get('/ui/:id', dashboardHandler);

The optional dataPolicyMiddleware and requireDataPolicy helpers live in packages/server-kit/dataConsent.js. A missing or old version receives HTTP 409 with error code data_consent_required. Check before forwarding, storing, logging or acting on content.

For MCP Streamable HTTP, check each request's HTTP header in the tool/resource handler. The reference SDK exposes it as extra.requestInfo.headers['parlane-data-policy']. Allow manifest reads, and guard content resources and tool calls. Checking only the session initialization leaves warm sessions using an old policy.

Handle changes and paused consent

Increase the version before changing recipients, retention, purposes or training behavior. The app re-fetches the manifest before content operations and compares the complete accepted declaration, so changing a field without increasing the version still triggers review. Server enforcement closes the race between that preflight and a request arriving.

Users can pause sharing in Settings → Server data sharing. Native Shortcuts and share-sheet deliveries then stay on the phone for review. Never treat authentication, pairing, a subscription or a previously enabled feature as processor consent.

Coordinate the rollout

  1. Publish an accurate declaration and validate it against the updated schema.
  2. Test a new client with REST, MCP/OAuth and any capture or server-voice endpoints you expose.
  3. Enable strict enforcement with a clear minimum-client notice. Builds through 78 do not send the header and will be blocked by the guard.
  4. Test a changed provider and paused permission: no content operation should run until the user reviews and accepts.

Saved shares retain their request IDs. Implement durable deduplication scoped to the authenticated owner, and reject an ID reused with conflicting content. See the private-preview and retry guide. Standard and private notification previews remain separate user choices; this consent migration does not itself encrypt previews.