Privacy Policy

VQC Checker is built to minimize the information kept on its servers. This policy explains the information used to provide the web service.

Inspection packet files

Uploaded document files are read in your browser and are not stored by VQC Checker. Deterministic extraction and comparison run on your device. When a field is uncertain, the service may send compact extracted text and up to two compressed page images from that document to a protected server endpoint for an AI second opinion. For a signed-in packet check, the browser may also extract and send up to six organization names that are literally labeled as the supplier, vendor, seller, issuer, or company. VQC Checker stores only the organization name, label role, document categories, and document count—not the source line or original file—and shows it only to the owner as account context. This context does not prove the account holder’s employer. The full original file and the server API key are never sent to your browser.

Account and usage information

When you create an account, VQC Checker stores the email address and display name you supply, a slow salted one-way password hash, a one-way recovery-code hash, a hashed session token, plan, subscription status, monthly packet count, and basic timestamps. VQC Checker does not store your readable password or recovery code. The current standalone registration flow does not confirm ownership of the supplied email inbox. A successful sign-in proves that the VQC Checker account password was accepted, not that the email address or display name is the visitor’s legal identity.

Payments

Stripe processes checkout, payment methods, recurring charges, invoices, and billing management. VQC Checker stores Stripe customer and subscription identifiers but does not receive or store complete card or wallet credentials. The payment methods Stripe displays can depend on the buyer, browser, location, and provider availability.

Account support tickets

Only signed-in account holders can create or view support tickets. The ticket, account email, status, owner reply, and timestamps are stored so the customer and owner can communicate privately through their portals without email. Do not include controlled document content, payment credentials, passwords, or API keys in a ticket.

Website analytics

