navigator.cpuPerformance: Tiers and Privacy

navigator.cpuPerformance is a coarse CPU performance classification, not a processor name, live utilization reading or identity check. Chrome 152 lists the API as a released feature. The pinned WICG draft defines four positive tiers and a separate unknown value, 0; an absent property is a different observation. BotBrowser can configure its documented core-count surface, but a --bot-cores setting alone cannot establish how this separate property is reported. That boundary matters when browser reports place CPU tiers beside core count, memory and timing signals.

Watch the video

This English-language video walks through the same question as the article: a returned navigator.cpuPerformance tier is a coarse static classification, not a live load reading. It separates an absent property, numeric zero meaning unknown, a current positive tier, an unrecognized future tier and a failed read; then it shows the draft's core-count mapping, the implementation-defined model adjustment, the privacy design band, Chrome's documented overrides, and a recorded Ubuntu Chrome readback from a controlled fixture. It does not reconstruct an exact core count, processor model or benchmark score. The audio is English.

TL;DR

• Keep an absent navigator.cpuPerformance, the numeric value 0, and a reported tier in separate states. Missing information is not a low-performance classification.
• The draft's initial mapping uses OS-reported cores, with implementation-defined CPU-model adjustments. A tier cannot reconstruct an exact core count or processor model.
• A static tier does not follow current CPU load. Chrome's documented user and administrator overrides also prevent treating every value as an unmodified hardware measurement.
• The specified exposure is a secure Window context. Chrome 152 documentation does not establish availability in every browser, embedded runtime or Worker.
• Coarse buckets reduce detail, not the existence of a hardware-related signal. Avoid adding unrelated identifiers to a CPU-tier support record.

Contents

• Watch the video

• Return states before hardware conclusions

• The draft's classification and its limits

• Static tiers, dynamic pressure and timing

• Privacy and minimal comparison records

• Chrome support and BotBrowser control boundaries

• Practical conclusion

Return states before hardware conclusions

The pinned CPU Performance API draft extends Navigator with a read-only unsigned short property. Its IDL declares SecureContext and Exposed=Window. These details describe where the interface belongs; they are not a compatibility table for every installed browser. A report needs to establish the observation context before assigning a meaning to the value it receives.

Observation	Meaning supported by the source or collector	Meaning not established
Context rejected by isSecureContext	The helper did not proceed with collection in that context	The device belongs to a low tier
Property not exposed	The property is absent from the inspected Navigator	The reason for absence, a privacy product or a CPU model
Numeric 0	The API reports an unknown classification	Zero cores, no CPU, or a failed JavaScript read
Integer 1 to 4	A current positive performance tier	Exact throughput, hardware identity or current utilization
Positive integer above 4	An unrecognized future tier for this consumer	Evidence that the pinned getter currently returns it
Read error or unexpected type	Collection did not produce the anticipated value form	A legitimate hardware classification

The difference between property exposure and classification survives even when a dashboard prefers a single compact label. Replacing both undefined and 0 with “unknown” discards information about which interface was available. Replacing them with tier 1 is more serious: it invents a performance judgment that the browser did not supply. Those transformations can produce misleading comparisons before any hardware inference begins.

A Window-side helper can retain the distinction without issuing a network request or running a benchmark. The branches below are an example of collection policy, not a transcript from a browser run. The secure-context branch is deliberately a prerequisite: returning there says that collection was skipped, not that an unavailable API was conclusively diagnosed.

function readCpuTier() {
  if (!globalThis.isSecureContext) return { state: 'context-skipped' };
  if (!('cpuPerformance' in navigator)) return { state: 'not-exposed' };
  try {
    const tier = navigator.cpuPerformance;
    if (!Number.isInteger(tier) || tier < 0 || tier > 65535) {
      return { state: 'unexpected-value' };
    }
    if (tier === 0) return { state: 'unknown' };
    if (tier <= 4) return { state: 'tier', tier };
    return { state: 'future-tier', tier };
  } catch {
    return { state: 'read-error' };
  }
}

The draft currently asserts a getter range of 0 to 4, while its tier section asks applications to tolerate additional tiers in future revisions. Preserving an unfamiliar positive integer is forward-compatible handling; it does not claim an existing implementation produces tier 5. An application may choose a conservative feature preset for that state, but its diagnostic record should not quietly relabel the observation as a known tier.

Property checks also have a narrower role than authenticity checks. Finding cpuPerformance on a page's navigator does not establish that the surrounding JavaScript environment is trustworthy, and a successful read does not authenticate a device. A feature-presence result belongs to capability handling. It should not become an account-access condition or a claim that a browser report has proved who is operating the machine.

The draft's classification and its limits

The draft starts with a core count reported by the operating system. Its definition of a core includes physical or logical execution units as the OS reports them. That input is not specified as the number returned by page JavaScript through navigator.hardwareConcurrency. The core-count reporting analysis distinguishes that page-visible report from underlying parallelism. Using the page's value to look up a tier is not a reproduction of the browser's OS-side classification.

OS-reported starting input in the draft	Initial tier
No core count, or 0	0
1 core	1
2 to 4 cores	2
5 to 10 cores	3
More than 10 cores	4

