# Protocol: VPN website protection warnings

Recorded before measured collection, 14 October 2026, Africa/Nairobi.

## Decision and scope

The planned native Proton status/kill-switch experiment is not feasible: native
computer-use inventory returned no applications, despite a protonvpn-app process,
and tcpdump/dumpcap are unavailable. No safe independent receiving endpoint and
packet-capture setup was established. Do not call this a kill-switch test.

The authorized fallback examines visible IP/security-checker messages on selected
VPN websites, comparing the native Kenyan ISP route with existing Proton WireGuard
Germany and California profiles. Native Proton app functionality is not tested.

## Collection plan

Select six public diagnostic pages from provider primary sources, including both
marketing-oriented checkers and provider-connection checks. Freeze the page list
before the main collection. Selection is purposive, not a market census.

Run two passes per connection condition, with reverse provider order in the second
pass. Use the same in-app browser, English page language, unchanged browser profile,
and no imported/deleted cookies. These are returning-browser observations, not
clean first visits or independent participants. Disable HTTP cache through tab CDP
where supported. Do not bypass challenges, dismiss warnings, or change security
settings to make a page work.

For each visit record start/end UTC timestamps, original URL and final URL,
rendered text, visible warning/connection labels, observed IP privately, source-IP
agreement with independent checks where available, page status and document
response status. Observe at least ten seconds after navigation begins, taking
snapshots at the first readable state and the final checkpoint. Save original
viewport screenshots privately. Preserve failures. Any retry is separate.

Before and after each network block, record active NetworkManager connections,
the route to an external address, and available independent external public-IP
responses. A WireGuard interface alone is insufficient; check actual exit behavior
in the browser and compare actual addresses privately. Save published agreement
flags without home IP or persistent hashed identifiers.

## Interpretation

A site's visible "unprotected" label is not evidence of a VPN leak. A site may
recognize only its own network. Different exit IPs across destinations can result
from provider routing and need investigation, not immediate classification as
leakage. No observed label is a whole-device security measurement. Test non-Proton
VPN positive controls only if already available; otherwise state their absence.

Separate exact visible findings from inferred mechanisms. Do not infer intent,
illegality, logging, cryptographic weakness, or user harm. Quote briefly and cite
provider explanations. Publish a small descriptive case study with actual sample
size; do not use significance tests or pretend the visits are independent users.

## Assets and privacy

Raw evidence is stored in evidence/ with user-only permissions. Public data will
omit exact IPs, account details, headers, cookies, authentication state, and bodies
of background requests. Original screenshots remain unchanged. Publication assets
may use clearly documented opaque redaction rectangles or crops; keep the original
and a redaction manifest. Redaction must not alter the observed warning or status.

## Deviations

- Browser initialization timed out once and succeeded on retry; no measured data
  were collected during the failed initialization.
- A preliminary Surfshark native-route page was inspected to design collection;
  it is exploratory and excluded from the measured dataset.

- Two initial collector-design visits (Surfshark and NordVPN) were moved to evidence/exploratory and excluded before the measured passes. The final collector measures its ten-second minimum from the cache-disabled reload start and preserves an initial and final DOM snapshot. A timed-out body extraction is an incomplete attempt, even if a screenshot exists.

- Frozen sample: Surfshark, NordVPN, ExpressVPN and Proton IP-check pages, Mullvad connection check, and IVPN homepage connection-status header. These are six provider surfaces, not six equivalent diagnostic engines.
- Germany exposed both IPv4 and IPv6 exit addresses. Added ipify universal (api64) as a supplementary independent check before the end of that block, and retained the version change in route-check.py. Matching is assessed separately by address family; different IPv4 and IPv6 addresses are not disagreements.
- Supplementary Mullvad WebRTC panel expansion took place after the measured Germany first visit. Its two listed addresses were compared privately with independent IPv4/IPv6 echoes. The FAQ button inspection added no explanatory panel. These are supplementary observations, not extra main sample visits.

- Collection ended after exactly 36 main attempts. Five were excluded by final diagnostic-quality review: one incomplete capture, two security challenges and two unresolved IP-field results. Reverse-order visits were planned repetitions, not replacements for failed first-pass visits.
- Screenshot calls with nonzero crop origins produced incorrect top-of-page strips in this browser adapter. Rejected strips remain private. Publication screenshots were instead cropped deterministically from unchanged original JPEGs with ImageMagick, with coordinates in article-assets/crops.json. No status text or colors were edited.
- Collection used existing manual WireGuard profiles, not the installed native Proton desktop application. The normal ISP connection was restored and independently checked after the final block.