RU EN
www.
Technical audit · 09.09.2026

luxexpress.eu

Lux Express bus operator website
EE

A bus operator's website — a single capture of the homepage, 143 requests, 12 nodes, about five minutes. The Cookiebot consent management platform is in place, and the user explicitly declines consent (action=decline). Google analytics matches this choice: the GA4 events and Google Ads carry the status 'denied', cookieless. But the Microsoft Clarity session recording does not respect the refusal: the stream of the visitor's behavioural data goes to Microsoft for the whole session — both before the refusal and after it. The Exponea customer data platform, meanwhile, only loads its SDK and sends no events. The security headers are weak.

Request timeline

+1739…+3135 ms · the stack loads, session recording starts
api.exponea.com/js/exponea.min.js (the Exponea SDK), www.googletagmanager.com/gtm.js, consent.cookiebot.com/uc.js, www.clarity.ms/tag/qutgpux0eg and scripts.clarity.ms/clarity.js, then i.clarity.ms/collect (POST 204) — the Microsoft Clarity session recording begins at +3135 ms. Served via Cloudflare; of the protective headers only HSTS is set.
+2427…+2621 ms · analytics and advertising (cookieless)
pagead2.googlesyndication.com/ccm/collect (page_view, gcs=G100) and region1.google-analytics.com/g/collect (GA4 G-GXFF79XC5T, page_view, gcs=G100). Both with the status 'denied', cookieless.
+295898 ms · the user declines consent
consent.cookiebot.com/logconsent.ashx?action=decline — an explicit refusal (method strict, country EE). By this point Clarity has been recording the session for almost five minutes.
+313262 ms · Clarity continues after the refusal
An i.clarity.ms/collect request goes out after the recorded refusal. The denial had no effect on the session recording.

Declared versus actual

✓ Controller — Lux Express (per the 'Policy and cookies' document) — declared
✓ The cookie declaration on the Cookiebot engine names: Microsoft (clarity.ms), Exponea, Google Analytics, Google Ads, Meta — declared
✓ Categories: necessary, statistics (statistika), marketing (turundus) — with consent configuration — declared
✓ Consent management — Cookiebot; supervisory authority — Andmekaitse Inspektsioon — declared
+ That the Microsoft Clarity session recording runs before and despite the refusal (action=decline) — not declared
+ That session recording as a separate processing operation is not described in the document (Clarity is disclosed only as a Microsoft cookie) — not declared

Transfer timings

+3135 ms i.clarity.ms

Microsoft Clarity, project qutgpux0eg. The start of the /collect stream.

+2621 ms region1.google-analytics.com

GA4 page_view, G-GXFF79XC5T, gcs=G100.

+2427 ms pagead2.googlesyndication.com

Google Ads ccm/collect, page_view, gcs=G100.

+295898 ms consent.cookiebot.com

logconsent.ashx?action=decline, method strict.

+313262 ms i.clarity.ms

The /collect stream continues after the refusal, despite the choice.

Detected trackers

Indicators of GDPR non-compliance

Context

luxexpress.eu is the website of the bus operator Lux Express. The controller is stated in the ‘Policy and cookies’ document. Consent is managed by the Cookiebot platform. The site is served via Cloudflare and, of the protective headers, sets only Strict-Transport-Security; Content-Security-Policy, Referrer-Policy, Permissions-Policy, X-Frame-Options and X-Content-Type-Options are absent.

The capture is a single recording of the homepage: 143 requests, 12 nodes, about five minutes, recorded on 9 September 2026. Over the course of the session the user declines consent in the banner. Processing is described by the cookie declaration on the Cookiebot engine.

Who receives data directly

Microsoft (Clarity, session recording — before and after the refusal). Google analytics (Analytics, Ads) goes cookielessly, honouring the denial. The Exponea customer data platform loads its SDK but sends no events.

Declared vs. actual

The discrepancy here is selective: the consent platform holds one part of the stack, but not the other.

Google analytics honours the denial. Cookiebot is configured for Google’s consent mode, and after the refusal the GA4 events (G-GXFF79XC5T) and the Google Ads requests carry the status gcs=G100 — both storages denied, the pings cookieless. This is correct behaviour, and it is worth recording to the site’s credit.

But the session recording does not respect the refusal. In the recording the user explicitly declined consent — the logconsent.ashx request carries action=decline at +295898 ms, method strict. Nevertheless, the Microsoft Clarity session recording (project qutgpux0eg) runs independently of that choice: the stream of i.clarity.ms/collect requests begins at +3135 ms and continues throughout the session — 21 requests — including after the refusal, up to +313262 ms. Clarity records both before the choice and after the explicit ’no’. The Cookiebot platform does not hold this service.

