Methodology

Principles

An audit is a reproducible measurement, not an opinion. Every claim in a publication rests on a concrete artifact: a HAR file, a screenshot, a fragment of code. Any reasonably technical person should be able to repeat the audit and arrive at the same result.

Tools

• Browser: Firefox or Chromium as an ordinary visitor (fresh profile, no extensions, typical user-agent).
• DevTools for network capture in HAR (HTTP Archive) format.
• Additional verification: Wireshark to confirm outbound TCP connections at the network level.
• Geolocation: recorded in the audit metadata, since RTB infrastructure responds differently to different regions.

Procedure

1. Session setup. Fresh browser profile, cleared cookies, disabled extensions. Open developer tools, start network capture.
2. Site visit. Requests are recorded with exact timestamps relative to session start.
3. Consent banner interaction (if any): state is recorded separately before any click and after each available variant.
4. Multi-page navigation to detect trackers that activate outside the homepage.
5. HAR export with timestamp and SHA-256 hash.

Request classification

Each network request is classified along multiple axes:

• Purpose: technical resource, analytics, advertising, consent, security, font.
• Recipient: domain, corporation, jurisdiction (EU, US, other third country).
• Trigger moment: before banner, after consent, after refusal.
• Disclosure status: whether the recipient is listed in the site’s privacy policy.

Legal qualification

Technical findings are matched to specific GDPR articles:

• Art. 5, 6, 7 — lawful basis and consent;
• Art. 9, 10 — special categories of data;
• Art. 12, 13, 14 — transparency and information;
• Art. 25 — privacy by design and by default;
• Chapter V — transfers of data to third countries.

The audit does not infer guilt or intent — it records facts and identifies the applicable rules.

Evidence chain

For each audit, we publish:

• HAR file for open download.
• SHA-256 of the HAR file, posted on the audit page.
• Date and time of the audit.
• Geolocation of the client at the time of audit.
• Browser version and user-agent string.

This allows integrity verification and independent replication.

Limitations

• An audit fixes a specific point in time. A site may be fixed afterwards or, conversely, add new violations.
• Not all violations are visible via HAR. Server-side or back-office processing requires different methods.
• Legal qualification is published as a reasoned opinion, not as a judicial decision. Final qualification rests with the competent authority.

Openness

The methodology is open to critique. If you find a methodological flaw, write to contact@gdpr-audit.eu. Corrections are documented publicly in the changelog.