RU EN
www.
Technical audit · 08.09.2026

ts.ee

AS Tallinna Sadam (Port of Tallinn) website
EE

The Port of Tallinn's website — a single capture of the homepage, 75 requests, 10 nodes, about twenty seconds. The WPConsent consent management platform is in place, and it holds Google analytics correctly: the GA4 pings go out with the status 'denied', cookieless, and the consent record contains statistics:false. But the Leadfeeder (Dealfront) B2B visitor-identification service bypasses this refusal: it loads its tracker, sends a beacon to tr.lfeeder.com and writes a persistent _lfa cookie with an identifier to the device — under a refused statistics state. The service is disclosed in the policy as a web-analysis tool that reports which companies visit the site. The security headers are set strictly.

Request timeline

+0 ms · homepage load
Served via Cloudflare. The security headers are set strictly: Content-Security-Policy (default-src 'self' with a narrow allowlist, frame-ancestors 'self'), HSTS, Referrer-Policy same-origin, Permissions-Policy, X-Content-Type-Options nosniff, X-Frame-Options SAMEORIGIN. The WPConsent consent platform runs on the page.
session state — statistics refused
The WPConsent record wpconsent_preferences contains essential:true, statistics:false — consent for statistics is not given. This is confirmed by the gcs=G100 status of GA4: both Google storages are denied.
+1491…+2087 ms · Google analytics (cookieless)
www.googletagmanager.com/gtag/js, then region1.google-analytics.com — a conversions request and the page_view, first_visit events (G-DWDWJ7YNQ6) with the status gcs=G100. The analytics honours the denial, the pings cookieless.
+3758…+4670 ms · Leadfeeder under refused statistics
sc.lfeeder.com/lftracker_v1_… — the Leadfeeder (Dealfront) tracker; then a beacon to tr.lfeeder.com (response 200). A persistent _lfa cookie with a visitor identifier is written to the device. All of this under statistics:false.
+1505 ms · Cloudflare Web Analytics
static.cloudflareinsights.com/beacon.min.js — an analytics beacon from the page markup.

Declared versus actual

✓ Controller — AS Tallinna Sadam, registry code 10137319, Sadama 25, Tallinn; data-protection officer andmekaitse@ts.ee — declared
✓ Cloudflare — necessary for the site's operation and cybersecurity; 'cookies do not identify the user' — declared
✓ Dealfront (Liidio Oy) — a web-analysis service based on Google Analytics data, reports which companies visit the site and provides potential leads; Dealfront's policy — leadfeeder.com/privacy — declared
✓ Google Analytics and Facebook are mentioned in the document — declared
✓ Consent management — WPConsent; supervisory authority — Andmekaitse Inspektsioon — declared
+ That Leadfeeder / Dealfront writes a persistent _lfa cookie and sends a beacon under a refused statistics state (statistics:false) — not declared
+ That Leadfeeder is not conditioned on the consent state, whereas Google analytics is (gcs=G100, cookieless) — not declared

Transfer timings

+2087 ms region1.google-analytics.com

GA4 page_view, G-DWDWJ7YNQ6, gcs=G100. The analytics honours the denial.

+3758 ms sc.lfeeder.com

Leadfeeder lftracker (Dealfront).

+4670 ms tr.lfeeder.com

Leadfeeder beacon, response 200. A persistent _lfa cookie is written to the device.

+1505 ms static.cloudflareinsights.com

Analytics beacon from the markup.

Detected trackers

Indicators of GDPR non-compliance

Context

ts.ee is the website of AS Tallinna Sadam (Port of Tallinn), registry code 10137319, Sadama 25, Tallinn; the data-protection officer’s contact is andmekaitse@ts.ee. The site is built on WordPress, served via Cloudflare, and keeps a strict header posture: Content-Security-Policy (default-src 'self' with a narrow allowlist, frame-ancestors 'self'), HSTS, Referrer-Policy same-origin, Permissions-Policy, X-Content-Type-Options nosniff, X-Frame-Options SAMEORIGIN. Consent is managed by the WPConsent plugin.

The capture is a single recording of the homepage: 75 requests, 10 nodes, about twenty seconds, recorded on 8 September 2026. Processing is described by the ‘Policy and cookies’ document.

Who receives data directly

Leadfeeder / Dealfront (B2B visitor identification — under a refused statistics state). Google analytics — cookieless, honouring the denial. Functionally — Google Maps, FontAwesome, Cloudflare.

Declared vs. actual

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

First — Google analytics honours the denial. WPConsent is configured for Google’s consent mode, and the GA4 events (G-DWDWJ7YNQ6) go out with the status gcs=G100 — both storages denied, the pings cookieless. The consent state is meanwhile unambiguous: the WPConsent record wpconsent_preferences contains statistics:false — consent for statistics is not given. GA4’s behaviour matches this state, and that is worth recording to the site’s credit.

Second — but Leadfeeder bypasses the refusal. The Leadfeeder B2B visitor-identification service (in the document — Dealfront, provider Liidio Oy) runs at full strength under the same consent state: at +3758 ms its lftracker (sc.lfeeder.com) loads, at +4670 ms a beacon goes to tr.lfeeder.com (response 200), and a persistent _lfa cookie with a visitor identifier is written to the device. That is, under a refused statistics state Leadfeeder both stores an identifier on the device and transmits visit data. WPConsent gates Google analytics, but Leadfeeder is not conditioned on this state.

