Collection, ethics, and quality controls

How a WSI measurement is produced

The measurement process is designed to be repeatable, low-impact, auditable, and honest about unavailable evidence. This page documents the workflow from cohort selection to publication and the safeguards applied when interacting with public websites.

Core posture

Public homepages only

Safe, idempotent requests

No authentication or form submission

Bounded concurrency and retries

Opt-out and safety exclusions

End-to-end workflow

  1. 1

    Define the cohort

    A versioned monthly CrUX country export defines country, origin, rank bucket, device, and contextual LCP/TTFB availability.

  2. 2

    Validate and import

    The portal validates identity fields, rejects duplicate country–origin–device rows, preserves origins with missing performance metrics, and records provenance.

  3. 3

    Scan public homepages

    Eligible origins receive a bounded GET, CORS preflight OPTIONS, DNSKEY lookup, and TLS inspection. Results are persisted per measurement.

  4. 4

    Classify page context

    Visible homepage text is mapped into an eight-category taxonomy for breakdowns. Category never changes the origin's security score.

  5. 5

    Compute WSI

    Stored observations are evaluated against a versioned rubric; scores and aggregates are reproducible from persisted evidence.

  6. 6

    Review and publish

    Coverage, failures, classification, scores, and aggregates are reviewed before publication. Published snapshots are pinned and immutable.

Per-origin scan footprint

A successful attempt deliberately uses a small set of operations against the public homepage:

1. Homepage GET

HTTP/2-capable, follows at most 10 redirects

Collects status, final URL, protocol version, security headers, cookie flags, SRI evidence, and the bounded response body needed for visible-text extraction.

2. CORS preflight OPTIONS

Browser-shaped, same per-attempt client

Observes CORS response headers and the Allow header without submitting state-changing requests.

3. DNSSEC validation

One validating DNS lookup

Resolves the hostname through a validating recursive resolver and passes only when the complete answer, including any CNAME chain, is authenticated to a trust anchor.

4. TLS evidence

Reuse negotiated connection when possible

Certificate issuer, expiry, and validity are read from the GET connection; one dedicated handshake is used only when the transport cannot expose them.

Default pacing and failure handling

ControlDefaultPurpose
Concurrency4Parallelism across different sites, never four requests to one origin.
Inter-origin jitter1.5–3.0 sAvoids synchronized or burst-like traffic.
Timeouts10 s connect / 15 s readBounds resource use and avoids holding connections indefinitely.
Retries1 after 30 sOne bounded chance for measured transient transport or gateway failures.
Retry-AfterHonoredLong server-requested delays are deferred to a future job, never retried early.
Response body cap512 KiBEnough for SRI/text evidence while limiting transfer and memory.

Transient failures remain resumable. Deterministic failures and browser-verification challenges are recorded without repeatedly hammering the same origin. Operators can cancel queued work; already completed in-flight observations remain auditable.

Ethical and operational safeguards

Identifiable research traffic

Requests carry a neutral WSI-Research version token alongside a browser-compatible User-Agent.

No crawling

Only the public homepage and its bounded redirect chain are visited. The scanner does not follow page links.

No privileged interaction

No login, credentials, form submission, account creation, exploit attempt, or state-changing method is used.

Opt-out and exclusions

Hostnames in the exclusion register are never scanned. It supports site-owner opt-outs and legal or safety decisions.

Scope controls

Countries and cohorts are explicitly selected; a country can remain CrUX-only and therefore receive no live WSI scan.

Public-launch requirement: the scanner supports exclusions today, but a monitored public contact and opt-out channel should be published before broad external operation.

Data minimization and retention

  • Raw HTML is not persisted. The scanner stores structured evidence and, temporarily, a visible-text extract capped at 20,000 characters.
  • Classification reuses the existing download. This avoids a second homepage visit. Cached text is purged after classification unless an explicit debugging retention option is enabled.
  • Sensitive response-header values are redacted. Header names can remain for inventory while credentials or cookie-like values are omitted; oversized non-sensitive values are truncated.
  • Evidence is measurement-scoped. Provenance, timestamps, retry state, and rubric identity are retained so published results can be audited without silently rescanning a closed snapshot.

Quality controls and publication

Coverage is explicit

Import completion and metric availability are separate. Origins are preserved even when LCP/TTFB are unavailable, and the portal reports availability gaps rather than manufacturing values.

Jobs are resumable

Pending work and transient failures can continue without reprocessing completed logical items; retries retain lineage and attempt numbers.

Publication is deliberate

A measurement is published only after workflow review. Its public rubric is pinned, and archival hides rather than deletes historical evidence.

Data quality is visible

Validation, unreachable origins, classification errors, coverage gaps, and retry outcomes are recorded instead of being silently dropped.

Known limitations

Measurements represent what one research vantage point could observe at a specific time. CDN geolocation, A/B tests, downtime, redirects, WAFs, bot challenges, and DNS/TLS conditions may change the evidence. Unreachable origins are not proof of insecurity, and reachable origins with high WSI values may still contain serious vulnerabilities outside the rubric.