Private Verification Tokens: Chrome's Proposal and BotBrowser Today

Private browsing needs a careful trust boundary

Private browsing is meant to reduce the amount of local state that a browser keeps and to separate a session from ordinary browsing. That boundary is useful for people who share a computer, research sensitive topics, test a fresh user journey, or simply do not want every visit tied to their regular profile.

The same boundary can create a difficult experience on the web. A site may receive a request without the cookies, local storage, or other state that it normally uses to recognize a returning user. A genuine person in a private window can therefore look similar to a newly cleared or automated client. The site may respond with an additional check, a slower flow, or a block even when the user is doing something ordinary.

Chrome is exploring one possible way to reduce that ambiguity: Private Verification Tokens, usually shortened to PVT. The proposal is interesting because it tries to carry a narrow trust signal into a private session without carrying the person's browsing history or identity with it. It is also easy to misunderstand. PVT is not a finished browser contract, not a promise that a site will accept a visitor, and not a feature that developers should assume is available today.

This article explains the public design at a level useful for privacy researchers, site operators, and browser teams. It separates the proposal from the platform status, describes the questions that still need evidence, and documents BotBrowser's current position.

What PVT is

The public explainer describes PVT as a privacy-preserving mechanism for a registered site. In the design sketch, a site can establish a trust relationship during regular browsing. The browser stores a token associated with that site. If the person later opens a private context, a request to the same site may include a limited verification result.

The useful distinction is between a trust statement and an identity statement. A PVT-style signal is intended to answer a narrow question such as whether the browser previously received a valid signal for this site. It is not intended to tell the site who the person is, which regular pages they visited, or which regular session produced the signal. The design also describes restrictions around the site scope and the circumstances in which a private context can use the token.

The proposal uses the same effective registrable domain, often described as the same eTLD+1, as an important boundary. That matters because a site-scoped relationship is less revealing than a token that can be presented to unrelated sites. The exact registration, issuance, redemption, and privacy rules remain part of the design and implementation work. They should be read from the current official documents rather than inferred from a feature name or a single request header.

The public design also discusses cookie-less requests and a Sec-Private-Verification-Token header. That header name describes the proposed protocol surface. It does not mean that every Chrome request carries it, that every site can request it, or that an implementation has shipped. A browser team evaluating the proposal should treat the header, token storage, and context transition as a coordinated design, not as independent switches.

Proposal, experiment, or shipped feature?

These labels have different operational consequences.

The official explainer calls PVT an early design sketch and states that it has not been approved to ship in Chrome. Chrome Platform Status currently lists the feature as proposed and not released. The status page includes milestone fields in the Chrome 154 through 165 range, but milestone fields in a proposal are not evidence that a feature is enabled for the general web. Registration, review, implementation, privacy evaluation, and release decisions can all change before a stable browser exposes a feature.

The public record currently has no signal from Firefox or Safari/WebKit. That means there is no public implementation commitment to use as a cross-browser baseline today. It does not mean that either project has rejected the idea or will never work on a related design. Browser support statements should therefore include a date and a source, and should avoid turning an absence of signal into a prediction.

For site operators, the practical conclusion is simple: do not build a production decision that assumes PVT is available. Detecting a proposed header, a browser brand, or a milestone string is not the same as proving that the protocol is enabled and usable. A site that needs to distinguish a returning private user from a newly cleared client should continue to design a clear, privacy-respecting fallback.

Why the proposal matters to privacy-focused browsers

PVT is aimed at a real tension. Private browsing should not require a person to accept unnecessary tracking merely to avoid being treated as suspicious. A narrowly scoped verification result could reduce false positives while avoiding a durable identifier that follows the person across unrelated services.

That goal is compatible with privacy only if the boundaries hold in practice. A privacy-focused browser must ask more than whether a request appears trusted. It must ask what information leaves each context, what can be correlated, and whether the behavior remains understandable to the user.

Important questions include:

• What exact event authorizes issuance in a regular context?
• Can the site learn more than a bounded verification result from redemption?
• Can separate identities share a token accidentally?
• Can a token be replayed, linked across sites, or used as a long-lived identifier?
• What happens when a user deletes site data or creates a new profile?
• Is the result consistent across tabs, workers, embedded frames, and private contexts?
• Can a user or administrator tell when the mechanism is active?

The answers depend on the final protocol and browser implementation. They cannot be established by reading a feature label or by observing a single successful navigation. They need documented tests, negative cases, and a clear statement of what the browser does not expose.

A practical evaluation model

Teams evaluating PVT should begin with a threat model and a test matrix. The threat model should name the privacy property being protected, the party that may receive a signal, and the correlation that must remain impossible or difficult. Avoid a test plan that measures only whether a page loads. A page can load while a context boundary is still leaking information.

The test matrix should include at least these cases:

1. A regular profile with established site state.
2. A new regular profile with no prior site state.
3. A private context opened after regular browsing.
4. A private context opened without a preceding regular visit.
5. Two private contexts that must remain independent.
6. A site with multiple subdomains under the same registrable domain.
7. An unrelated site that must not receive the signal.
8. Site-data deletion followed by a new private context.

For every case, record the browser version, operating system, profile state, site registration state, context type, request method, and observable result. Capture only data needed for the test. Do not collect a person's browsing history as a substitute for a privacy review.

Negative tests are especially important. Confirm that a token is not accepted by an unrelated site, that a deleted profile does not retain unexpected state, that a private context cannot reveal the regular context's URL history, and that a site cannot turn a one-bit result into a stable identifier by repeatedly combining it with unrelated signals. Test interrupted flows, expired state, denied permissions, and browser restarts as well as the happy path.