Third — what exactly Leadfeeder does. The policy describes Dealfront plainly: it is a web-analysis service that ‘reports which companies visit the site’ and ‘provides potential leads based on this information’. That is, it is not a strictly necessary function but marketing analytics of visitor identification — precisely the category for which consent is required. The disclosure of the recipient here is honest (Dealfront is named, a link to its policy is given), but disclosure does not replace respecting the choice: under statistics:false this service should not run.

Proven: consent for statistics is not given. The WPConsent record wpconsent_preferences contains statistics:false; the gcs=G100 status of GA4 confirms it — both Google storages are denied.

Proven: Google analytics honours the denial. The GA4 pings are cookieless, with the status gcs=G100.

Proven: Leadfeeder writes an identifier and transmits data in this state. The lftracker loads at +3758 ms, the beacon to tr.lfeeder.com is delivered at +4670 ms (response 200), and a persistent _lfa cookie with a visitor identifier is present on the device.

Not proven, and not required: the content of the Leadfeeder transfer. Which fields exactly the Leadfeeder beacon carries is not reproduced in the audit; the conclusion rests on the fact of the tracker loading, the beacon being delivered and the persistent cookie being written under a refused statistics state.

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 consent state is established from the WPConsent record wpconsent_preferences (statistics:false) and confirmed by the gcs=G100 status of GA4; the presence of the persistent _lfa cookie is established from the session’s storage, since cookie values in the published file were removed during redaction. The full _lfa identifier is not reproduced in the audit. Google Maps, FontAwesome and jsDelivr are classified as the functional part.

The file is published redacted of personal data. Response headers, statuses, the load order and initiators are preserved, so the gcs=G100 status of the analytics, the loading of the Leadfeeder tracker and the delivery of its beacon are verified directly against the published file.

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

Conclusion

The Port of Tallinn’s website keeps the WPConsent consent management platform, and it holds Google analytics correctly: the GA4 pings go out with the status ‘denied’, cookieless, and the consent record contains statistics:false. But under the same consent state the Leadfeeder (Dealfront) B2B visitor-identification service bypasses the refusal: it loads its tracker, sends a beacon to tr.lfeeder.com and writes a persistent _lfa cookie with an identifier to the device. That is, one component of the stack is honestly conditioned on consent, and the other is not.

The service itself is disclosed in the policy plainly: Dealfront is named as a web-analysis tool that reports which companies visit the site, with a link to its privacy policy. But this is precisely marketing analytics of visitor identification, for which consent is required — and under a refused statistics state it nonetheless writes an identifier and transmits data. Honest disclosure of the recipient does not replace respecting the user’s choice.

Remediation: condition the loading and firing of Leadfeeder (Dealfront) on the consent state so that under a refused statistics state (statistics:false) its tracker does not load, no beacon goes out and no _lfa cookie is written to the device; verify that all components classified as statistics and marketing are wired to the WPConsent platform at the blocking level, not only to Google’s consent mode.

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/ts-ee-2026-09-08.har
SHA-256: 1167e1cd537e8d985045d1ac7b53b7e25258aa8002e8ae30024f33b7c37305d8
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) — ts.ee

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 ts.ee.

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 WPConsent consent management platform installed, and it holds Google analytics correctly: the GA4 events (G-DWDWJ7YNQ6) go out with the status gcs=G100 — both storages denied, the pings cookieless. The consent state is unambiguous: the WPConsent record wpconsent_preferences contains statistics:false, meaning consent for statistics is not given. Nevertheless, the Leadfeeder B2B visitor-identification service (Dealfront, provider Liidio Oy) bypasses this refusal: at +3758 ms its lftracker (sc.lfeeder.com) loads, at +4670 ms a beacon is sent to tr.lfeeder.com (response 200), and a persistent _lfa cookie with a visitor identifier is written to the device. That is, under a refused statistics state Leadfeeder both stores an identifier on the device and transmits visit data — whereas the service itself is described in the policy precisely as a web-analysis tool that reports which companies visit the site. That is, WPConsent gates Google analytics, but Leadfeeder is not conditioned on the actual consent state.


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-ts-ee/

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 — ts.ee

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

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

1) The site has the WPConsent consent management platform installed, and it holds Google analytics correctly: the GA4 events (G-DWDWJ7YNQ6) go out with the status gcs=G100 — both storages denied, the pings cookieless. The consent state is unambiguous: the WPConsent record wpconsent_preferences contains statistics:false, meaning consent for statistics is not given. Nevertheless, the Leadfeeder B2B visitor-identification service (Dealfront, provider Liidio Oy) bypasses this refusal: at +3758 ms its lftracker (sc.lfeeder.com) loads, at +4670 ms a beacon is sent to tr.lfeeder.com (response 200), and a persistent _lfa cookie with a visitor identifier is written to the device. That is, under a refused statistics state Leadfeeder both stores an identifier on the device and transmits visit data — whereas the service itself is described in the policy precisely as a web-analysis tool that reports which companies visit the site. That is, WPConsent gates Google analytics, but Leadfeeder is not conditioned on the actual consent state.

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

3. GDPR provisions I ask you to examine
ePrivacy — Directive 2002/58/EC, Art. 5(3) (in conjunction with GDPR Art. 6(1)(a)) — storing an identifier and tracking under a refused statistics state

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]