Aerod tests should be understandable before they are impressive. A reader should be able to identify the environment, baseline, changed variable, observed result, evidence source, and limit without reverse-engineering an undocumented score.
Purpose
These standards apply to browser tools, connection checks, media-device tests, proxy and VPN verification, provider research, and technical explainers. They do not require every page to use the same apparatus. They require every result to disclose enough context to be interpreted honestly.
A test should answer:
- What was tested?
- Under what conditions?
- What changed?
- What was observed?
- What can the result support?
- What remains unknown?
Record the environment
Before comparing results, record the parts of the environment that can change the outcome. Depending on the test, this can include:
- Browser family, version, profile, extensions, and private-browsing state.
- Operating system and relevant privacy settings.
- Device type, camera, microphone, audio interface, or network adapter.
- IPv4 and IPv6 availability.
- VPN, proxy, Proxifier rule, split-tunneling, and DNS configuration.
- Provider product, plan, network type, endpoint, region, and authentication method.
- Date and time.
- The exact Aerod route and deployment identifier.
Environment records explain why the same nominal test may produce a different result elsewhere.
Establish a baseline
A baseline is the state before the tested variable changes. For a VPN check, it can include the direct public IPv4, IPv6, ASN, organization, country, region, WebRTC candidates, and expected DNS path. For a browser-permission check, it can include the saved site permission and operating-system permission. For a provider test, it can include the direct connection’s latency and throughput.
Without a baseline, a changed result can be mistaken for a successful result. A proxy exit showing a different city does not prove that an application changed routes unless the direct route was recorded first.
Change one variable at a time
- Connect one VPN server without also changing browser profile and DNS settings.
- Enable one Proxifier application rule while Default remains Direct.
- Grant camera permission without simultaneously testing the microphone.
- Change one proxy protocol while keeping endpoint and target constant.
- Compare one provider plan using the same target, region, concurrency, and test window.
Some real workflows require multiple simultaneous changes. When that happens, describe the result as a combined configuration result instead of attributing it to one component.
Observe before interpreting
| Type | Example | How to write it |
|---|---|---|
| Observation | The public IPv4 changed from one address to another. | State the comparison and time. |
| Provider claim | A provider says a plan includes a stated pool size. | Attribute the claim and date the source. |
| Inference | The route is probably a hosting-network exit. | Identify the supporting ASN or organization evidence and label it as inference. |
| Limit | The test cannot identify every resolver used by every application. | State the untested layer directly. |
Clean writing is not an excuse to convert an inference into a fact.
Use the correct test layer
- IP Lookup observes the public route used by the request and available network intelligence.
- WebRTC Leak Test observes ICE candidates returned to the browser.
- Browser Leak Test observes browser identity, locale, storage, permission, and privacy-control signals.
- Browser Fingerprint Check reviews rendering and device-characteristic surfaces.
- Proxy/VPN Detection reviews consistency clues rather than issuing a universal classification.
- Online Webcam Test verifies browser permission, device selection, live input, and local capture.
- DNS testing requires controlled resolver infrastructure and cannot be replaced by a public-IP lookup.
Repeat material results
A single run can be affected by transient routing, caching, provider load, browser startup state, device contention, or a temporary error. Material conclusions should be repeated when the test permits it.
- Multiple runs in the same environment.
- Multiple endpoints or regions.
- Desktop and mobile viewports for interface checks.
- IPv4 and IPv6 separately.
- Before-and-after disconnect checks.
- A second browser profile when profile state is relevant.
- Tests on more than one day for provider performance comparisons.
Preserve result limits
- A changed public IP does not prove that every application uses the route.
- A clean WebRTC result does not prove anonymity.
- An approximate city is not a device location.
- A browser fingerprint surface is not proof of identity across the web.
- A local media preview is not a complete hardware diagnostic.
- A provider test is a sample from the tested plan, endpoint, target, and time.
- A resolver name does not by itself prove the full DNS path.
Handle failures as evidence
A failed test should not be discarded merely because it complicates a conclusion. Record whether the failure came from the target, environment, browser, provider, authentication, timeout, unavailable device, or an unknown cause.
- Mark the result inconclusive when it cannot support a conclusion.
- Describe the missing evidence.
- Do not substitute an inferred success value.
- Retest only after changing or repairing the relevant condition.
Version and update control
A material app-runtime change, browser release, operating-system privacy change, provider product change, or methodology change can invalidate an older result. Aerod pages carry publish, modified, and review dates. The Evidence Register exposes those dates and the number of recorded external sources.
Retesting is prioritized when a provider changes pricing or product terms, a browser changes an API or permission, an app runtime changes the result model, a source conflicts with newer primary evidence, or a correction request identifies a material issue.
Release quality gates
Code and content releases are expected to pass canonical validation, legacy parity, deterministic builds, route and sitemap checks, app-runtime protection, accessibility testing, mobile and desktop browser tests, preview smoke testing, and a clean final Git state before push.
Passing an automated release gate does not prove every factual claim. It proves that the configured structural, publication, build, and browser checks succeeded for that release.
Minimum test record
A material test record should contain enough information to reconstruct the conclusion without relying on memory. At minimum, record the public route or tool, test date, environment, baseline, changed variable, target, procedure, observed output, failure handling, and limitation. Provider-related tests should also identify the product or plan, network type, region, authentication method, and billing context.
Raw evidence does not need to be published when it contains credentials, personal information, provider secrets, or security-sensitive details. In that case, the public page should still describe the method and preserve a redacted or summarized result sufficient for editorial review. A result that cannot be reviewed internally should not support a strong public conclusion.
Thresholds, scoring, and pass criteria
When Aerod uses a threshold or score, the rule should be defined before the result is interpreted. A pass criterion can be binary, such as whether a requested browser permission was granted, or comparative, such as whether the routed public IP differs from the direct baseline. Composite scores should expose the contributing signals and should not hide a serious failure behind an average.
Thresholds must fit the task. A latency level acceptable for ordinary browsing may be unsuitable for real-time media. A route-success sample suitable for a setup guide may be too small for a provider reliability ranking. Pages should state the decision rule and avoid reusing a threshold outside the context for which it was designed.
Related Aerod documents
- App Methodology defines the result model for active tools.
- Source and Evidence Policy defines how claims are sourced and attributed.
- Provider Review Methodology applies these standards to proxy and VPN research.
- Editorial Policy defines publication expectations.
- Corrections Policy defines how errors are handled.
- Evidence Register publishes evidence metadata for public editorial routes.
FAQ
Does Aerod test every possible browser, device, network, and provider configuration?
No. Aerod documents the tested environment and the limits of the sample. Results from another browser version, operating system, route, account, device, or provider can differ.
What makes a browser or network test repeatable?
A repeatable test records the environment, baseline, changed variable, procedure, result, date, and known limitations so another reviewer can reproduce the same conditions.
Why does Aerod separate IP, WebRTC, DNS, fingerprinting, and browser-state checks?
Each layer observes a different signal. Combining them into one score can hide which test passed, which test failed, and what the result actually proves.
How are inferred results labelled?
An inference must be identified as an inference and linked to the observations that support it. It should not be presented as a directly measured fact.
When should a test be repeated?
Retest after a material browser, operating-system, app-runtime, provider, network, protocol, methodology, or policy change, and whenever a prior result is old enough to affect a current recommendation.