Cross-platform testing should be explicit. A result observed on one operating system and one browser channel is not a universal browser behavior. Compare supported versions, but label experimental observations as experimental. Keep protocol observations separate from product claims so a later proposal change does not silently become a compatibility guarantee.

What BotBrowser does today

Current BotBrowser builds do not enable PVT. BotBrowser does not forge, import, or pre-seed PVT tokens. This keeps the browser's behavior explicit while the proposal, rollout status, and cross-browser position remain unsettled.

This position is about product behavior, not a claim that the wider Chromium ecosystem has permanently rejected the design. If the platform status changes, BotBrowser will need a fresh review of the privacy properties, profile boundaries, storage lifecycle, and observable behavior before considering any enablement. A future review would also need to distinguish a browser-level capability from an application-level policy.

For current deployments, users should continue to follow BotBrowser release notes and compatibility reports. A release note will identify a deliberate behavior change and the versions it affects. A compatibility report can then describe the tested conditions, limitations, and migration guidance without asking users to infer behavior from a browser brand or a status-page milestone.

What site operators can do now

Site operators do not need to wait for PVT to improve private browsing flows. First, make the reason for an additional verification step clear. A user who understands why a check appeared is more likely to complete it and less likely to disable privacy protections. Second, keep the fallback proportional to the risk. Do not require a durable identifier for a low-risk action when a short-lived, user-visible step is enough.

Third, separate session security from device recognition. Authentication, rate limits, abuse controls, and fraud review each have different requirements. A proposed browser signal should not become a hidden replacement for account security or a justification for collecting more data than the service needs.

Finally, document private-context behavior as part of the application's support matrix. Test sign-in, consent, checkout, search, uploads, and other important journeys with regular and private contexts. Record what the site sees and what the user sees. This produces useful evidence whether or not PVT eventually ships.

Questions for a browser compatibility review

A compatibility review should be written so another engineer can understand the conclusion without joining the original investigation. Start with the public source version and the browser build under test. State whether the test used a stable release, a preview channel, or a locally configured build. A result from a locally configured build can be useful for protocol work, but it is not evidence of general availability.

Next, define the user-visible purpose. Is the test checking that a private window can complete sign-in, that a consent choice remains isolated, or that a site does not receive an unexpected identifier? One test should not quietly answer all three questions. Keeping the purpose narrow makes both the privacy review and the support explanation more reliable.

The review should list the state transitions that matter. Include whether a regular context existed first, whether the site had registered for the mechanism, whether the user deleted site data, and whether the private context was closed and reopened. Include browser restart and profile replacement where those events are part of the product workflow. A token or a request header observed in only one state is not enough to describe the whole feature.

Record absence as carefully as presence. If a request does not include a proposed signal, note the browser version, site registration, context type, and request path. If a signal is present, record whether it is limited to the expected site and whether the same result appears in a new private context. This avoids the common mistake of treating one positive observation as proof of a broad rollout.

Support teams also need a plain-language answer for customers. A good answer can say that PVT is a proposed browser design, that availability may change, and that BotBrowser currently keeps it disabled. It should direct the customer to release notes and compatibility reports for tested changes. It should not ask a customer to enable an unreviewed setting or infer support from an experimental milestone.

Separating privacy review from detection claims

PVT discussions often become confused with broad claims about whether a site can classify a visitor. Those are different questions. A privacy review asks what information a browser makes available and whether contexts remain isolated. An application review asks which signals a service uses for a particular decision. A security review asks whether an account or transaction is protected against abuse. The same request can be relevant to all three reviews, but one result cannot stand in for the others.

For example, a site may receive a bounded verification result and still ask for a normal sign-in step. Another site may not use the result at all. A browser that does not expose PVT may still support a complete private browsing workflow through ordinary authentication and user-visible checks. Avoiding a proposed signal is therefore not the same as disabling privacy, and observing a signal is not the same as proving that a site will trust it.

This separation also improves product documentation. Browser documentation can describe context isolation, storage policy, and release behavior. Site documentation can describe its own verification and fallback flow. Neither document needs to promise an outcome controlled by the other. Customers get a more accurate expectation, and future platform changes can be evaluated without rewriting unrelated guarantees.

What users and browser teams should watch

Users should look for concrete release notes rather than relying on headlines about an experimental browser feature. A meaningful announcement should state the browser version, the scope of the change, whether it is enabled by default, and how the behavior affects private and regular contexts.

Browser teams should watch the official explainer and Chrome Platform Status for changes to the proposal. They should also compare public statements across browser vendors without treating one vendor's status as another vendor's roadmap. When a design changes, update the test matrix and the threat model before updating a product guarantee.

The most useful evidence is reproducible: a documented browser build, a known profile state, a controlled site, and an observation that can be repeated. Screenshots or a single header capture may illustrate a case, but they cannot establish rollout, privacy isolation, or cross-browser support by themselves.

Conclusion

Private Verification Tokens are a proposal for carrying a narrow, site-scoped trust signal from regular browsing into a later private context. The idea addresses a legitimate false-positive problem, but its privacy value depends on strict boundaries and careful implementation.

Today, PVT should be discussed as proposed and unreleased. Chrome's public status does not establish general availability, and the public record currently has no signal from Firefox or Safari/WebKit. Current BotBrowser builds do not enable, forge, import, or pre-seed PVT tokens.

That is a stable basis for evaluation: understand the design, test the privacy boundary, and avoid promising behavior that the platform has not shipped. Follow BotBrowser release notes and compatibility reports for future decisions.

Sources

• Private Verification Tokens explainer
• Chrome Platform Status: Private Verification Tokens
• PPC Land: Chrome tests a one-bit signal telling sites an Incognito visitor is human