Exponea is silent for now. The Exponea (Bloomreach) customer data platform, in this capture, only loads its SDK (exponea.min.js); no track event is observed in the recording. This is noted as the presence of the service, not as a transfer.

The security headers are weak. Of the protective headers the site sets only HSTS — neither Content-Security-Policy, nor Referrer-Policy, nor Permissions-Policy, nor X-Frame-Options, nor nosniff — on a platform where tickets are bought and payment data is left.

Proven: the user declined consent. The consent.cookiebot.com/logconsent.ashx request carries action=decline, method strict, country EE.

Proven: Google analytics honours the denial. The GA4 events and the Google Ads requests carry gcs=G100 and are cookieless.

Proven: Clarity records the session before and after the refusal. The i.clarity.ms/collect stream runs from +3135 ms, continues throughout the session and includes a request after the refusal — at +313262 ms.

Proven: Exponea sends no events. Only the loading of exponea.min.js is present in the recording; no request transmitting an event is recorded.

Not proven, and not reproduced: the content of the recorded sessions. What exactly the Clarity recording captured is not reproduced in the audit; the conclusion rests on the fact of the session-recording request stream before and after the refusal.

Observation boundaries

The capture covers the homepage and records browser behaviour, not the services’ internal workings: server-side processing, the configuration of the tag container and contracts with recipients are not verified by a browser-level capture. The session-recording tool is identified by the Clarity domains and the character of the /collect stream; the type of decision (action=decline) is read from the Cookiebot request. Cookie values in the published file were removed during redaction.

The file is published redacted of personal data. Response headers, statuses, the load order, initiators, the Clarity request stream and the moment of the refusal are verified directly against the published file.

The legal assessment is made by the competent authority — Andmekaitse Inspektsioon.

Conclusion

The bus operator’s website keeps the Cookiebot consent management platform, and it holds Google analytics correctly: after the refusal the GA4 events and Google Ads carry the status ‘denied’, cookieless. But the Microsoft Clarity session recording does not respect that refusal: the stream of the visitor’s behavioural data goes to Microsoft for the whole session — both before the explicit refusal and after it. One component of the stack is honestly conditioned on consent, the other is not.

Microsoft Clarity is present in the cookie declaration as a Microsoft cookie, but session recording as a separate processing operation is not described in the document, and — most importantly — it continues despite a direct refusal. Added to this is the weakness of the security headers on a platform where tickets are bought.

Remediation: condition the Microsoft Clarity session recording on actual consent, so that under a refusal (action=decline) no recording is performed and the /collect stream stops; describe session recording in the policy as a separate processing operation with the purpose and legal basis stated; verify that the Exponea customer data platform is also conditioned on consent before it begins sending events; and set the basic set of protective headers — Content-Security-Policy, Referrer-Policy, Permissions-Policy, X-Frame-Options and X-Content-Type-Options.

Evidence

How to verify: download the file and compute its checksum — sha256sum file.har (Linux, macOS) or certutil -hashfile file.har SHA256 (Windows); it must match the one shown. The conclusions apply to the scope of this measurement — see the limitations of the method.

Original (audit)
HAR file: ee/luxexpress-eu-2026-09-09.har
SHA-256: 389e5dd22d3e940dedd9c5055971921eaa7b34ae1e8b528d7c3921ce97574174
Re-check snapshot
Awaiting changes
HAR files are stored on EU infrastructure (Proton Drive). SHA-256 is published for integrity verification.
Want a response from the company about this audit? → Open the tool

Fill in once — it will be inserted into every letter below:

All fields are required to print the document — this is a formal requirement of the letter itself (the particulars of an official submission), not data collection: nothing is sent or saved anywhere, it all stays in your browser and disappears when you close the page. See the methodology for details.

Step 1. Data access request (GDPR Art. 15)

Send this letter directly to the company first — before contacting the regulator it has the right to respond (GDPR Art. 12(3) — 30 days).

Subject: Data access request (GDPR Art. 15) — luxexpress.eu

