Seven kinds of information stay separate

This prevents a browser-support fact from being mistaken for proof that a website is secure:

  1. Browser data: support records, browser versions, and source notes.
  2. Feature mapping: which source records represent a security feature.
  3. Calculation: whether your chosen browser versions meet the requirements.
  4. Guidance: setup needs, fallbacks, and limitations written for this project.
  5. Supplied configuration: optional headers, page information, local resource checks, request information, and reduced passkey settings.
  6. Public browser tests: direct links to reviewed Web Platform Tests and their limits.
  7. Report signer: an optional command-line check that an approved continuous integration (CI) workflow signed the matching report.

How a security feature is linked to browser data

A security feature may rely on one browser-data record or several. When every part is required, ControlCurrent reports that the feature works only if every record shows support. If MDN data does not describe the exact feature separately enough, the result is “Not enough browser data” instead of a guess. Content Security Policy (CSP) nonces and hashes currently have this result, although the local header check can still recognise their syntax in a supplied policy.

How browser versions are compared

Browser versions are compared as version numbers rather than decimals, so version 100.10 is not confused with 100.1. Support, removal, last-supported versions, and uncertain source records are handled separately. Experimental flags, partial support, old names, and source notes produce “Works with limits” rather than disappearing into a simple yes.

What the result labels mean

What a change date means

The update page records the date attached to the source data and the ControlCurrent version that first noticed a difference. It does not claim that browser code changed on that exact date.

How the local evidence check works

The simple inspector reads one final set of response headers that you paste. It makes no web request and reports only reduced information. “Found” means recognisable syntax appeared in the supplied enforced policy or header. It does not prove browser enforcement, coverage across every page, safe rollout, or live behaviour. An advanced evidence file can compare several supplied pages, relate CSP to supplied markup, verify local resource bytes against Subresource Integrity (SRI), examine selected request and passkey settings, and compare reports. You must still provide a complete page list; ControlCurrent cannot discover missing pages itself.

How optional report signatures work

The command-line tool can prepare a standard statement containing the report fingerprint, deployment identity, and reduced page-list fingerprint. It can then check a Sigstore digital signature from the exact certificate issuer and workflow identity allowed by your policy. This confirms the signer and unchanged report; it does not prove that the evidence was complete or true.

How public browser tests are used

Each security feature either has a direct Web Platform Tests link or is clearly marked as having no exact link. Source links point to the reviewed test version, while live result links are provided for further investigation. ControlCurrent does not turn those results into scores or use them to change its browser-support answer.

Repeatable results and safety limits

The same reviewed inputs produce the same ordered data, results, and update identifiers. ControlCurrent limits input sizes, record counts, saved plans, and exports. If a required source record disappears, the data update fails instead of silently reporting support.

Browser support cannot prove that a website is configured correctly, follows every part of a standard, has no browser defects, or uses the right security policy for an organisation. Technical terms used here are explained in the plain-English glossary.