VQC Checker uses first-party analytics to understand page visits, approximate unique visitors, page journeys, landing pages, referring domains and their page paths, campaign tags, country, state or regional area, network and browser timezone, network owner and ASN, broad device type, operating-system family, browser family, primary browser language, coarse viewport class, signups, packet starts, checkout starts, and subscription starts. For a signed-in account, VQC Checker also records a server-side page-open event for the dashboard, account-security page, or support page. This works without browser scripts, is limited to one stored event per account page in each 30-minute period, and stores the page path rather than form values, ticket content, passwords, or document content. When present, utm_source=chatgpt.com or a ChatGPT referrer host is grouped into a 30-day ChatGPT traffic card using the same stored events. No additional visitor data is collected for that metric; a separately labeled ChatGPT-authenticated browser event is described below. The owner may create a private targeted-company link containing an opaque campaign token and may optionally add an expected recipient name or role and business email already known to the owner. A supplied recipient email must match the company website domain. New links put the random token in an opaque /r/ path so an email security or privacy system cannot remove attribution merely by stripping query parameters. The hosting edge necessarily receives that opaque path. It is marked noindex, nofollow, noarchive and no-referrer, is never included in the sitemap, and immediately redirects to the public homepage. For an eligible U.S. request without Global Privacy Control, the redirect also places the token in a first-party HTTP-only, Secure, SameSite handoff cookie for no more than 30 minutes. Page scripts cannot read it. This lets the server preserve the same link when scripts, session storage, or query parameters are unavailable. Page JavaScript still keeps current campaign context in that browser tab and removes the brief via handoff from the address bar when available. If JavaScript is disabled, the same-origin fallback can use the short-lived cookie or process the token from the page Referer. The application database stores only a one-way HMAC of the token in the link table and the internal link ID on an event, never the raw token. A private-link path fetch is stored separately from a landing-page event and is labeled unconfirmed because it may be an email-security scanner, blocked analytics, or an interrupted navigation rather than a person. The handoff cookie is not issued for non-U.S. or unknown locations and is deleted when the request is ineligible or Global Privacy Control is enabled. Expected-recipient details stay only on that owner-controlled link record and are not copied into individual visit events. Visit events store the selected company name, optional broad company domain, campaign label, and internal link ID—not the token or recipient details. A private outreach link can be forwarded, so its expected recipient is owner-supplied context and never proof of who clicked or of the visitor’s employer. A targeted company or expected recipient is marked independently corroborated only when the target agrees with a retained business network owner, registered IP allocation, registered autonomous system, business domain, or matching referring domain. Mixed and different-business signals are shown as such; company agreement still does not identify the individual visitor. When an expected business email is present, the owner dashboard compares it with any later account associated with the link. It separately labels a direct exact-email account session, a direct different account on the same company domain, a direct account on another domain, or a lower-confidence returning-browser or browser/network association. Account emails are registrant supplied; even an exact string match does not verify the email inbox or the person. The dashboard also counts distinct randomized returning-browser keys only among human-supported link visits. Multiple linked accounts produce a shared-or-forwarded warning, while multiple returning-browser keys produce a multi-device warning because they may represent one person on several devices or a forwarded link. Raw browser tokens are not stored, a shared browser may represent more than one person, and these classifications never prove who clicked. Deleting a link removes its token hash and expected-recipient details and unlinks its historical events, while those events retain only their non-recipient company and campaign context. Referring-page query strings and fragments are discarded. Network ownership may indicate a business, internet provider, VPN, or cloud service and does not prove a visitor’s identity or employer. A monthly rotating one-way signature is created from the request network, browser user-agent, coarse browser timezone, primary language, and viewport class. The raw network address and combined signature are not stored. This signature can show probable same-browser activity across separate tabs more selectively, but shared devices and identical workplace setups can still produce a wrong match. The browser also generates a random tab-scoped visit token so separate people using the same company network are less likely to be merged. The raw visit token stays only in that tab’s session storage; visit events receive only a monthly one-way HMAC, which cannot be used as a permanent cross-month fingerprint. For traffic that the hosting edge places in the United States, and only when Global Privacy Control is not enabled, the service may issue a random 128-bit returning-browser token as a first-party HTTP-only, Secure, SameSite cookie for up to 180 days. Page scripts cannot read the cookie. The raw value is not retained in analytics records; the server stores only its one-way HMAC. It can connect separate visits after a network or month change. A successful sign-in or authenticated product action can connect that browser to a VQC Checker account only when the same token has been observed with exactly one account. A token seen with more than one account is treated as ambiguous and does not assign anonymous activity to either account. A shared browser can still be used by another person, so this is labeled as browser continuity rather than individual identity. The cookie is not issued for non-U.S. or unknown locations and is deleted when the server reports the visit is ineligible or Global Privacy Control is enabled. An older returning-browser value in first-party local storage is migrated to the HTTP-only cookie when eligible and then removed from local storage. If page JavaScript is disabled, a hidden same-origin image request can record the public page path supplied by the browser's same-origin Referer header and can issue the same returning-browser cookie. The VQC Checker visitor-intelligence records retain only the path, a valid opaque via token, and the five standard utm_* campaign values; every other query value and the complete Referer URL are discarded from those records. It does not receive form values, passwords, ticket content, or document content. The fallback rejects outside and private-page referrers, excludes obvious bots, and honors Global Privacy Control before recording or issuing a cookie. Each JavaScript-enabled page activation sends a random one-time event token so a real reload or return can be recorded while delivery retries do not create extra page views. Only a one-way deduplication value is retained. When Daniel is authenticated through the VQC Checker account or a verified ChatGPT browser session and visits a public marketing page, VQC Checker can instead retain a separate owner test record. It uses the authenticated owner context as its stable subject, does not issue or reuse a returning-browser token, skips network enrichment and derived browser, transport, and network association keys, and appears only in the owner's recent-visitor screen. Owner tests are excluded from visitor totals, funnels, organization leads, and recognition learning. Private admin, dashboard, account, and support page opens are not owner tests. This owner-test handling honors Global Privacy Control. Normal browser owner checks still use obvious-bot filtering; a verified ChatGPT browser session is accepted from its authenticated context rather than a generic user-agent label. Speculative prefetch and prerender loads are not counted as visits unless the document is activated and becomes visible. On public pages, VQC Checker records whether a tab remained visible for 12 seconds, whether a trusted pointer, keyboard, or touch interaction occurred, and whether the browser reports automation. Security-link wrapper domains alone are not treated as proof of automation because a real person may arrive through them. When Cloudflare Bot Management data is available, VQC Checker retains only a coarse likely-human or automated classification; it does not retain the underlying bot score, JA3 or JA4 value, TLS fingerprint, or detection identifiers. These signals help separate likely people from scanners but do not identify a person. The coarse browser, language, viewport, and timezone signals help explain and corroborate a visit but do not identify a person. After a successful sign-in, the exact visit session is associated with the authenticated VQC Checker account when its tab token is available. Separate tabs with the same monthly signature may be labeled as a probable match to that account only when the signature maps to exactly one account; a signature associated with multiple accounts remains anonymous. This is activity evidence, not proof that the account holder personally made every matched visit. For a non-public business-email domain, the owner dashboard also compares that domain with independent business network, registered allocation, ASN, retained domain, and referring-domain evidence. It labels agreement, mixed evidence, differences, or a lack of independent evidence without claiming the inbox or individual is verified. The service may also make an encrypted public MX-record query through Cloudflare DNS for that business domain. Cloudflare receives the domain. VQC Checker retains only a hashed domain cache key and whether public mail routing was observed, was not observed, or the lookup was inconclusive, for up to seven days; it does not retain MX hostnames or raw DNS answers. Public mail routing supports domain plausibility only. It does not verify the inbox, visitor, legal identity, employer, or company match, and it does not upgrade the account's confidence label. For an already-observed non-public business domain from an account, retained business-network domain, or human-supported outside business referrer, VQC Checker may also use IANA's public DNS RDAP bootstrap file to send the domain to the authoritative top-level-domain registry. It retains only a hashed cache key, a non-generic organization-level registrant when one is published, the registry hostname, and lookup status for up to 30 days; inconclusive lookups expire after one hour. Contact names, individual registrants, email addresses, phone numbers, postal addresses, privacy-proxy and redacted records, and raw registry responses are discarded. A registered organization may be a holding or administrative company. This evidence describes domain registration only and does not prove who visited, employment, authorization, or control of an email inbox. It never upgrades person-level confidence. Labeled packet organization names may appear beside that signed-in account as unverified document context. For up to 90 days, VQC Checker may also derive a company-level network association when a registrant-supplied non-public business-email domain agrees with a forward-confirmed business network domain, an authoritative registered customer allocation, or a fully corroborated business-owned ASN on authenticated activity. Allocation names and organizations are namespaced by the authoritative registry and can be reused only when the registered allocation evidence itself matches the business domain; the parent carrier ASN is not treated as the customer. A later anonymous visit using that same domain, allocation, or qualifying ASN may be labeled with the recognized business domain and the number and recency of distinct signed-in account records previously observed there. The owner-only dashboard may also show up to five of those first-party accounts’ display names, registrant-supplied emails, and last authenticated timestamps as a possible candidate pool. Before that owner-facing shortlist is displayed, ranking may privately compare up to 48 of the most recently authenticated distinct accounts on that qualifying network and retain no more than twelve for downstream processing. This prevents a strong older resemblance from being excluded merely because twelve newer accounts exist, while keeping the owner-facing list bounded. Candidate-frequency denominators can reflect that full comparison pool. These values already belong to VQC Checker account records; they are not obtained from a data broker, and expanding the comparison pool collects no additional visitor data. No candidate is assigned to the current anonymous visit, including when only one account is listed. When at least three traits are comparable, the candidate list may be ordered using equality checks across the already-retained coarse browser family, operating system, device class, browser timezone, primary language, and viewport bucket. Each account can contribute no more than four deduplicated coarse profiles with at least three available traits from that same 90-day window, so a recent alternate authenticated device is not discarded merely because the account later used another device. Only the best comparison is used. If resemblance, current-network support, and candidate-frequency comparisons still tie, the relative freshness of that best profile may break the tie. The dashboard can show only whether it was the newest, second-newest, third-newest, or fourth-newest retained profile. It does not expose the profile timestamp or an age. This uses only the existing retained-profile order, collects no new data, and remains part of the coarse-browser evidence family. The dashboard shows both the agreeing and differing trait labels and the number of retained profiles. Raw profile values, other comparisons, and profile timestamps are hidden. Multiple devices, shared browsers, and standardized workplace devices increase the chance of resemblance, so this comparison does not upgrade identity confidence. The dashboard does not expose raw user-agent strings, exact display dimensions, or a probability. When browser resemblance ties, candidate-level current-network support is ordered from a matching forward-confirmed business domain, to a matching authoritative customer allocation, to a matching registered business-owned ASN. Multiple independently matching network types can break a further tie, and the dashboard shows the types supporting each candidate. This reuses the same qualifying company-network evidence; it does not prove the person using that network. If the resemblance ratio and current-network support still tie and at least three traits agree, the list may first count how many candidate accounts have all of those agreeing values together on one retained authenticated profile. Traits from separate profiles are never combined into a synthetic device. The dashboard shows only the number of agreeing traits and candidate accounts, not the values. If that joint frequency ties, matching coarse traits may be inverse-frequency weighted individually inside that candidate pool. Each candidate account counts at most once for a trait even when several retained profiles contain the same value. The dashboard shows only the agreeing trait label and how many candidate accounts shared the current visit's value; the value itself and every nonmatching retained value remain hidden. A one-account combination still does not mean unique to a person; rarer does not mean unique to a person. These refinements collect no new data. The weighting remains inside the coarse-browser evidence family, does not upgrade identity confidence, and is not a probability. If these observations tie and the visit used an owner-created private link, an exact normalized match between the link's owner-supplied expected-recipient business email and one candidate account email may place that candidate next. The expected email remains only on the private-link record and is not copied onto visit events. The dashboard labels this as an owner expectation, not observed identity: the link may be forwarded, the account email is registrant supplied, and neither value verifies an inbox or person. As the most specific behavioral comparison, the list may bind four already-retained facts from the same specialized-page interval: the accepted acquisition context, strongest binary engagement, exact next specialized-page transition, and the first page's coarse UTC activity window. The exact timestamp is reduced to weekday or weekend plus one of four six-hour windows and discarded before ranking. This fully bound comparison requires the tab-scoped session key and never falls back to a visitor or returning-browser key. The dashboard shows no more than two fully bound session journeys with candidate frequency and hides unmatched full contexts. A matching full context is not counted again as its source-and-engagement or time component. If those two components exist only in separate historical session observations, the dashboard labels the timing separation and withholds the component rows at this stage instead of implying all four facts occurred together. Genuinely uncombined observations remain eligible for the later comparisons. This adds no collection, exact time, date, local schedule, or probability. Coworkers on the same shift, shared browsers, forwarded links, and automated scanners can reproduce the full pattern, so it remains candidate-ordering evidence and never raises identity confidence. The list may next compare the pace of that exact same-session specialized-page transition. It derives this only from the two page timestamps already used to order the transition, immediately reduces the interval to one of four broad bands—under 30 seconds, 30 seconds to under 2 minutes, 2 to under 10 minutes, or 10 to 30 minutes—and discards the exact interval before ranking. Gaps over 30 minutes are treated as idle and are not compared. The dashboard shows no more than two matching same-session pace journeys with candidate frequency and hides unmatched pace history. This adds no collection and remains inside the existing same-session evidence family rather than counting as independent support. Shared browsers, coworkers following the same workflow, and automated scanners can reproduce a pace band, so it is only an inverse-frequency tie-breaker and never raises identity confidence. Before comparing the source, engagement, or sequence parts separately, the list may bind all three existing facts from one specialized-page interval: an accepted acquisition context on the first path, its strongest binary engagement, and the exact next specialized-page transition. The engagement must occur after that first page opens and before the next specialized page in the same tab-scoped session. The comparison requires the session key and never falls back to a visitor or returning-browser key. It accepts only the sanitized campaign or validated outside-business referrer and the 12-second visible threshold or trusted pointer, keyboard, or touch interaction already described here. The dashboard shows no more than two matching same-session source-and-engagement journeys with candidate frequency and hides unmatched combined journeys. It does not count a matched combined observation again as separate same-session source and engagement journeys. If a candidate has both component matches only in separate historical session observations, the dashboard labels that separation and withholds those component rows from this stage instead of implying they occurred together. Other genuinely uncombined session observations remain eligible for their separate comparisons. This correlation rule does not collect any additional data. It does not expose query strings, coordinates, clicked elements, key values, scroll behavior, or exact duration. Forwarded links, shared browsers, coworkers following the same workflow, and automated scanners can reproduce the combined pattern, so it is candidate-ordering evidence only and never raises identity confidence. Before comparing source or sequence separately, the list may bind an accepted acquisition context on the first specialized page to the exact next specialized-page transition inside that same first-party visit. This joint comparison accepts only the sanitized campaign or validated outside-business referrer rules described below, requires the random tab-scoped session key, and never falls back to a broader visitor or returning-browser key. The session key and timestamp are discarded before candidate ranking. The dashboard shows no more than two matching same-session source journeys with candidate frequency and hides unmatched source journeys. A forwarded campaign or private link, shared browser, or email-security scanner can reproduce this joint pattern, so it remains candidate ordering evidence and never raises identity confidence. The list may next bind the strongest existing binary engagement on that first specialized path to its exact next specialized-page transition, but only when the engagement occurred after the first page opened and before that next specialized page in the same tab-scoped session. This comparison requires the session key and never falls back to a visitor or returning-browser key. It uses only the already-recorded 12-second visible threshold or a trusted pointer, keyboard, or touch interaction. The dashboard shows no more than two matching same-session engagement journeys with candidate frequency and hides unmatched engagement journeys. It does not retain or reveal coordinates, clicked elements, key values, scroll behavior, or exact duration through this comparison. Shared browsers, common workflows, and automated scanners can reproduce the pattern, so it never raises identity confidence. The list may next bind that exact same-session transition to the first page's coarse UTC activity window. Before ranking, the exact timestamp is reduced to only weekday or weekend plus one of four six-hour windows and then discarded. The dashboard shows no more than two matching same-session time journeys with candidate frequency and hides unmatched time journeys. Coworkers on the same shift, shared browsers, and automated scanners can reproduce this pattern, so it never raises identity confidence. After the stronger browser, network, owner-routing, and exact same-session comparisons tie, the list may compare support breadth across no more than seven generic evidence families: current business network, sufficiently strong coarse browser resemblance, owner routing expectation, same-session context, public-page workflow, acquisition context, and coarse place or time. The current business network is only the candidate-pool baseline. Coarse browser resemblance enters this breadth label only with at least three agreeing traits and at least 75 percent agreement among three or more comparable traits. Correlated details inside one family count once, and separation warnings do not count as support. The dashboard labels network-only, one-additional-family, or multiple-family support and shows only the generic family names. This is a later tie-breaker, not a statistical probability, independence claim, identity score, or confidence upgrade, and it collects no new data. As a later visible tie-breaker, the list may compare the exact combination of a specialized public path and its acquisition context on the same page-view event. Acquisition context is limited to the same sanitizedutm_source plus non-generic utm_campaign pair or validated outside business referrer described below. The dashboard shows no more than two shared page-source pairings with candidate frequency and hides every unmatched pairing. Query strings, campaign content or term values, direct traffic, personal profiles, and generic or rejected referrers cannot enter this comparison. Forwarded campaign and private links can reproduce the same pairing, so it does not raise identity confidence. Before the broader sequence comparison, the list may compare an exact adjacent specialized-page transition contained within one first-party visit. Repeated paths inside that visit are collapsed to their first occurrence. This requires the random tab-scoped session key and does not fall back to a broader visitor or returning-browser key when session storage is unavailable. The one-way session key is used only to group events and is never copied into candidate evidence or displayed. The dashboard shows no more than two shared same-session transitions with candidate frequency and hides every unmatched transition. It does not expose timestamps, dates, time gaps, or session keys. A forwarded link, shared browser, or email-security scanner can still create a same-session sequence that is not one person's deliberate journey, so the match does not raise identity confidence. The list may then compare broader exact adjacent transitions in the first-seen order of public /xometry-vqc and /resources/... pages. Repeated page opens are collapsed to the first occurrence. The dashboard shows no more than two shared transitions and the candidate-account frequency supporting each; it does not show timestamps, time gaps, or a candidate's unmatched sequence history. Because this broader order can span separate visits, it ranks after the same-session sequence. A shared sequence may reflect a common workflow or forwarded link and does not raise identity confidence. The list may next compare an exact binary engagement type on the same specialized public path: either the already-recorded 12-second visible threshold or a trusted pointer, keyboard, or touch interaction. The dashboard shows no more than two shared path-and-engagement labels with candidate frequency. It does not retain or reveal interaction coordinates, clicked elements, key values, scroll behavior, exact durations, or a candidate's unmatched engagement history. Common workplace tasks can produce the same engagement pattern, so it remains tie-breaking evidence only. The list may then compare the exact specialized public path and coarse activity window from the same page-view event. The window is only weekday or weekend plus one of four six-hour UTC categories. The dashboard shows no more than two shared page-time pairings with candidate frequency and hides every unmatched pairing. Exact timestamps, dates, time gaps, local schedules, and visit counts are not retained or exposed by this comparison. Coworkers on the same shift may open the same resource, so this remains tie-breaking evidence and does not raise identity confidence. After that, the list may also use exact unordered overlap among the public /xometry-vqc and /resources/... pages used during authenticated activity on that qualifying network and the current anonymous visit. Home, login, dashboard, account, support, privacy, terms, token, and other private or generic routes are excluded. The dashboard shows no more than four shared public paths. Those paths are inverse-frequency weighted within that network's candidate pool, so a path observed on fewer candidate accounts can break a tie ahead of a commonly observed path. The dashboard shows the candidate-account frequency supporting each shared path, not a probability, and does not expose a candidate's other page history. Frequencies reflect only incomplete first-party activity observed during the prior 90 days. After browser, network-specificity, and specialized-page evidence, a shared acquisition tie-breaker may compare either an exact sanitized utm_source plus non-generic utm_campaign pair or a referrer already accepted as a distinctive outside business website, LinkedIn company page, or Crunchbase organization profile. Direct traffic, query strings,utm_content, utm_term, personal profiles, search and social homepages, email-security wrappers, public-email sites, generic campaign labels, and non-business referrers are excluded. The dashboard shows no more than two exact shared labels and the candidate-account frequency supporting each; it does not expose a candidate's unmatched campaign or referrer history. Campaign links can be forwarded, referrers can be suppressed or misleading, and coworkers may share acquisition channels, so this is only tie-breaking evidence and never raises identity confidence. After that, a broad-region tie-breaker may compare the already-retained two-letter country and state, province, or comparable regional-area label. Only a region shared with the current visit and its candidate frequency may be shown. Coordinate-like values are rejected; city, postal code, coordinates, and a candidate's nonmatching region history are not collected or exposed by this comparison. Corporate gateways, VPNs, and IP geolocation can place different people in one region or report the wrong region. After that, another tie-breaker may compare coarse activity windows derived from the same stored event timestamps. Each timestamp is reduced to weekday or weekend plus one of four six-hour UTC windows, for only eight possible categories. The dashboard shows no more than two matching window labels and how many candidate accounts were observed in each; it does not expose exact timestamps, dates, local schedules, visit counts, or a candidate's nonmatching windows. People with the same shifts or work duties can use the same devices and resources, so this ordering does not upgrade identity confidence or establish that any candidate made the visit. The derivation uses existing visitor-intelligence records and stores no new raw IP address or fingerprint. Public-email domains, automated activity, generic allocations, carriers by themselves, VPNs, cloud providers, uncorroborated ASNs, and any network key associated with conflicting business domains are excluded. This is company-level continuity only: the later visitor remains anonymous, and the association does not verify a person, email inbox, employment, or authority. The service does not guess an anonymous visitor’s real name or email. When the hosting edge does not provide ASN ownership, VQC Checker sends the request IP to the atlas.ipinfo.app lookup service and retains only the returned country, ASN, and organization; that provider states that request logs are normally retained for no more than 14 days. For a network already classified as a possible business, VQC Checker may make an encrypted PTR query through Cloudflare’s public DNS resolver, resolve the returned hostname forward, and retain its broad domain only when it resolves back to the same public address and matches the network organization. VQC Checker may also query PeeringDB using only the public ASN. The full PTR hostname is discarded. A PeeringDB website domain is retained only for an active, matching Enterprise record. For a public IP outside a known cloud or VPN network, VQC Checker may use IANA’s RDAP bootstrap registries to query the authoritative regional Internet registry for the most-specific address allocation and, when an ASN is available, the registered autonomous system. The address registry receives the public IP; the autonomous-system registry receives only the ASN. VQC Checker retains only a non-generic organization name, the registry name, a broad matching domain when available, and a non-generic registration-holder network name. The network name is used only when it matches an owner-targeted company or signed-in business-account domain; by itself it does not create an organization lead. Public RDAP contact URLs or email addresses are processed transiently only to derive that matching domain; full contacts, individuals, postal addresses, and raw registry responses are discarded. Private-customer, private-residence, individual, carrier, provider, generic, VPN, cloud, and mismatched results are rejected. A referring domain can be marked as matching only when it independently agrees with the business network, registered allocation, autonomous system, or retained domain. VQC Checker does not store raw IP addresses, full PTR hostnames, exact city-level locations, precise coordinates, complete browser identifiers, packet source lines, or original files in analytics records. Obvious automated traffic is filtered, Global Privacy Control is honored before visit-session, returning-browser, targeted-link, or other analytics processing in the browser and is honored again in server processing, access is limited to the owner account, and analytics events are retained for up to 400 days; cached network lookup results expire after seven days.