The same section permits adjustments when a known CPU model performs substantially better or worse than typical devices with its core count. Such adjustments usually move the classification by no more than one tier, require reliable model information from the OS, and use an implementation-defined model set. “Usually” is a source qualification, not a universal promise that every implementation is restricted to an identical adjustment list.

This makes the reverse mapping underdetermined. Tier 3 can begin in the 5 to 10 core group, but model adjustments can also affect a device's classification. Even before adjustments, a multi-value group does not disclose one exact core count. After them, assuming a unique processor from the final integer is even less justified. The returned bucket contains less information than the internal inputs that helped choose it.

The reference implementation and demonstration linked by the WICG document are explicitly non-normative. A classification produced by their example heuristics is useful for understanding an algorithm, not proof that an installed browser used the same model data. Reconstructing a reference result from a hypothetical input also does not constitute a measured browser observation. Source revisions, shipped implementation decisions and actual return values remain separate evidence categories.

The draft asks model adjustments to reflect performance measured under ideal conditions with relevant benchmarks. That is guidance for implementation classification; it does not turn a page's integer into a benchmark score. A tier has no published unit of seconds, operations per second or percentage utilization. Dividing one tier by another does not yield a meaningful speed ratio, so tier 4 should not be described as twice as fast as tier 2.

Likewise, the document's video-conferencing example associates tiers with application presets such as resolution and effects. It labels that interpretation application-specific. Another application's workload may depend on GPU capability, memory pressure, network latency or a particular instruction path. Selecting a modest starting preset from a tier can be reasonable; claiming the tier guarantees smooth video, model inference or a fixed frame rate exceeds what the API value establishes.

Static tiers, dynamic pressure and timing

Reproducibility is a stated design rule: the same device should report the same tier, rather than changing with current load or utilization. The draft also distinguishes correction of classification mistakes from redefining older tiers whenever faster machines appear. That distinction preserves the meaning of the scale while allowing implementation errors to be fixed. Static does not mean every value must remain identical across all browser releases and administrative settings forever.

Surface	Question it addresses	Invalid substitution
navigator.cpuPerformance	Which coarse static performance class is reported?	A live CPU-load meter
navigator.hardwareConcurrency	How many logical processors are reported to the page?	The CPU tier's exact OS input or model identity
navigator.deviceMemory	What approximate memory category is reported?	A CPU classification
Compute Pressure	What dynamic pressure information is exposed through that API?	A stable hardware tier
performance.now()	What timestamps are available for a timing measurement?	A direct readout of a CPU performance class

The distinction from dynamic pressure affects debugging. A tab can become slow while its CPU tier stays unchanged. That combination is not automatically a contradiction: a static category and a changing workload describe different things. The Compute Pressure workload analysis covers dynamic feedback and its API boundaries; it is the relevant neighboring question when the problem is adaptation to changing pressure rather than interpreting a classification.

Timing requires another separation. A page that times a task measures a particular execution path under particular conditions. Its result includes effects the tier was not designed to report continuously. The performance timing privacy analysis distinguishes timestamp precision and timing observations from hardware labels. A short duration cannot be inserted into the tier table as though the two surfaces shared a scale.

Consider an application that enables an expensive optional visual effect for a reported tier and later sees poor responsiveness. The first diagnostic question is which decision used the tier: an initial preset, a persistent entitlement, or a periodically recomputed setting. If the value only selected an initial preset, poor responsiveness does not alone show incorrect classification. The workload can require a separate adaptation mechanism, and the application should be able to reduce the optional effect without rewriting its hardware record.

Conversely, repeatedly reading the property is not a substitute for observing the workload that matters. The specification's load-independence goal means a polling loop is not supposed to reveal current saturation. Recording identical integers every second adds storage and activity without answering whether a frame, computation or request is missing its deadline. The question to measure should come from the application failure, rather than from the convenience of an available navigator field.

Privacy and minimal comparison records

The WICG privacy section describes a deliberately small integer disclosure. It aims for each tier to contain many devices and CPU models, including a stated intention of at least 10% of existing models and 10% of user devices per tier. These are design intentions in a specification, not population measurements supplied with every browser response. The property contains neither the denominator nor an audit proving that a particular deployment currently meets those coverage goals.

That matters for fingerprint interpretation. A coarse category is still an observable category, and the design seeks same-device reproducibility. A report may place that value beside platform, memory and other hardware-related observations. Combining categories can change what a collector knows, but the API's small output space does not by itself establish how distinctive a combination is in an actual population. No uniqueness percentage follows from merely listing the possible tier values.

An absent property can also reflect an observation boundary rather than an intended privacy feature. The draft's secure Window exposure, a product's implementation and the inspected context are all relevant. Assigning a missing field to a named privacy tool without evidence creates a second unsupported inference on top of the missing observation. The safer support result is the concrete state that was collected, together with the context information necessary to reproduce that specific issue.

