chd.lu

Context

chd.lu is the website of the Chamber of Deputies of Luxembourg, the unicameral parliament of the Grand Duchy. It publishes parliamentary files, deputies’ questions, plenary-session transcripts, petition materials, and educational sections. The data controller is the Chamber itself, Rue du Marché-aux-Herbes 23, Luxembourg; the Data Protection Officer role is performed by an external contractor from Deloitte Tax & Consulting. The platform is Drupal with a custom theme.

Scan: 48 requests, five hosts. Thirty-nine requests to the site’s own domains, nine to the analytics platform. Capture duration: 2.7 seconds; full page load completed at 2003 ms. Captured on June 15, 2026, on the French-language homepage.

A single document — a personal data protection notice — describes the processing.

Who receives data directly

TWIPLA (Visitor Analytics).

Declared versus actual

The discrepancy here isn’t in the details — it’s in the very subject matter of the description.

The document doesn’t acknowledge that the site has visitors. The notice is built around situations where a person actively contacts the parliament: fills out a contact form, subscribes to parliamentary files or transcripts, writes an email, files or signs a petition. For each situation, the categories of data are honestly listed — down to place and date of birth for a public petition — with legal bases, retention periods, and recipients named, including the State Information Technology Centre for cross-checking against the national register.

The document says nothing about processing that occurs simply by opening the page. The word cookie doesn’t appear in it once. Nor do the words “analytics,” “visitor statistics,” “audience measurement.” The section on what data is collected opens with the contact form and subscriptions, exhaustively delineating collection and leaving no room for observation of the reader.

Yet observation does occur, and in a fully deployed form. From the 1726th millisecond, the TWIPLA platform deploys, also known under its former name Visitor Analytics. The sequence is: a script carrying a site identifier, a request for the site’s monitoring settings, a log transmission via POST with a 201 response — meaning a record on the platform’s side was created — a second script, a request to the poll-targeting service, and establishment of a persistent connection.

Two elements deserve particular attention.

The first is the request to the polls service at +2527 ms. The address of this request carries, in plain text, as ordinary parameters, the address of the page being viewed and a persistent visitor identifier. The identifier is a fixed-length base64-encoded string, used to recognize the same visitor on subsequent visits. It is not reproduced in full in this analysis.

The second is the connection at +2711 ms. The request goes out over the WebSocket protocol and receives a code of 101, meaning a protocol switch: the channel is established and remains open as long as the page is open. This is a fundamentally different mode from a one-off event transmission: over such a channel, data can be transmitted continuously, in both directions, without separate visible requests.

The platform’s second script is named ssr-worker.js. TWIPLA’s feature set includes session recording, and the abbreviation in the file name is consistent with that purpose; however, this cannot be stated as fact from a browser-based scan, where response bodies are not preserved — only the file name and the presence of a persistent channel are recorded.

There is no consent mechanism. Across all 48 requests, there is not a single request to a consent-management platform and not a single script bearing the corresponding hallmarks. Names of known platforms and general patterns in addresses were checked — zero matches.

What is worth noting in the site’s favor. There is only one external recipient in total. Fonts, images, theme scripts, and internal requests go exclusively to the site’s own domains — no mapping libraries, no third-party icon sets, no embedded players. A set of protective headers is present: strict transport security, a restriction on being embedded in a frame from an external source, a restriction on content-type sniffing, a restrictive referrer policy, and a separate header disabling the browser’s cohort-based advertising technology. The Content-Security-Policy header, however, is not set.

Separately, regarding third countries. The notice explicitly states that no transfers outside the European Union occur within the listed processing activities. TWIPLA is a Berlin-based company, and by its own statements, processing takes place within the Union; this is not verifiable by a browser-based scan. This observation is not recorded as a cross-border-transfer violation — the caveat “within the listed processing activities” simply does not apply to web analytics, since it is not part of that list.

Consent: what is proven and what is not

Proven: there is no consent mechanism in the capture. Not a single request to a consent-management platform, not a single script bearing the corresponding hallmarks, across all 48 requests.

Proven: analytics ran in full and transmitted data. The log transmission received a 201 response, meaning a record was created on the platform’s side. The request to the polls service carries the visitor identifier and page address. A persistent connection was established with code 101.

Proven: loading does not depend on the user’s choice. The initiator of the platform’s script is recorded as the site’s own theme script, loaded from the page footer — meaning the call is built into the site’s code and executes as it runs. There is no condition tied to the user’s choice preceding it.

Not proven and not required: the absence of a text notice in the markup. Response bodies have been stripped from the published file, so the presence of an informational notice in the HTML cannot be checked from it. The conclusion is not built on this, but on the fact that analytics launches from the theme’s code and does not depend on any notice, and that no platform capable of managing it exists on the page.

Separately: the browser sent a DNT: 1 header during the capture. This had no effect on the composition or volume of the transmissions.

Limits of observation

The scan covers a single page — the French-language homepage — in a single state. The petitions sections, where the documents indicate name, date, and place of birth are collected, were not part of this scan, and this analysis makes no claims about them.

The observation records browser behavior, not the internal workings of the services: processing on the platform’s side, its contractual relationship with the parliament, the data it retains, and the geography of processing are not verified by a browser-based scan. Legal assessment falls to the competent authority — the Commission nationale pour la protection des données.

The file is published stripped of personal data: cookie headers, response bodies, the tab header, and the body of the transmitted log have been removed. The persistent visitor identifier is not reproduced in full in this analysis. The set of cookies on a device cannot be reconstructed from the published file, and no conclusion in this analysis relies on it: all statements rest on request addresses, their order, response codes, and recorded initiators.

Content transmitted over the persistent connection is not preserved in this kind of browser capture — only the fact of the channel’s establishment and the response code are recorded. The purpose of the ssr-worker.js script is inferred from its file name and the platform’s known capabilities; it cannot be verified from the scan.

Identification of the service relies on the visitor-analytics.io domains, the address pattern carrying a site identifier, and the response headers of the platform’s hosts.

Conclusion

The Luxembourg Chamber of Deputies’ data protection notice is written carefully and in detail — for those who write letters to the parliament, subscribe to transcripts, or file petitions. For those who simply open the site to read the news, there is not a single line: the word cookie does not appear once, analytics is not mentioned, and processing during browsing is not described as a phenomenon at all.

Meanwhile, an external analytics platform deploys on opening the homepage: it requests monitoring settings, transmits a log, carries a persistent visitor identifier along with the address of the page being viewed in the request address, and opens a persistent connection that stays held open for as long as the page remains open. No consent mechanism was found on the site — no banner, no platform, no stored choice.

Otherwise, the site is set up in a restrained manner: a single external recipient, its own fonts and images, a reasonable set of protective headers. This makes the gap between that restraint and the document’s complete silence about the one instance of monitoring that is nonetheless taking place all the more notable.

Remediation: introduce a consent mechanism that controls the loading of the analytics platform, and do not launch it from the theme’s code before the visitor’s choice; supplement the notice with a section on processing during site visits — naming the platform, the fields transmitted (including the visitor identifier), the purposes, the retention period, and the legal basis; describe the purpose of the persistent connection and the polls service.