Skip to content

Future-work privacy boundary · not active

A future release would require local, explicit control.

No public Local Guard product or data-collection path is active. The points below are design requirements for any future release, not a description of the contest's native Site Tools flow.

Proposed minimum information

  • The origin and path of the tab you explicitly select.
  • The names, descriptions, input schemas, and safety annotations of WebMCP actions declared by that page.
  • A short-lived local document identifier and one-use capability metadata.
  • The bounded result, state comparison, side-effect list, and receipt identifier for an approved synthetic lab run.

Information a future release must not collect

Full page text, form entries, passwords, authentication cookies, payment information, personal messages, and unrelated browsing history remain outside the proposed scope.

Proposed transport boundary

Any future implementation would need explicit local consent, authenticated same-device transport, no telemetry or advertising, and an independently reviewed retention design before release.

Proposed retention and control

Pairing state and unused authority would need to disappear on disconnect, navigation, tab close, or consent revocation. Any retained receipt would need a clear user-controlled deletion path.

Reporting boundary

The current public lab creates only private page-session drafts. A future guard must not submit anything to Left Out Security or a security feed without a separate, explicit human review and action.

Policy changes

Any release must publish a versioned privacy notice, pass security and accessibility review, and disclose changes before handling data. None of those release gates is satisfied here.