As a lower-confidence fallback when the public IP changes, VQC Checker may create a separate monthly one-way key from the network ASN and country plus the same coarse browser signals. It is used only when the original visit and an account sign-in occur within 24 hours, the key maps to exactly one account, and no stronger session or exact-network match exists. The raw combined value is not stored. The dashboard labels this as a probable same-network/browser match; standardized workplace devices, shared devices, carrier networks, and VPNs can still make it wrong.

For the same eligible U.S. traffic, the browser may locally assemble a coarse platform, architecture, bitness, model family, operating system version family, memory bucket, processor-count bucket, touch capability, orientation-independent display bucket, pixel-ratio bucket, color depth, language set, and timezone. Where supported, the platform fields come from the browser's User-Agent Client Hints API. The complete local set is SHA-256 hashed inside the browser; raw hardware, display, and high-entropy Client Hint values are not sent to VQC Checker. The server validates that digest, HMACs it again with a monthly rotating secret, stores only the second HMAC, and uses it only as a lower-confidence account-continuity fallback when a visit and a unique account event occur within 72 hours and stronger signals are absent. A key associated with multiple accounts remains anonymous. Shared or standardized devices can collide, browser privacy defenses may return empty or fictitious values, and software or hardware changes can break continuity. This signal does not identify a person, verify an inbox, or prove who used the device. It is not generated or stored when Global Privacy Control is enabled. VQC Checker publishes its GPC support at /.well-known/gpc.json.

