# The Grey Zone Index — raw capture files

Twenty websites, loaded once each in a fresh Chrome profile from Finland on
10 August 2026. Recording stopped the moment the cookie banner was touched, so
everything in these files happened **before any consent was given or refused**.

These are the files the numbers on
<https://riskscope.actvli.com/grey-zone-index> are derived from. They are
published so the counts can be checked rather than believed.

## Reproducing the numbers

Open any `.har` in Chrome DevTools (Network tab → drag the file in), or run the
counting script from the episode repository:

    python3 count_har.py

The published files reproduce every figure in the index exactly. That was
verified after scrubbing, not assumed.

## What was changed before publication

Scrubbed with `scrub_har.py`. Three things were removed:

1. **Response bodies.** 1,292 of 1,344 entries carried one. They are other
   people's copyrighted JavaScript, they were 94% of the 137 MB, and nothing in
   the analysis reads them. `size` and `mimeType` are retained.

2. **Credential headers.** foxnews.com ships live API keys to the browser,
   including an AWS AppSync key. Those keys are technically public — every
   visitor receives them — but republishing a working key in a downloadable file
   is not the same act as it passing through a browser. The header *name* is
   kept, because "Fox sends an API key before you consent" is part of the
   finding. Only the value is replaced.

3. **Credential fields in POST bodies.** Third-party analytics account keys,
   which would let anyone write junk into that customer's analytics. Key names
   kept, values replaced.

Everything replaced reads `[redacted-by-scrub_har]`, so you can see exactly
where and how often it happened.

## What was deliberately kept

- **Full URLs and query strings.** This is the evidence. Redacting it would
  leave you taking the counts on trust, which defeats the purpose.
- **Device and session identifiers in POST bodies.** Every capture used a fresh
  Chrome profile that was destroyed afterwards, so these identify nothing that
  still exists — and "an identifier was minted for me before I was asked" is the
  entire argument.
- **Request headers, timings, server IPs, resource types, initiators.**

Two payloads are worth opening yourself:

- `www.amnesty.org.har` → `m.stripe.com`. A base64 browser fingerprint sent
  before consent: operating system, language, installed PDF plugins, screen
  geometry, and a hash.
- `www.linkedin.com.har` → `collector-pxdojv695v.protechts.net`. Two POSTs
  totalling about 21 KB of encoded device data. LinkedIn scores **0** in the
  index because this vendor is anti-scraping and was classified as functional.
  That call is documented and arguable, and this file is how you argue with it.

## Known limits

- Roughly ten seconds per site. A live news page never finishes loading — Al
  Jazeera made 113 requests at ten seconds and 1,092 at ninety. The figures are
  conservative.
- `www.nhs.uk.har` is empty. The export ran with the third-party filter active
  and there was nothing left to export, because the NHS made 13 requests and
  every one was first-party. It is a clean result, not a failed capture.
- Totals for 18 of the 19 non-empty files are unavailable for the same reason:
  the HAR was exported with a filter applied, so it contains only third-party
  requests. Third-party counts are unaffected — the filter only ever removed
  first-party traffic.
- One sample, one location, one date. Results elsewhere, especially outside the
  EU, are likely to be worse rather than better.

## Licence

Published for scrutiny and reuse. Attribution to RiskScope appreciated.
Questions: reachout@actvli.com