bzst.de

Context

BZSt (Bundeszentralamt für Steuern) is the Federal Central Tax Office, Bonn. It maintains registers of tax identifiers, administers tax refunds, and manages international tax cooperation. Sensitivity — high. GSB platform, Apache. HAR: 50 requests, 3 domains.

Matomo without a banner — Art. 6(1)(e)

addon_matomo.js loads locally at +106 ms and initiates requests to piwik.itzbund.de at +278 ms. The GSB CookieBanner is absent from the HAR entirely — unlike RKI, THW and other GSB sites in the series, where the banner is present. The tracking request (/js/?action_name=…&idsite=4) at +368 ms contains detailed data: User-Agent Client Hints (Edge 148, Windows 19.0.0, platform), screen resolution, page-view identifier.

The policy justifies Matomo through Art. 6(1)(e) DSGVO in conjunction with § 3 BDSG — the processing of personal data by a public authority to carry out tasks within its remit. Consent is not required, only an opt-out cookie for 2 years is provided. The policy does not refer to TDDDG, even though addon_matomo.js technically sets a cookie under the opt-out mechanism.

Viola — a chatbot on its own subdomain

formularbot-viola.bzst.de/static/widget/widget-no-avatar.js loads at +124 ms — the Viola chatbot widget on BZSt’s own subdomain. The homepage CSP points to several related endpoints: formularbot-viola.bzst.de, viola-bzst.azr.juacvoe.net (Azure) and formularbot-fms.bzst.de. In the capture only the widget itself from the BZSt subdomain is active; no requests to the Azure endpoint or to formularbot-fms are observed. In the policy Viola is declared indirectly — as a form bot (a form-filling assistant), without a separate section on data transfer and without naming the Azure infrastructure in the processing chain.

A chatbot on a tax-authority site is a sensitive component: through it the user may enter data related to tax matters. But in this capture only the loading of the widget is recorded, without interaction and without transfer of entered data — that is, the very fact of collection through the chatbot is neither confirmed nor denied by a browser capture on the homepage.

Consent: what is proven and what is not

Proven: Matomo runs without a consent banner. addon_matomo.js — a local wrapper at +106 ms, piwik.itzbund.de/js/ — at +278 ms, the tracking request /js/?action_name=…&idsite=4 — at +368 ms. The GSB CookieBanner is absent from the HAR entirely — unlike other GSB sites in the series, where the banner is present.

Proven: the tracking request carries detailed technical data. idsite=4 (BZSt), action_name=www.bzst.de/BZSt - Startseite, uadata with User-Agent Client Hints (browser, OS, platform versions), res=1536x864, pv_id=GI357H (a page-view identifier).

Proven: Set-Cookie — zero. Not a single Set-Cookie across all 50 requests. The Matomo opt-out cookie mechanism did not fire in this capture (the user did not opt out, no refusal cookie was set).

Not established: data collection through Viola. The widget is loaded, but there is no interaction in the capture; the transfer of user-entered data was not observed.

Not verified: the server side of Matomo and the Viola Azure chain. What ITZBund does with the received data and how the Viola data passes through the Azure endpoint is not determined by a browser capture.

Observation boundaries

The capture covers the homepage and records browser behaviour, not server-side processing. The infrastructure is federal: the GSB platform (Government Site Builder) on Apache, the BundesSans and BundesSerif fonts locally, Matomo analytics via ITZBund (Informationstechnikzentrum Bund), the Viola chatbot on BZSt’s own subdomain with an Azure endpoint in the CSP. ReadSpeaker (*.readspeaker.com) is present in the CSP as an allowed source, but is not active in the HAR and not mentioned in the policy — attributed to the undisclosed-but-not-fired.

The legal framework here differs from that of commercial sites. BZSt is a public authority, and the justification for Matomo runs through Art. 6(1)(e) DSGVO (processing to carry out a public task) in conjunction with § 3 BDSG, rather than through consent. However, § 25(1) TDDDG (the German implementation of ePrivacy) requires consent for access to information on the user’s device regardless of the legal basis for the subsequent processing — and the policy does not refer to this provision. That is, the dispute here is not whether there is a basis for the analytics (a public task is claimed), but whether Art. 6(1)(e) covers the technical access to the device itself, which under TDDDG requires consent. This boundary is drawn by the competent authority — the Federal Commissioner for Data Protection (BfDI).

The file is published cleaned of personal data; the absence of a banner, the parameters of the Matomo tracking request, the zero Set-Cookie and the loading of Viola can be verified directly against the published file.

Conclusion

The Federal Tax Office runs Matomo web analytics without a consent banner, justifying it by a public task (Art. 6(1)(e) DSGVO + § 3 BDSG) and offering only opt-out. Technically everything rests on federal infrastructure: analytics via ITZBund, fonts locally, no Set-Cookie — by privacy standards this is a restrained configuration, with no third-party ad networks and no commercial tracking.

The key question is not whether there is a basis for the processing, but consent for the technical access to the device. Matomo loads and sends a tracking request with detailed User-Agent Client Hints and a page-view identifier before any consent, while the policy justifies this through Art. 6(1)(e), without referring to § 25(1) TDDDG, which requires consent for the access to the device itself. For a public authority this is a contestable but not rare position; the boundary between “the public task covers the analytics” and “access to the device requires consent under TDDDG” is drawn by the supervisory authority.

Remediation: bring the justification for Matomo into line with § 25(1) TDDDG — either condition the loading of the analytics on consent (a banner, as on other GSB sites in the series), or document why the technical access to the device falls under an exemption; disclose the Viola chatbot explicitly in the policy, naming the Azure infrastructure in the processing chain; remove ReadSpeaker from the CSP if it is not used, or disclose it in the policy.