For eligible U.S. requests without Global Privacy Control, the Cloudflare edge may also supply JA4, JA3, or hashed TLS ClientHello cipher and extension characteristics. The edge worker immediately replaces the available characteristics with a monthly one-way HMAC before the request reaches the application. The raw JA4, JA3, cipher, and extension values never leave the worker and are not stored in the application database. The application combines that rotating key with the coarse browser family, user-agent, timezone, primary language, and viewport class and stores only another one-way HMAC. This separate transport/browser fallback can associate a visit across a network change with a VQC Checker account only when an account event occurs within 24 hours and the key maps to exactly one account. More than one account makes the key ambiguous and prevents assignment. Standardized browser and TLS stacks can produce the same characteristics, so the dashboard labels this as a lower-confidence probable association. It does not identify a person, verify an email inbox, or prove that an account holder made the visit.

For an eligible U.S. request without Global Privacy Control, the Sites platform may forward a signed-in ChatGPT user's email and optional display name when the site is opened through the official ChatGPT browser. VQC Checker accepts that identity only when Cloudflare independently marks the request as a signed Web Bot Auth agent and the verified Signature-Agent identifies the ChatGPT browser-rendering service. The edge removes the incoming OpenAI identity and signature headers before the application runs and forwards only the validated identity through private internal headers. Unsigned, differently signed, non-U.S., and Global Privacy Control requests are discarded. For an accepted request, the application retains the platform-authenticated email, optional display name, and an agent-mediated flag with the visitor-intelligence event for up to 400 days. A direct signed-agent event does not issue a returning-browser cookie or perform network enrichment. Daniel-owner requests are retained only as the separate owner tests described above and do not enter customer visitor totals.

