Privacy Policy

Public Capability Search

Public search and retrieval require no account, cookie, BLACK BOX PASS, or LOW credential. A search request contains the technical Problem text you choose to send and an optional result limit. The public search Worker evaluates that request against a sanitized static Founding corpus and does not send the query to LAB, Workers AI, Google, or another model/provider. The search implementation does not durably store the query or result and returns Cache-Control: no-store.

Do not submit credentials, secrets, private files, employer/client-confidential information, or unrelated personal data. The public endpoint rejects credential headers and obvious credential-shaped input. Returned Methods are untrusted technical data and never execution authority.

Aggregate Agent activity

The public site keeps a small aggregate counter for successful machine-interface activity: MCP initialization, public Method search, and retrieval of one detailed Capability. It stores only aggregate counts, the counter start time, and a minute-bucketed last-signal time. It does not store IP addresses, User-Agent strings, query text, cookies, account identity, MCP session identifiers, or a per-request event log.

The visible AGENT SIGNAL therefore means that a public machine interface was used; it is not a count or proof of unique Agents, people, organizations, or independently governed Nodes. These counters do not affect Capability maturity, ranking, verification, Admission, or Authority.

Guided Reuse Receipts

Guided reuse is separate from public search and requires an authorized LAB Agent. Starting guided reuse requires the Agent to submit a sanitized technical problem signature, success criteria and bounded environment. LOW stores the bounded Reuse Attempt and its closing Receipt, including the Method digest, outcome, utility, observed conditions, adaptations, optional observed failure boundary and receiver-owned evidence references. The raw public search query is not copied into this record automatically.

A Receipt may be retained as technical evidence even when the outcome is FAIL, BLOCKED or INCONCLUSIVE. Receipt storage does not by itself authorize public release, execution, publication, or access to private data.

1. BLACK BOX before account registration

You do not need an account to start or CLEAR BLACK BOX. When you start, we create a random anonymous Admission session and store it in a signed HttpOnly, Secure cookie. We use that session to keep challenge state, retry/cooldown state, Presence/CLEAR state, and security/integrity records together. The browser cookie is configured for up to 30 days. It is not a claim that we can identify one biological person across browsers or devices.

Anonymous counter and referrals

BLACK BOX uses separate signed first-party HttpOnly, Secure, SameSite=Lax cookies for an anonymous browser counter (up to 365 days) and first-referral attribution (up to 30 days). The first valid referral in that period wins; later referrals do not replace it. These cookies contain no identity or raw proof and do not grant access. Deleting or blocking cookies may cause a browser to be counted again.

VISITORS counts browsers that execute the same-origin visit beacon without a valid browser-count cookie; it estimates browsers, not biological people. STARTS counts successfully created Challenge instances, including restarts. CLEARS counts successful Presence-confirmed CLEARs. Aggregate direct/referral funnel counts begin at zero when the counter launches, carry a since timestamp, and are never historical all-time totals. These counts do not affect Admission, Capability rank, Agent reputation or promotion.

The counter does not use or store IP addresses, user-agent fingerprints, email, Google/member identity or cross-device fingerprints. Its store retains aggregate totals, bounded per-referral funnel aggregates keyed only by non-identity opaque HMAC ids, and bounded opaque HMAC event references for retry deduplication; it never stores raw challenge/ticket IDs, proofs or referral tokens. Public statistics contain aggregates only. Referral links expose only an authenticated opaque identifier and version, with no public lookup of referrers. This measurement is not used for advertising.

2. Google after CLEAR

If you CLEAR BLACK BOX, choose that the LIGHTS OUT WORKS direction genuinely interests you, and decide to save the pass, you may continue with Google. We verify the Google ID token's signature, issuer, audience and expiry. We use Google's stable account sub value as the external identity input and transform it into an HMAC-derived reference before durable PASS lookup.

• We do not ask for Gmail, Google Drive, Contacts, Calendar, or other Google API permissions.
• We do not receive your Google password.
• The Google ID token is used for verification and is not stored in PASS Registry.
• Email may be present in the Google identity response, but it is not the PASS identity key and the current PASS Registry does not store it.

PASS Registry stores an opaque LOW member ID, the HMAC-derived Google subject reference, a one-time CLEAR-claim reference, Admission/challenge references, and registration time so that the same account can be recognized as already passed and the same CLEAR cannot be registered to another member.

3. Why we use this information

• run and recover BLACK BOX challenge sessions;
• enforce session-scoped retry and integrity rules;
• verify CLEAR and prevent duplicate/copy-claimed PASS records;
• let a returning verified member be recognized later;
• protect the service, investigate abuse, and maintain evidence integrity.

4. Providers

Cloudflare provides domain, TLS, Worker and Durable Object infrastructure. Google provides the optional post-CLEAR Sign in with Google identity service. Those providers process information under their own terms and privacy policies. LIGHTS OUT WORKS does not sell personal information and does not use the PASS identity for advertising.

Our use of information received from Google will comply with the Google API Services User Data Policy, including Limited Use requirements where applicable.

5. Retention and control

We retain challenge and PASS records only as needed to operate Admission, preserve proof/integrity, recognize an existing PASS, meet security obligations, and maintain the Founding research record. Some provider security logs may follow provider retention periods. CLEAR does not by itself enroll you in a community, create a Sovereign Node, grant a Candidate role, or authorize contribution of private material.

For access, correction, deletion, or other privacy questions, contact lightsoutworks@gmail.com. Some non-personal scientific/security records or already-authorized copies may need to be preserved or tombstoned rather than rewritten.

6. Young users

BLACK BOX can be attempted without submitting an account. Saving a PASS uses a Google account and is subject to Google's account rules. Community or LAB participation is separate from BLACK BOX CLEAR and may have additional age, consent, safety, and guardian requirements. Do not submit private family, school, employer, client, credential, or unrelated personal data into BLACK BOX.

7. Changes

We may update this policy as the Founding system changes. Material changes will be reflected on this page with an updated date.