Methodology

Principles

An audit is a reproducible measurement, not an opinion. Every claim in a publication rests on a concrete artefact: a HAR file, a screenshot, a fragment of code. A person with basic technical skills can repeat the measurement using this method.

A repeat measurement shows the same pattern of requests — the same recipients, the same timing relative to the consent banner — but not necessarily byte-identical addresses and responses: advertising systems respond differently depending on country, time and browser history. That is why every audit states the date and the country of the measurement.

Tools

• Browser: Firefox or Chromium as an ordinary visitor (fresh profile, no extensions, typical user agent).
• Browser developer tools (the Network tab) to record network traffic in HAR (HTTP Archive) format.
• Country of measurement is recorded and stated in the audit, since advertising infrastructure responds differently in different regions.

Procedure

1. Session setup. Fresh browser profile, cleared cookies, extensions disabled. Developer tools are opened and network recording starts.
2. Site visit. Requests are recorded with exact timestamps relative to the start of the session.
3. Consent banner interaction (if any): the state is recorded separately before any click and after the choice.
4. Other pages where needed, if trackers may activate outside the home page.
5. HAR export with a timestamp and a SHA-256 checksum.

The scope of the measurement — which pages were opened and what was clicked in the banner — is stated in every audit. The audit’s conclusions apply only to that scope.

Request classification

Each network request is classified along several axes:

• Purpose: technical resource, analytics, advertising, consent, security, font.
• Recipient: domain, company, the company’s country of registration (EEA, US, other third country).
• Timing: before the banner, after consent, after refusal.
• Disclosure: whether the recipient is named in the site’s privacy policy.

Consent state: the string, not the label

The verdict “consent given / refused” is read from the decoded TCF string (the IAB TC string) carried in requests to advertising partners, not from the event name emitted by the consent management platform (CMP). A CMP may send an event typed “consent.given” for any user choice — acceptance and refusal alike; the event name records that a choice was made, not which one. What the site actually signalled to its partners is in the TC string: the consent and legitimate-interest signals for each purpose can be read from it unambiguously. This is the signal passed to partners — not an assessment of whether the consent was legally valid.

If no TC string is present in the recording, the consent state is treated as undetermined, not as given.

This distinction itself became an illustrative case. An automated check reading the CMP event name reported “consent given” where the string encoded a full refusal — a practice that might otherwise have gone unnoticed. The gap between the label and the decoded state is exactly the project’s subject: what is declared versus what actually happens. The label is not proof; the decoded state is.

Legal assessment

Technical findings are matched against two sets of rules.

ePrivacy — Directive 2002/58/EC, Art. 5(3), and the national laws that implement it (for example, § 25 TDDDG in Germany, the Electronic Communications Act in Estonia). It requires consent for storing information on, or reading it from, the user’s device — cookies, localStorage, identifiers — unless this is strictly necessary for a service the user has requested. “Trackers and cookies before consent” is first and foremost an ePrivacy question.

The GDPR — for what then happens to the personal data:

• Art. 5, 6, 7 — principles, lawful basis and consent;
• Art. 9 — special categories of data (for example, health);
• Art. 12, 13, 14 — transparency and information;
• Art. 25 — data protection 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.

Three registers of wording

So that a reader never mistakes a measured fact for a legal conclusion, the audit uses three levels of statement. Each finding is written at its own level and is not raised higher without grounds.

1. Observation (fact). What the HAR records: “the browser sent a request to X before the consent banner appeared (+3163 ms).” Reproducible and independent of interpretation.
2. Assessment (matching against the rule). How the fact relates to the rule: “the observed behaviour is inconsistent with the stated consent mechanism and indicates possible non-compliance with Art. 6(1).” This is the project’s reasoned opinion.
3. Legal determination. “The supervisory authority found an infringement of Art. X.” Used only where a decision by a regulator or court exists, with a reference to the document.

By default the project works at levels 1 and 2. Without a decision by a competent authority the words “violation” or “infringement” are not used; instead the audit speaks of a “finding”, an “indicator of non-compliance” or “possible non-compliance”. This also applies to the letter templates: in a complaint the complainant asks the regulator to examine the circumstances rather than asserting an infringement as an established fact.

Evidence chain

For each audit we publish:

• The HAR file — a sanitised copy (see below), linked from the audit page.
• SHA-256 — the checksum of that sanitised copy; a matching checksum confirms the file has not changed since publication.
• Date and time of the measurement.
• Country from which the measurement was made.
• Browser; the full user-agent string is visible in the headers inside the HAR file.

This makes it possible to verify the integrity of the evidence and to repeat the measurement.

HAR sanitisation

A HAR file records the browser’s actual network exchange — including the personal data of whoever ran the audit: cookie values, session tokens, IP address. These are removed automatically before publication. Below is what is stripped, what is kept, and why.

What is removed

The auditor’s personal data is removed from the published HAR: cookie values (Cookie, Set-Cookie); authorisation headers (Authorization, Proxy-Authorization, CSRF and session tokens, any header ending in -token, -auth, -key, -secret, -session); request and response bodies that are not evidence (script code, styles, images, and any body larger than 8 KB) — zeroed, with size and MIME type kept; sensitive URL parameters (token, session, password, code, signature and similar — the value is stripped, the name stays); the client IP address; local paths in the initiator stack.