When that verified request arrives on the native Sites hostname, VQC Checker may automatically carry it to the branded vqcchecker.com hostname without asking the visitor to type or submit anything. The email, optional name, requested public path, and a ten-minute expiration are encrypted with authenticated encryption inside an opaque one-time token. The database stores only a keyed one-way hash of that token for replay protection—not another readable copy of the identity—and the intermediate path is excluded from robots, sends no-referrer and noindex headers, and immediately replaces itself with the requested public page. Expired, altered, replayed, non-U.S., Global Privacy Control, and unsigned handoffs are rejected. A Daniel-owner handoff can create only a separate owner test record. On the branded landing page, the eligible first-party randomized returning-browser cookie described above may be issued. Later pages can be associated with the earlier ChatGPT account context only when that one-way browser key has been linked to exactly one ChatGPT identity and does not conflict with a VQC Checker account. Those later pages are labeled returning-browser continuity, not authenticated visits, because a shared browser can be the wrong person. The email identifies the ChatGPT account context presented by the hosting platform. Because the original request travels through an agent, it does not prove that the person personally viewed each page, owns a similarly named company, or authorized a business action.

As a separate corroboration exception, an authoritative RDAP registration-holder or non-generic customer network name may create a company-level organization clue when it agrees with either a non-public website or email domain in the same registry record, a forward-confirmed reverse-DNS business domain, or a distinctive customer label inside the PTR hostname—even if the visible domain and ASN belong to a carrier. Recognized public-email, carrier, generic, individual, and mismatched contacts are rejected. For a carrier-owned PTR domain, at least one distinctive token from the registered customer name must appear before the carrier domain; generic company and industry words are ignored. PTR hostnames must resolve back to the same public address. The full hostname, contact address, and raw registry response are discarded. This identifies only a possible business network, never a person.

