www.inforegister.ee

Context

www.inforegister.ee is the Estonian business register and credit-information service Inforegister (OÜ Register): company data, credit scores, beneficial-owner information, financial forecasts. The site is built on WordPress and served through Apache. The recording was made on the Russian-language version.

The recording: 109 requests, 6 nodes, a recording length of 146.3 seconds, taken on 16 August 2026. Besides the main domain, the page addresses three third-party recipients: Google (Analytics 4 and Tag Manager via the Google Site Kit plugin) and Webpushr (a push-notification service on three subdomains). The session runs across several register pages.

The processing is described by a detailed privacy policy in Estonian: twenty-two sections of the main part, separate documents on the categories of recipients and on the legitimate-interest analysis. Section 18 is devoted to cookies, analytics and marketing, section 12 to recipients and third parties.

Who receives data directly

Google (Analytics, Tag Manager), Webpushr.

Declared versus actual

A consent mechanism is installed — but analytics does not depend on its result. Consent-management plugins run on the site: cookie-consent, wp-consent-api and Google Site Kit, all starting from the markup in the first milliseconds. That is, the consent infrastructure is present, and this is noticeably better than its complete absence. The problem is that the actual loading of analytics is not tied to the result of the user’s choice. The first Google Analytics 4 request goes out at +1130 ms with the consent-mode marker gcs=G100 — “consent granted” — and carries the client identifier, page URL and title, a page_view event. The G100 marker means that analytics cookies are allowed; but it is set before the choice in the banner is recorded in the recording. Later, throughout the recording, scroll and click events go out with the same marker.

The push-notification service works independently of consent. Webpushr is loaded at +333 ms — earlier than Google analytics — and calls its three nodes: cdn.webpushr.com (the script), bot.webpushr.com (obtaining settings and subscription) and analytics.webpushr.com (impression analytics impression/prompt). This is a third-party service with its own analytics, and its loading is not made conditional on consent.

The recipients of web data are not named individually. The policy is detailed as regards business data: section 12 thoroughly analyses the categories of recipients — technical providers, legal advisers, auditors, public authorities, third parties by consent. But as regards web analytics, section 18 is limited to general terms: cookies, analytics and similar technologies may be used, and the precise principles are described in a “corresponding cookie notice”. Neither Google Analytics, nor Google Tag Manager, nor Webpushr is named individually in the policy, and there is no separate cookie notice in the materials provided.

Security headers are set well. The site sets strict transport with subdomain inclusion and preload, the content-type-sniffing ban, a referrer policy and a permissions policy banning camera, microphone and sensors. The content-security-policy is built up solidly: nonce, strict-dynamic, report-uri and a node allow-list including Google Analytics, Tag Manager, DoubleClick and Webpushr. That is, the loading of third-party scripts is controlled at the CSP level — but not at the consent level.

Consent: what is proven and what is not

Proven: a consent infrastructure is present on the site. The plugins cookie-consent, wp-consent-api and Google Site Kit are loaded from the markup at +141…+145 ms.

Proven: Google analytics sends data with the consent marker before the choice is recorded. The GA4 request at +1130 ms carries gcs=G100 and the client identifier; scroll and click events over the recording continue to go out with the same marker.

Proven: Webpushr starts independently of consent. The requests to its three nodes are initiated by the markup at +333…+831 ms, before the Google analytics requests.

Not proven and not unambiguously established: the origin of the consent marker. The gcs=G100 marker could have been set either as a default value in the consent-mode configuration or as a saved choice from an earlier visit. Response bodies and cookie headers were removed from the published file during sanitisation, so the source of the marker cannot be reconstructed from the recording. What is recorded is that, in the observed session, the data went to Google with a granted-consent marker without a prior interaction with the banner in the recording itself.

Not proven and not asserted: the state of cookies on the device. Cookie headers and response bodies were removed from the published file during sanitisation.

Separately: the browser was sending the DNT: 1 header during capture. This had no effect on the composition and addressing of the requests.

Boundaries of observation

The recording covers several register pages. The observation records the browser’s behaviour, not the services’ internal workings: server-side processing, contractual relationships with recipients and settings on their side are not verified by a browser recording. The legal assessment is made by the competent authority — Andmekaitse Inspektsioon.

The file is published sanitised of personal data: cookie headers in requests and response bodies were removed. Because of the absence of response bodies, the origin of the consent marker gcs=G100 — a default value or a saved choice — cannot be established from the recording; what is recorded is only that the data went out with this marker without an interaction with the banner in the observed session. The full client identifier is not reproduced in the analysis.

The identification of services rests on domains and address patterns: Google Analytics 4 — by google-analytics.com/g/collect and the property G-3M0JH1H9F3; Google Tag Manager — by googletagmanager.com and the container GT-M34QRD4; Webpushr — by the webpushr.com subdomains and the paths app.min.js, impression/prompt; the serving provider — by the server: Apache header.

Conclusion

The Estonian business register Inforegister has installed a consent-management infrastructure on the site — WordPress plugins and Google Site Kit — and built up a solid content-security-policy with a node allow-list. But the actual loading of analytics is not tied to the result of the user’s choice: Google Analytics 4 sends the client identifier and page_view, scroll and click events with the granted-consent marker gcs=G100 already in the first second, before the choice in the banner is recorded. The Webpushr push-notification service with its own impression analytics starts even earlier and independently of consent.

The detailed policy, meanwhile, discloses the recipients of business data thoroughly, but describes web analytics only in general terms and refers to a separate cookie notice; Google Analytics, Google Tag Manager and Webpushr are not named in it individually.

Remediation: make the actual loading of Google Analytics and Webpushr conditional on the user’s choice, so that no data with the gcs=G100 marker is sent before consent; name all recipients of web data in the policy or in a separate cookie notice individually — Google Analytics, Google Tag Manager, Webpushr — with the fields transmitted and the purposes; ensure that the default consent mode is set to “denied” until explicit consent to analytics cookies is obtained.