What is deliberately kept

Everything that constitutes evidence of data being sent to third parties stays intact: cookie names and attributes (Path, Max-Age, HttpOnly) — the name shows which tracker set it; the recipient server’s IP address; the request initiator — which script triggered the call; timings — when each request happened; file provenance — which browser captured the HAR; request and response bodies that carry evidence — small (up to 8 KB) responses from ad exchanges, RTB auction bids, lists of networks the data is passed to, and consent strings (TC string). Personal fields inside such bodies (identifiers, user agent, email and the like) are stripped, but the evidentiary structure is kept.

The core principle: personal content is removed, the fact of transfer is preserved. A cookie value is stripped — but its name, recipient, initiator, size and moment of sending remain visible.

A limitation of sanitisation: the published copy shows who received requests, when, and which fields they carried, but without identifier values it cannot show that different requests carry the same identifier. Where this matters for a conclusion, the audit says so explicitly and relies on the original (see “Storage of originals”).

How it works

Sanitisation is automatic — the har_redact.py script, with no manual editing of individual entries. Each cleaned file gets a redaction map (_redaction_map.json) listing what was stripped and where, which makes the sanitisation itself verifiable. The integrity of the published file is confirmed by the SHA-256 shown on the audit page.

Storage of originals

The original HAR (before sanitisation) is stored separately from the site: on encrypted storage (Proton Drive), under double encryption and a strong password; access is held by a single person — the project author, and succession of access is currently an open question; storage is indefinite — the original is the evidence base, and deleting it would make the audit unverifiable. The original contains the auditor’s own data, not data about visitors of the audited sites.

Our position is that indefinite storage of originals as an evidence base is permitted under Art. 5(1)(e) and 89(1) GDPR (archiving in the public interest), subject to safeguards: encryption, single-person access, use only for verifying audits. This is our position, not a regulator’s decision; if a supervisory authority takes a different view, the storage arrangements will be revised.

This is consistent with the project’s principle: one person with a reproducible methodology records facts and is personally accountable for them. Sanitisation and storage are part of that accountability.

Limitations

• An audit captures a specific point in time. A site may be fixed afterwards or, conversely, new discrepancies may appear after the measurement date.
• Conclusions apply only to the scope of the measurement: the pages listed, the banner actions listed, one session. “No findings” means “nothing found in this measurement”, not “the site complies with the GDPR”.
• Not everything is visible in a HAR. Server-side or back-office processing requires different methods.
• The legal assessment is published as a reasoned opinion, not as a judicial decision. The final assessment rests with the competent authority.

If findings have been resolved

An audit records the state as of the measurement date. If a site has resolved the findings, this can be reported to contact@gdpru.eu, stating the domain and what exactly was changed.

After such a report, a repeat measurement is made using the same method (a fresh HAR, the same checks). If the earlier findings are no longer confirmed, the audit is listed under “Fixed sites” with the date of the re-check, and the original audit remains available. The reply and re-check take place within 30 days of the report.

The re-check relies on fact, not on assertion: it is confirmed by the same measurement as the original audit.

What to do with the results

If an audit shows indicators of non-compliance, you have the right to lodge a complaint with a data protection authority under Article 77 GDPR. For an individual this is free of charge in any EU country.

Recommended order:

1. First contact the company directly and give it 30 days to reply.
2. If there is no reply, or the reply does not resolve the questions, move on to a complaint to the regulator.

Article 77 GDPR does not require you to contact the company first. In practice, however, many regulators expect the complainant to have tried to resolve the matter directly, and complaints without such an attempt are often returned. A letter to the company is therefore a sensible first step.

You do not have to write these letters yourself. Under every audit with findings there is a ready-made tool: a letter to the company (a data access request under Art. 15 GDPR) and a letter to the regulator — both already filled in with the facts of that audit (findings, date, link to the evidence, HAR checksum). Add your name, email and country, and both letters are ready to print and sign.

For countries where it is better to address the regulator in the national language (for example Estonia — AKI), the audit page already contains a translated complaint text.

This is not legal advice — we are not lawyers; it is a standard complaint structure based on the requirements regulators publish on their own websites. For the exact way to file in a given country (form, email, response time), see the “How to file a complaint” block on that country’s page.

No data collection in complaint letters

The complaint tool (the data access request to the company and the complaint to the regulator under each audit) collects your name, email and country only in your browser, to fill in the letter text before printing. You do not have to take our word for it — here are three ways to check:

1. There is no sending code. The site’s code contains no call to fetch, XMLHttpRequest, sendBeacon or a form submission — the mechanism that would let data go anywhere simply does not exist.
2. Even if it appeared, the browser would block it. The site sends a strict security policy: the default-src 'self' and connect-src 'self' rules in the Content-Security-Policy header forbid the browser from sending requests to any other domain, whatever the code says.
3. Test it live. Open developer tools (F12) → the Network tab and type a test name into the field on an audit page. If no new network request appears, the data went nowhere. You can see this yourself without reading any code.

Openness

The methodology is open to criticism. If you find a methodological flaw, write to contact@gdpru.eu. Changes to the method are published in the project diary.