As separately labeled exceptions to the network-referrer comparison above, an outside referrer matching a targeted-company or business-account domain may corroborate that company context even when the network is a carrier, ISP, or VPN. A referrer path matching the official LinkedIn /company/ or Crunchbase /organization/ pattern may also corroborate company context when its distinctive organization name agrees with the targeted company or business-account domain. Personal-profile paths, generic industry words, and nonmatching profiles are rejected. Independently of those matches, a visit with human-activity evidence may show a distinctive outside business website domain or an official LinkedIn company or Crunchbase organization path as low-confidence referring-company context. Search engines, social homepages, public-email and hosting services, security or link-wrapper domains, personal profiles, generic-only names, and automated visits are excluded. This context describes only the outside page from which the browser arrived; it does not identify the visitor, prove employment or authorization, or change an anonymous visitor into an identified person. These clues do not verify the individual visitor or employment. The owner dashboard also calculates visit-intent labels and scores from page views, related visit tabs and active days, signed-in status, the human or automation signals described above, and already-recorded signup, packet-start, checkout, subscription, and support events. For a private outreach link, the same tab’s opaque link token may accompany its human or automation signals and a later sign-in or registration so the owner can distinguish scanner-only activity, likely-person activity, and a linked account. For 30 days after that linked visit, the dashboard may show whether the linked account generated signup, packet-start, checkout, subscription, or support events. The readable token is processed only to find the owner-created link and is not stored in visit events. Intent and link activity describe observed behavior and are not identity proof; a forwarded link can associate the activity with someone other than the expected recipient.