To: [insert the company's address — DPO / support / legal department]
From: [Your name], [contact email]

I request access to my personal data processed in connection with the website luxexpress.eu.

1. Categories of data and purposes of processing (Art. 15(1)(a)-(c))
Based on an independent technical analysis of the site, I request confirmation and detailed disclosure of the following categories of processing:

1) The site has the Cookiebot consent management platform installed, and in the recording the user explicitly declined consent: the consent.cookiebot.com/logconsent.ashx request carries action=decline (at +295898 ms, method strict, country EE). Google analytics matches this choice — the GA4 events (G-GXFF79XC5T) and the Google Ads requests carry the status gcs=G100 (both storages denied), the pings cookieless. But the Microsoft Clarity session recording (project qutgpux0eg) does not respect the refusal. The stream of POST requests i.clarity.ms/collect begins at +3135 ms and continues throughout the session — 21 requests from +3135 ms to +313262 ms, that is, also after the refusal recorded at +295898 ms. Clarity records the session both before the choice and after the explicit 'no'. The Cookiebot platform does not gate this service: Google analytics honours the denial, but the session recording does not.

2) The site's main document is served via Cloudflare and, of the protective headers, sets only Strict-Transport-Security. Content-Security-Policy, Referrer-Policy, Permissions-Policy, X-Frame-Options and X-Content-Type-Options are absent. This on a carrier's site, where a visitor buys tickets and leaves contact and payment data. For a platform with this composition of data, the absence of a basic set of protective headers is a standalone security-of-processing defect.


2. Recipients, retention periods, and transfers outside the EEA (Art. 15(1)(c)-(d), 46)
I also request the full list of third-party recipients, the applicable retention period for each category, and the legal basis for any transfer of data outside the EEA. The full technical audit with evidence (saved network log, SHA-256 checksum) is published at: https://gdpru.eu/en/audits/ee-luxexpress-eu/

3. Automated processing and profiling (Art. 15(1)(h))
Please state whether I am subject to automated decision-making or profiling, and if so, disclose the logic involved.

Sincerely,

[Your name]
[contact email]
[Country]


[Date]
IMPORTANT: before filing a complaint with the regulator, first contact the company directly and give it 30 days to respond. Without this step the regulator may reject the complaint. Details and a template letter to the company are in the Methodology.
Ready-to-send complaint letter

Where to file: Estonian Data Protection Inspectorate (AKI) — write to info@aki.ee

Important: AKI only handles submissions in Estonian. Translate the letter before sending.

The regulator reviews complaints in its national language. There is an officially translated template from the European Data Protection Board (EDPB) — you can use it instead of or alongside this letter: Official EDPB complaint form (PDF, your language)

Subject: Complaint regarding personal data processing — luxexpress.eu

1. Subject of the complaint
I am filing a complaint regarding the processing of my personal data by the website luxexpress.eu.

2. Circumstances
I visited the website luxexpress.eu and found indications that the processing of my personal data does not comply with the GDPR. The technical analysis published on gdpru.eu on 9 September 2026 (open methodology, reproducible measurements) documents the following indications:

1) The site has the Cookiebot consent management platform installed, and in the recording the user explicitly declined consent: the consent.cookiebot.com/logconsent.ashx request carries action=decline (at +295898 ms, method strict, country EE). Google analytics matches this choice — the GA4 events (G-GXFF79XC5T) and the Google Ads requests carry the status gcs=G100 (both storages denied), the pings cookieless. But the Microsoft Clarity session recording (project qutgpux0eg) does not respect the refusal. The stream of POST requests i.clarity.ms/collect begins at +3135 ms and continues throughout the session — 21 requests from +3135 ms to +313262 ms, that is, also after the refusal recorded at +295898 ms. Clarity records the session both before the choice and after the explicit 'no'. The Cookiebot platform does not gate this service: Google analytics honours the denial, but the session recording does not.

2) The site's main document is served via Cloudflare and, of the protective headers, sets only Strict-Transport-Security. Content-Security-Policy, Referrer-Policy, Permissions-Policy, X-Frame-Options and X-Content-Type-Options are absent. This on a carrier's site, where a visitor buys tickets and leaves contact and payment data. For a platform with this composition of data, the absence of a basic set of protective headers is a standalone security-of-processing defect.

Full technical documentation is published at: https://gdpru.eu/en/audits/ee-luxexpress-eu/

3. GDPR provisions I ask you to examine
ePrivacy — Directive 2002/58/EC, Art. 5(3) (in conjunction with GDPR Art. 6(1)(a)) — session recording despite the refusal; GDPR Art. 32 — security of processing, weak headers

4. Request
I request that you examine the circumstances described and, if non-compliance is confirmed, apply the measures provided for in Article 58(2) GDPR.

5. Attachments
The full evidence base — the HAR file, its SHA-256 checksum and the quotation from the site's privacy policy documenting the stated contradiction — is published and verifiable at the link in point 2 above.

Sincerely,

[Your name]
[contact email]
[Country]


[Date]