Terms & Privacy

Summary

WhiteMagic software runs locally by default; product usage sharing is off unless you explicitly enable it. If you enable the optional install-funnel report, it sends a random, rotatable install ID, version, operating system, architecture, install channel and optional referral code, first-launch time, milestone names, active-day offsets, and session and memory counts. It does not send memory text, prompts, paths, hostnames, or IP addresses. Each per-install record has a configured 180-day expiry that resets when a new report updates it; daily funnel aggregates have a 180-day periodic-cleanup target, so cleanup may not occur exactly on schedule.

Separately, the site exposes an opt-in product telemetry endpoint. Its strict allowlist accepts a version, operating system and architecture, optional client family and install channel, bounded counts for named lifecycle, memory, recall, tool, dream, backup and restore events, and named latency buckets. Basic mode stores daily aggregate counters without an identifier. Optional longitudinal mode accepts a client-generated rotating ID and stores a salted hash with a 60-day periodic-cleanup target; this is pseudonymous telemetry and does not guarantee that information could never be associated with a person. The endpoint has no field for prompts, memory content, paths, code or names and does not read or store IP addresses. The endpoint's availability does not mean every core client sends telemetry. Product telemetry counters have a 90-day periodic-cleanup target; the longitudinal records have a 60-day target, and cleanup may not occur exactly on schedule.

Data is sent to a hosted service when you choose to use or connect to it; the service processes requests and some services keep records described below. A third-party platform you connect has its own privacy practices.

This website

Site analytics stores hourly and daily aggregate request counts by visitor class and normalized route family, coarse country, language bucket, navigation type, referring host, and selected crawler family. It also counts page views, JavaScript loads, scroll-depth milestones, active-time buckets, and broad outbound destination categories. Browser interaction beacons use no cookie or stable visitor ID and are skipped when Do Not Track or Global Privacy Control is enabled; the server-side aggregate counters are derived from request metadata and are not gated by browser DNT/GPC signals. The pipeline does not store visitor IP addresses, raw User-Agent values, full referrer URLs, or full outbound URLs. Hourly analytics counters have a 14-day expiry target and daily analytics counters a 90-day target, maintained by a scheduled cleanup job, so cleanup may not occur exactly on schedule. Contact and feedback submissions have a separate rate-limit counter described below.

Contact and feedback forms

If you submit a contact request or feedback, the site stores the message, any email address you provide, its topic or category, submission time, and a reference number for review. Feedback can include diagnostics you choose to paste. Message records are configured to expire after 90 days. Anti-abuse rate limits use a daily rate-limit key that includes your IP address; those counter keys have a two-day expiry target maintained by a periodic cleanup job, so expiry is not necessarily immediate at midnight. A notification may be sent to the lab inbox. Please do not include secrets.

Hosted recall lane (mcp.whitemagic.dev)

The service processes the request body and response content in memory to answer a recall call; it does not add your query or returned recall content to the curated corpus. For rate limits, access review, and abuse prevention, the gateway writes request audit entries that can include a key name or “unknown”, timestamp, HTTP method and status, byte count, normalized route, JSON-RPC method, tool name, client family, bounded User-Agent family, latency, and decision details. Tool arguments, query text, response content, bearer tokens, and raw User-Agent strings are not written to these audit entries. For an unrecognized non-empty User-Agent, a truncated SHA-256 fingerprint is recorded for recurring-client correlation.

The anonymous trial limit uses the client IP in an in-memory per-day counter; the trial counter does not itself write the IP to disk. The faucet uses the request IP and, when supplied, a payer/address identifier to enforce daily and global claim limits. Faucet audit entries include the IP and payer identifier on grant and IP/payer-limit outcomes, so these identifiers can be present in persistent gateway audit logs. Counters are held in process memory, and their cleanup depends on service restarts and implementation. Keys can be revoked on request.

OAuth and connected platforms

If you use OAuth, the hosted service stores authorization state needed to validate and revoke the grant, including a hash of the access token, granted scope, and usage counters; it does not store the bearer token as the token value. Connected platforms send requests to the hosted service and receive its responses. Some operational call data is also sent to Glimind (a third-party reliability-monitoring service) for service reliability monitoring: bounded tool name, HTTP status, latency, service labels, and an error class. The feed excludes arguments, results, payloads, tokens, keys, and IP addresses. Glimind's receipt and retention practices are governed by its own terms and privacy policy. You can revoke an OAuth grant at the service's revoke endpoint; contact us to request deletion of grant-related data. Revocation and a deletion request do not automatically remove separate security, accounting, or service records that must remain for their stated purpose.

Verification API and optional stored data

A standard receipt verification request is evaluated in memory and its submitted bundle is not stored or logged as bundle content. The optional in-memory verification cache is keyed by a digest and has a 15-minute code-configured lifetime. The evaluation endpoint accepts Add, Search, and Delete operations against participant-isolated evaluation storage; submitted evaluation records are stored to support those operations, and no general expiry schedule is published. Other endpoints intentionally persist data when used: revocation documents, OpenTimestamps anchor proofs, payment settlement receipts, caller-claim notarizations, and client-encrypted Memory Crystal ciphertext. A notarization stores caller-supplied digests and bounded claims, not the underlying prompt, context, or execution. Crystal metadata and ciphertext are stored server-side; encryption keys remain with the client. The service also keeps assertion-replay nonces until their assertion expiry plus a clock-skew allowance, and retains service signing keys. These records do not have a general automatic deletion period documented here. Stored anchors, receipts, revocations and notarizations may be retrievable by their public identifiers. Contact us about a deletion request for a stored object; ownership verification may be needed. Verification and storage behavior is described on the hosted page.

Retention and contact

Contact and feedback messages have the 90-day configured expiry described above. Gateway audit logs have a 90-day retention target under periodic rotation; old archives may not expire immediately. Backups of the hosted store and durable authorization state retain up to four weekly remote and twelve weekly local copies; service records removed from active storage may remain in those backups. Audit logs are excluded from that backup set. Replay nonces are kept through assertion expiry plus the clock-skew allowance. Other durable state, including owner mappings, service signing keys, receipts, and crystal ciphertext, has no general expiry schedule. For questions or requests about data, email lab@whitemagic.dev.