Security and service providers

VQC Checker uses slow salted password hashing, one-way recovery-code hashing, login throttling, hashed session tokens, secure HTTP-only cookies, same-origin checks, server-side authorization, usage limits, one-time AI run records, webhook signature verification, and security headers. Sign-in is handled directly by VQC Checker; OpenAI may process limited uncertain document evidence, Stripe processes billing, atlas.ipinfo.app provides fallback IP-to-ASN network ownership data, PeeringDB provides public ASN network records, IANA supplies authoritative RDAP routing data, the applicable regional Internet registry supplies public address-allocation and autonomous-system records, and Cloudflare provides hosting, the database, and the optional public DNS resolver. No internet service can promise absolute security.

Retention and deletion

Account, usage, billing, support-ticket, and owner-created outreach-link records are kept only as reasonably necessary to operate the service, prevent abuse, resolve disputes, and meet accounting or legal requirements. The owner can deactivate or permanently delete an outreach link at any time. Permanent deletion removes its token hash and expected-recipient details and disconnects the link from historical events. Aggregate analytics events are automatically removed after 400 days. Stored packet organization context is hidden after 90 days and cleared during routine service use. A signed-in account holder can request account or ticket deletion through the private support portal.

Controlled or restricted information

Do not submit ITAR-controlled, export-controlled, classified, or other restricted information unless your organization has independently determined that the complete processing flow is authorized for that information.

Questions or requests

Registered customers can sign in to the VQC Checker Support portal to create a ticket and read the owner’s reply. VQC Checker does not provide a public contact form, support email, or physical support address.