self.julianus.ee

Context

self.julianus.ee is the self-service portal of Julianus Inkasso OÜ, registration code 10686553, Tallinn, Toompuiestee 35. The company provides debt collection services; per its own terms, it acts as the controller when collecting debts, operating in its own name and as a credit collection firm. Data protection contact: andmekaitse@julianus.ee. The portal is built on a Ruby application behind Apache and Phusion Passenger, and sets no proprietary Content-Security-Policy header.

The measurement consists of two captures. The first — the debtor’s personal account: a sequence of navigations to /debts, the “My Debts” page, the visitor authenticated. Fifty-two requests, eight hosts, 33 outbound calls. The second — the public page /debtors, titled “Wall of Shame”: an open registry of debtor companies, searchable by name and registration number. Forty-six requests, 31 of them outbound. Both were captured on July 31, 2026, five and a half minutes apart, in the same browser.

Processing is described by a single document — Julianus Inkasso’s data-protection terms, revision dated April 30, 2025. The Estonian original is stated to be legally binding.

Who receives data directly

Google (Analytics, Tag Manager), MindTitan, Postimages.

Declared versus actual

The document is detailed: ten sections, a separate annex, a list of data sources, a breakdown of processing bases. It honestly lists what the company knows about a debtor — down to information about their financial position and payment defaults. It says less about the site, but it does say something: section 4.3.5 classifies as technical information the actions taken in the system, including login and navigation, operating system, browser, timezone, IP address, and other cookie-collected data. Section 4.7.5 adds — with the data subject’s permission.

The measurement reveals four discrepancies, and the first of them differs fundamentally from the usual story of an undisclosed counter.

First — a signal about debt status goes to Google. At +815 and +819 ms into the session in the account, two requests fire carrying the event ss_debtor_loggedin. This is not a standard name from Google’s built-in set — the event is custom-built in the resource’s own settings. The container’s configuration shows the entire rule: the event is created from a page view, on the condition that the address contains /debts. In other words, someone deliberately configured a transformation of “visited the my-debts page” into a tagged event, “the debtor has logged in.” Along with the event go a client identifier, the page title “Julianus Inkasso | My Debts,” and the virtual path /debts#sisse_logitud — Estonian for “logged in.”

The event is not alone. The same container has ss_debtor_payment, ss_debtor_contactus_start, and ss_creditor_submitdept_start configured — a debtor’s payment, a debtor starting to contact support, a creditor submitting a claim. This is a complete funnel-measurement scheme, built on the actions of people involved in debt proceedings.

Particular weight is added by the fact that the client identifier in the account and on the public registry page is the same one. Visiting the open “Wall of Shame” and logging into the debtor’s personal account are stitched into a single profile on Google’s side.

Second — there is no consent mechanism, even though the document implies one. Section 4.7.5 describes cookie-derived data as collected with the data subject’s permission. Section 8.2.5 goes further: as a rule, the company does not process data on the basis of consent, but in the case of cookies, the data subject may withdraw their consent at any time — implying that consent was given in the first place. Section 4.3.5 refers to “the browser’s cookie notice” for details. There is no notice, no banner, and no consent-management platform on the portal.

Third — the composition and nature of the recipients. Neither Google, MindTitan, nor Postimages is named in the document. The list in section 6.3 consists of categories, including a line about ICT partners who may, depending on the service, gain access to all personal data. Both the chatbot and the analytics could formally be filed under this. But section 6.3(a), concerning advertising and marketing partners, carries a caveat: they typically receive site-usage data in non-personalized form. An event carrying a client identifier and a tag marking a debtor’s login does not fit that caveat.

The chatbot deserves separate mention: 25 requests per page to two hosts of the TitanCS service, developed by the Estonian company MindTitan, hosted on the subdomain julianus.titancs.mindtitanapps.com. The service is integrated into the account, where the user discusses their debt. Section 4.7.4 of the terms confirms that data submitted in the chat is processed, but does not name the provider. The chat icon, meanwhile, is pulled from the public file host i.postimg.cc, whose owner is shielded by an Icelandic privacy service — the account visitor’s IP address goes there with no necessity whatsoever.

Fourth — a running counter that no one needs. The pages have the Universal Analytics resource UA-6990595-1 inserted: data processing for it stopped in 2023. Requests to it nonetheless fire and carry the IP address, page title, screen resolution, and window size. Worse still: it is precisely this outdated counter that automatically pulls the GA4 container onto the page — the one that then sends the debtor-login event. The page’s markup contains only the old code snippet — the new counter appears on its own, through Google’s related-resource mechanism.

