gdpru.eu

Context

gdpru.eu is a public archive of technical audits of websites against data protection requirements. It publishes analyses accompanied by network-traffic captures and their checksums, the texts of the policies audited, correspondence with companies and regulators, the methodology and country statistics. The controller is the gdpru.eu project, Estonia; contact — contact@gdpru.eu. The site is static, served by the hosting provider statichost.eu.

The measurement: 72 requests, one domain. The capture lasted 66 seconds, during which nine pages were opened across two language versions: the home page, the countries, changes and articles sections in Russian, then the English home page, the audits and countries sections in English, and a return.

Auditing your own site by the method you use on others is a thankless exercise: if anything turns up, you have to explain yourself in public. But otherwise the whole project would rest on nothing but its word. The processing is described by the privacy policy in its version of 12 July 2026; below it is checked against the capture line by line.

Who the data goes to directly

No one. There are no external recipients in the capture.

Declared versus actual

The policy opens with the claim easiest to disprove by measurement: not a single request to a third-party domain when the page loads. In the same place the reader is directly invited to check this themselves by opening the developer tools. The capture confirms the claim on every count.

Not a single external call across nine pages in two languages. The walkthrough deliberately covered the sections with interactive elements — the data flow map, the country chart, the policy change calendar, the filters in the archive. That is usually where external dependencies surface: developers most often pull charting and map libraries from public CDNs, because it is two lines shorter. Here the charting library sits in /js/chart.umd.js on the site’s own server — all 205 kilobytes, downloaded and placed alongside. The flow map and its data are its own too.

The language versions pull nothing extra. When switching to English, separate data files are loaded — site-search.en.js, flowmap-data.en.js, countries-chart-data.en.js — but all from the site’s own domain. Shared libraries come from cache.

Fonts are local. Two IBM Plex Sans weights are served from the /fonts directory. There are no calls to Google’s servers.

Cookies are not set. Zero Set-Cookie headers across all 72 responses.

Hosting matches what was declared. Every response carries the server header statichost.eu — the very processor named in the policy by name, with its country and the existence of an Art. 28 agreement stated. There are no signs of a CDN in the capture, which is consistent with the note about the unused sub-processor.

A consent mechanism is absent — and here that is correct. There is nothing to manage: no optional scripts were found. The policy states this outright — the rule on consent for access to a device does not apply, because there is nothing to apply it to.

Protective headers

The content security policy is drawn up strictly: by default only the site’s own origin is allowed, and the same restriction is duplicated in separate directives for scripts, styles, fonts, images, network connections, the base URL and form submission. Framing is denied entirely, insecure connections are upgraded to secure ones. The only relaxation is allowing inline styles — a common necessity for a static build.

The value here lies not so much in protection as in demonstrability. The project’s main claim — the absence of third-party calls — is now declared by the server itself in machine-readable form. It can be checked with a single command, without opening developer tools and without taking anyone’s word for it. At the same time the header works as insurance against one’s own carelessness: if tomorrow an external script accidentally slips into the template, the browser simply will not execute it.

Alongside are set: a referrer policy with the value strict-origin-when-cross-origin — when following an external link from an audit, the audited organisation receives only the domain name, not the address of the specific page the visitor was reading; a frame-embedding ban in a separate header with the value DENY, duplicated by a directive in the content security policy; strict transport with a one-year term, subdomain inclusion and the preload flag; a ban on content-type sniffing.

Among the technical details that have no bearing on data processing but speak to the care of the build: 67 of 72 requests went over HTTP/3; twenty-four unique addresses served seventy-two requests — thirty-two responses came back with a 304 code, meaning the cache works and no redundant traffic is generated; the names of the stylesheet and map script contain a content hash, so a file cannot be swapped without changing its name.

Consent: what is proven and what is not

Proven: there are no external transfers across nine pages. All requests are addressed to the site’s own domain.

Proven: cookies were not set in this session. None of the responses carry a Set-Cookie header.

Proven: protective headers are set and drawn up strictly. Verifiable directly from the main document’s response.

Confirmed by the hosting operator: the content and retention of the logs. The policy states that the logs record neither the IP address nor the user-agent string, and that retention does not exceed seven days. This is not verifiable by a browser measurement; a written confirmation was obtained from the operator statichost.eu.

Not proven and not claimed: the data route on the hosting side. The server header shows who serves the response, but not the infrastructure it passed through. The absence of CDN signs is consistent with the statement about the unused sub-processor, but does not constitute confirmation of it.

Limits of observation

The measurement covers nine pages across two language versions, in one state — ordinary browsing without interacting with forms.

The observation captures the browser’s behaviour. Server-side processing and the actual geography of storage are not verifiable by a browser measurement. The second processing operation described in the policy — personal data within the published archive materials — has no bearing on the operation of the site and is not reflected in the capture.

The file is published stripped of personal data by the same rules applied to others’ captures: request cookie headers, response bodies and tab headers are removed. All the analysis’s claims rest on the request addresses, their composition and the response headers visible in the file.

The audit of the site’s own site was conducted by the same methodology and with the same limitations as the rest. A reader wishing to verify it independently need only repeat the measurement: the tool and procedure are described in the methodology section, and the checksum of the capture is given in this card’s header.

Conclusion

Across nine pages opened in two language versions the site sent not a single request outward. Fonts, the charting library, the flow map, the filters, the change calendar — everything sits on its own server, including the separate language data files. Not a single cookie for the entire session. The hosting in the response headers matches the processor named in the policy; there are no signs in the capture of the approved but not engaged sub-processor.

The technical side is tightened to the same requirement: the content security policy allows only the site’s own origin and denies framing, and the referrer policy does not let audited organisations learn which specific page a visitor who followed a link was reading. The promise the policy opens with is now not only checked by measurement but declared by the server itself — and it can no longer be broken silently.

No violations recorded.