Support-record field	Purpose	Collection limit
Browser product and release relevant to the issue	Relate a result to documented feature availability	Do not substitute a full identifying header dump when a release is sufficient
Window context and secure-context decision	Explain where collection proceeded or stopped	Do not claim a rejected context proves hardware absence
Collector state and tier when present	Preserve the result's actual shape	Do not convert 0 or missing into tier 1
Known user or enterprise override	Explain an explicitly known configuration difference	Leave it unknown when it was not verified
Observation date and relevant source revision	Separate a current case from older documentation	Do not attach unrelated browsing history or account identifiers

A comparison can remain useful without becoming a general fingerprint export. For a report about unexpected tier exposure, the return state and browser release can be enough to identify the next compatibility question. Raw Canvas output, WebGL renderer strings, installed fonts and cross-site identifiers do not automatically help answer that question. Adding them because another report happens to display them expands the data collection without establishing a need.

Retention should follow the support task as well. A record intended to explain one feature's availability does not need a permanent identity key joining future visits. If the browser release changes or the application adopts a newer specification revision, a dated comparison can document that change directly. Reusing an old tier as an immutable device label obscures the source and configuration differences that the investigation should keep visible.

The distinction between declared configuration and observation also prevents misleading product comparisons. A known setting is evidence about configuration; the property read is evidence about the page-visible return state. Neither should silently replace the other. When a value differs from a preset or from a reference heuristic, the record should preserve both facts and the source of each, rather than inventing a conclusion about a person's hardware or intent.

Chrome support and BotBrowser control boundaries

Chrome 152 release notes list CPU Performance API support and say users and administrators can override the reported tier through Chrome settings and enterprise policies. This is a Chrome-specific implementation statement. The WICG draft's classification algorithm does not, by itself, document the same settings in every other browser product or embedding application.

A reported tier therefore cannot always be described as an untouched OS-derived classification. A known Chrome override is a concrete alternative input to the visible result. When its state is not available to the investigation, the appropriate conclusion is that the override was not verified. It is not sound to assume “no override” simply because a page cannot inspect the administrator's policy configuration.

Version evidence has a similar boundary. A feature appearing in Chrome 152 release notes is evidence of that release's documented feature, not proof that a mobile app's embedded browser uses the same configuration. A Chromium version string alone does not establish the surrounding product's feature decisions. Feature detection in the actual page context should accompany documentation checks instead of being replaced by a brand or version assumption.

Worker comparisons need particular care because the pinned IDL is exposed to Window and extends Navigator, not WorkerNavigator. Reading a main-window value and sending it to a Worker creates an application-supplied value in that Worker; it does not demonstrate a native Worker property. A support record should preserve which context performed the original read rather than claiming cross-context parity from a relayed message.

The BotBrowser core-scaling reference documents navigator.hardwareConcurrency, --bot-cores choices and worker-affinity limits. Linux and Windows have documented affinity support; macOS still reports the configured count without that affinity mechanism. Those statements address a specific surface and execution constraint. They are not documentation that a profile or core-count flag rewrites navigator.cpuPerformance.

The storage and memory reference describes separate memory-related reporting. A memory category cannot establish a CPU tier, and a storage or heap setting is not evidence of control over this property either. Product documentation should name a surface before a comparison assigns control of that surface to a product setting. A direct observation can then support the narrower result for its recorded environment, rather than a universal protection claim.

FAQ

Should an unknown tier disable every optional feature?

An application can choose a conservative preset for 0, but the WICG example illustrates a different application-specific choice. There is no single mandatory workload preset encoded in the unknown value. Separate the observation record from the application's policy, and provide a way to change a costly feature when actual responsiveness is poor. The policy can evolve without pretending that the original property supplied a more specific classification.

Can a tier serve as an authorization credential?

The API returns a small performance category, not a signed authorization statement. Chrome also documents user and administrator overrides. A service deciding whether an operation is permitted needs evidence appropriate to that decision; a hardware-related bucket does not supply it. Treating the category as a login credential would attach a trust meaning that neither the property type nor the cited documentation defines.

What happens when a later specification adds another tier?

Keep the raw positive integer distinguishable from a familiar 1 to 4 value, and choose an application fallback deliberately. The draft explicitly anticipates additional higher tiers while its current getter algorithm asserts the existing range. A forward-compatible consumer should avoid turning an unfamiliar category into a collection error merely because its own display labels have not yet been updated.

Does a stable tier remove the need to date a comparison?

An observation still belongs to a browser release, product configuration and source revision. The draft allows classification mistakes to be corrected, and Chrome documents overrides. A date and release can explain why two records were collected under different assumptions. They should be kept as provenance for the support question, rather than used to create an enduring identity record.

Sources

• Pinned WICG CPU Performance API draft
• Pinned WICG security and privacy questionnaire
• Chrome 152 CPU Performance API release notes
• BotBrowser CPU core scaling reference
• BotBrowser storage quota and memory reporting reference

Practical conclusion

Record the exposure state before interpreting navigator.cpuPerformance. Use a positive tier as a coarse starting input for application behavior, keep 0 separate from a missing property, and retain unknown future values without inventing their meaning. Compatibility questions belong to the actual browser product and Window context. A core-count setting, reference heuristic or low-detail tier is insufficient evidence of CPU identity, product control of this separate surface, or the outcome of an unrelated service decision.