Separately worth noting is section 8.2.8, which states that automated processing and profile analysis that significantly affect the data subject are not used. The event-based scheme in the analytics is not the same as an automated decision about the debt, and is not recorded as a violation of this section. But the very construction of a behavioral profile of a debtor, on the side of an external platform, is not described anywhere in the document.

Consent: what is proven and what is not

Proven: there is no consent mechanism on the portal. Across both captures, 98 requests, there is not a single request to a consent-management platform and not a single script bearing the corresponding hallmarks. No response sets a Set-Cookie header. Known platform names and common patterns in addresses and page markup were checked, with zero matches. The account’s markup contains neither a consent-mode fragment nor a data-layer object — only a direct counter insertion.

Proven: the counter’s loading does not depend on a user’s choice. The code snippet sits in the header section of the account page and executes as the browser parses it; the request for the script fires at +531 ms, and the first transfer at +603 ms. There is no condition preceding this code.

Proven: the debt-status event was created by configuration, not by accident. The transformation rule reads verbatim in the container’s configuration: the name of the new event is ss_debtor_loggedin, the source event is a page view, and the condition is that the page address contains /debts. This is a deliberate setting in the analytics interface, not a side effect.

Proven: the identifier existed before the capture began. Based on the timestamp embedded within it, it was created at 16:05:50 UTC — five minutes before the first measurement, from an earlier opening of the portal. The identifier is the same across both captures.

Not proven, and not required for the finding: the account’s contents. What specific sums and claims were displayed to the visitor is immaterial to the finding and is not used in this review. What matters is that the mere fact of being in the debtor’s account was transmitted outward, tied to an identifier.

Separately: the browser sent a DNT: 1 header during capture. This did not affect the composition or volume of the transfers.

Boundaries of this observation

The measurement covers two pages of the portal — the personal account and the public registry. The observation records browser behavior, not the internal workings of the services: server-side processing, contractual relationships with recipients, and settings on the recipients’ side are not verified by a browser-based measurement. Legal assessment falls to the competent authority — the Andmekaitse Inspektsioon, whose oversight is explicitly named in section 3.3 of the terms themselves.

The published files have been cleaned of personal data: Cookie headers in requests were removed. Response bodies and page markup were preserved, so the counter insertion, the container’s event configuration, and the chatbot’s settings can be verified directly from the published files. The full client identifier is not reproduced in this review; its existence and consistency across both captures are established from the requests to Google themselves.

Service identification rests on domains, URL schemes, and configuration contents: Google — via google-analytics.com and googletagmanager.com, with the identifiers of both resources; MindTitan — via mindtitanapps.com, the chatbot’s path scheme, and its configuration parameters; Postimages — via postimg.cc. The public registry in the second capture contains only information about debtor companies with registration numbers; no individual’s data appeared on the viewed page, and none is included in this review.

The ss_debtor_payment event did not fire during the captures — only its presence in the container’s configuration is recorded. What exactly it transmits upon payment is not established by a browser-based measurement of these two pages.

Conclusion

A debt collection agency transmits to Google a signal that a specific visitor is a debtor who has logged into their account. This is not a side effect of a standard counter: the ss_debtor_loggedin event is built as a distinct rule, triggered by the “My Debts” page address, and fires alongside a client identifier and the page title. In the same configuration, events for a debtor’s payment and their contact with support are also configured nearby. The identifier is shared between the account and the public registry, meaning both visits are stitched into a single profile.

There is no consent mechanism on the portal at all, even though the data-protection terms twice describe cookies as processed with the data subject’s permission and refer to a cookie notice that does not exist. Not a single web-data recipient is named: neither Google, nor the provider of the chatbot integrated into the debtor’s account, nor the third-party file host from which that chat’s icon is pulled. The Universal Analytics resource running on the pages has been invalid since 2023, yet continues to transmit data — and it is precisely this resource that pulls in the container sending the debtor event.

The financial position of a person in debt proceedings is a category of data demanding the highest degree of care; for an operator whose principal activity consists of handling such data, transmitting a signal about debt status to an external analytics platform, with no consent and no disclosure of the recipient, is an indicator of non-compliance of both consent rules and transparency requirements.

Remedy: immediately remove the ss_debtor_loggedin event and its related events from the analytics configuration, and exclude any transmission of debt-status indicators outward; remove the counter from the personal account entirely, or introduce a consent mechanism that genuinely governs its loading; remove the discontinued Universal Analytics resource; name all web-data recipients by name in the data-protection terms, including the chatbot provider; move the chat icon onto proprietary infrastructure.