TeleGapper: On the (un)reliability of Privacy Policies in Telegram Mini apps

TeleGapper: On the (un)reliability of Privacy Policies in Telegram Mini apps

Abstract

Telegram Mini Apps are Web applications embedded within the Telegram client, forming an ecosystem of third-party services within one of the world's most widely used messaging platforms. Despite their growing adoption and access to Telegram-provided context, their privacy properties remain largely unexplored. Unlike ecosystems such as WeChat, which rely on tightly controlled, proprietary execution frameworks, Telegram adopts a different model: Mini Apps run inside a WebView, combining platform-provided context with standard Web capabilities and unrestricted outbound networking. This enables applications to transmit sensitive information to analytics, advertising, tracking, or other third parties through ordinary Web requests, often with limited visibility.

Privacy disclosures are therefore critical for transparency. Telegram allows Mini Apps either to define an application-specific privacy policy or to rely on a platform-provided default policy. While the latter reduces the developer's disclosure burden, it may lead to generic statements that do not accurately capture actual data practices of individual Mini Apps.

In this paper, we present TeleGapper, a black-box dynamic analysis framework to assess the privacy posture of Mini Apps by capturing runtime network traffic, identifying third-party communications, and comparing observed data flows against disclosed privacy information. We evaluate 278 working Mini Apps collected from tApps Center, a community-driven catalogue for discovering third-party applications in Telegram. We find that 59.4% contact at least one undisclosed third party, 78.8% rely exclusively on Telegram's default privacy policy, and none provides a consent or opt-out mechanism. These findings expose a substantial transparency and compliance gap in a widely used yet understudied ecosystem.

Keywords: Mini App, Telegram, Dynamic Analysis, Privacy Violation, Network Analysis

1. Introduction

Mini apps have recently emerged as a rapidly expanding paradigm in mobile computing, consisting of small, lightweight software programs that run inside a larger host or super app. They support a broad range of services traditionally offered by standalone mobile applications, including e-commerce, food delivery, transportation, payments and financial services, entertainment, ticketing, and productivity tools, while providing users with direct access within the host platform. Notably, some of the most prominent mini app ecosystems are embedded in large-scale social and messaging platforms, such as WeChat, AliPay, TikTok, and Telegram. By integrating third-party services directly into these widely used environments, mini apps allow users to access diverse functionality without leaving the host platform.

The tight integration with the super app, however, is also what makes mini apps privacy-sensitive: they execute within an already authenticated user session and can access account identity and device context through privileged host APIs.

Among these ecosystems, Telegram stands out both for its scale and for its distinct architecture. Its Mini Apps reached an estimated 150–190 million active users in 2025, yet have received comparatively little research attention. Unlike ecosystems such as WeChat, Alipay, and Baidu, where mini apps are packaged using platform-specific languages and manifests, submitted to the host platform, and distributed through its infrastructure, Telegram Mini Apps (hereafter, Mini Apps) are ordinary Web applications loaded from developer-controlled URLs inside a WebView. This differs substantially from the more standardized and tightly specified models adopted in other ecosystems, as Telegram retains the flexibility and openness of the Web.

This distinction is methodological as much as architectural. Prior analyses of unintended data collection in Chinese mini app ecosystems can inspect application packages before execution. Telegram provides no equivalent package to decompile or manifest to audit: the application is retrieved dynamically from the developer's infrastructure at runtime. Consequently, static and taint-analysis approaches designed around inspectable mini app artifacts do not directly transfer, motivating a runtime perspective on the privacy behavior of Mini Apps.

Moreover, the Terms of Service for Mini Apps enumerate what a Mini App obtains the moment it is opened, without asking and before the user can act: the IP address, which follows from the page being fetched over HTTPS, and, through initData, the Telegram user ID, public name, username, profile picture, language tag, and premium status. Telegram, however, disclaims control over what is exchanged once these data have been transmitted to the Mini App.

Two consequences follow. First, a Mini App does not need to request an identity explicitly: it receives one before the user can perform any action, meaning that data collection can begin as early as Mini App load. Second, once that identity has been disclosed, the privacy policy becomes the primary means through which users can understand how it is subsequently processed and shared: a custom notice where the developer publishes one, or Telegram's Standard Bot Privacy Policy, which applies by default otherwise.

This arrangement is governed by privacy regulations that place obligations on the developer, who typically acts as the controller for the data processed by the Mini App. Articles 13 and 14 GDPR require the recipients of personal data, or at least their categories, to be disclosed to the data subject. Both are relevant here: the Mini App may collect data directly from the user while receiving other data from Telegram. Article 5(3) of the ePrivacy Directive further requires prior consent for storing information in, or accessing information from, the user's terminal equipment, unless a statutory exception applies.

These conditions create an accountability gap between declared and actual data practices. While similar risks arise across super-app ecosystems, which centralize user data and delegate access to mini apps, verifying whether the data flows generated by an individual mini app are consistent with its privacy disclosures remains challenging. The developer is the only party that directly knows both the recipients declared in the policy and those actually contacted; users cannot readily observe where their data are forwarded, and external auditors or data protection authorities cannot realistically inspect every application individually. This problem is particularly acute for Telegram: its Web-based architecture provides no publicly inspectable application artifact from which such flows can be inferred before execution. As a result, there is currently no systematic way for external parties to determine which third parties receive Mini App data, whether those recipients are disclosed, and when such transfers occur.

To investigate this gap in the Telegram ecosystem, we define four research questions (RQs):

• RQ1: Do Telegram Mini Apps comply with their stated privacy policies?

• RQ2: How widely is Telegram's Standard Bot Privacy Policy used, and does providing a custom policy correspond to better compliance?

• RQ3: At which stages of the Mini App lifecycle do privacy violations occur?

• RQ4: What types of user data are predominantly shared with undeclared third parties?

To answer these RQs, we developed TeleGapper, a black-box dynamic analysis framework that requires no access to application code and takes as its only input the name of the bot associated with a Mini App. TeleGapper retrieves the applicable privacy policy, launches the Mini App from the Telegram client, intercepts its outbound traffic through a man-in-the-middle proxy, and separates traffic generated at page load from that produced during user-driven exploration. The contacted domains are then compared with the recipients declared in the applicable policy, either the custom notice exposed by the developer or, in its absence, Telegram's Standard Bot Privacy Policy.

We applied TeleGapper to 278 working Mini Apps sampled from tApps Center, a widely used community-driven catalog, with more than 4 million subscribers, that provides a large and publicly accessible entry point for discovering third-party applications in the Telegram ecosystem. We find that 59.4% contact at least one third party that the applicable policy does not disclose, and that such contacts are seldom isolated: 63.0% of violating apps reach two or more undeclared recipients, 2.78 on average and up to 14. The large majority of Mini Apps (78.8%) do not expose a custom privacy notice and instead rely on the Standard Bot Privacy Policy; apps that provide a custom policy violate it at a statistically indistinguishable rate (p = 0.55). Violations are also front-loaded: 85.5% of violating apps contact undisclosed third parties at page load, before any user action is possible. Across all 278 apps, not one presented a cookie banner, consent dialog, or other mechanism through which the user could accept, refuse, or configure the processing of personal data.

In summary, this paper makes the following contributions:

• We present the first empirical study of privacy-policy compliance in the Telegram Mini App ecosystem, covering 278 Mini Apps observed at runtime over five independent runs.

• We propose TeleGapper, a dynamic analysis framework that detects undeclared third-party data flows in Mini Apps without access to application code, requiring only a bot name as input.

• We derive from Telegram's Standard Bot Privacy Policy an explicit set of violation classes, making the default regime that governs 78.8% of the analyzed ecosystem operational for automated analysis.

• We demonstrate that the absence of consent mechanisms is widespread across the analyzed ecosystem and identify concrete platform-level countermeasures that Telegram could deploy.

• We release our Mini App scraper and dataset of 991 catalog entries to support replication and future work.

2. Background

The Telegram Mini App Architecture. Compared to mini apps adhering to the W3C Mini App standardization model, such as WeChat, Baidu, and Alipay, Telegram Mini Apps follow a fundamentally different architectural paradigm. Rather than being bundled into a single compressed package and executed in a controlled native-like environment, Mini Apps are full-fledged web applications hosted on third-party platforms (e.g., Vercel, Netlify). These applications are ultimately invoked via Telegram bots, which are automated software entities operating within the Telegram platform. They act as virtual chat partners that users interact with through text messages, predefined commands, inline queries, or interactive buttons, serving as entry points for launching the Mini Apps.

Due to the absence of a standardized packaging format or a mandatory application framework, the internal structure of a Telegram Mini App depends entirely on the developer's technology stack. A Mini App may be implemented using plain HTML, CSS, and JavaScript, or using common frontend frameworks such as React or Svelte, and is typically deployed on external hosting services. From an architectural perspective, it is useful to distinguish between a frontend component and a backend component. The frontend is the web application rendered inside the Telegram WebView and is responsible for the user interface, client-side logic, and interaction with the Telegram WebApp API. The backend, when present, is an external service under the developer's control that exposes application APIs, executes server-side logic, validates Telegram initialization data, stores persistent data, and may interact with the Telegram Bot API on behalf of the service.

Telegram Mini App Execution Ecosystem. Telegram Mini Apps operate within a distributed execution ecosystem involving multiple components and communication paths:

1. Telegram Client. The Telegram client functions as a super-app, providing a runtime environment and a WebView container in which the Mini App is rendered and executed.

2. Telegram Bot. The Telegram Bot serves as the interface between the user and the Mini App, triggering the app through specific commands or UI elements.

3. Telegram Mini App. The Mini App itself is a web application that executes within the Telegram WebView, leveraging standard web technologies and communicating with the Telegram WebApp API.

4. Telegram Server. The Telegram server exposes the Telegram Bot API, an HTTPS-based interface used by the bot backend to exchange data with the Telegram platform.

Mini App Market. Similar to traditional Super Apps, a user can retrieve a list of mini apps by entering keywords in a built-in interface within the Telegram app. In addition to official discovery channels, the ecosystem contains alternative third-party marketplaces such as tApps Center and FindiMini.app. These alternative platforms often serve as decentralized repositories that host a broader, unverified range of Mini Apps.

Telegram Policies. To govern both the use of the Telegram client and the operation of Mini Apps hosted on the platform, Telegram provides a set of interrelated normative documents: (i) the Telegram Privacy Policy, (ii) the Terms of Service for Bots, (iii) the Terms of Service for Mini Apps, and (iv) the Standard Bot Privacy Policy.

1. Telegram Privacy Policy. Telegram does not provide a standalone privacy policy for Mini Apps; instead, it subsumes them within the broader bot ecosystem. The policy expressly states that the use of both Bot and Mini App features is governed, respectively, by the Terms of Service for Bots and the Terms of Service for Mini Apps. In this framework, third-party developers are treated as independent entities from Telegram, and interactions with bots or related features may disclose public profile data, user messages, interface language, membership information in groups, and, when external links are accessed, the user's IP address.

2. Terms of Service for Bots. The Terms of Service for Bots explicitly place Mini Apps within the same third-party ecosystem as bots. They further state that access to a Mini App is additionally governed by the Terms of Service for Mini Apps, while Telegram disclaims liability for the availability, operation, and loss of any data, assets, or functionality delivered through either Bots or Mini Apps.

3. Terms of Service for Mini Apps. The Terms of Service for Mini Apps further specify the privacy and liability regime applicable to Mini Apps. Telegram states that Mini Apps are third-party services operated by independent Service Providers, who are solely responsible for their operation, maintenance, content, and availability. From a data-processing perspective, a Mini App automatically acquires the user's IP address and may receive basic account metadata, including the Telegram user ID, public name, username, profile picture, client language tag, premium subscription status, and selected in-app theme parameters. If launched from a private chat, it may also receive basic information about the chat partner; if opened from channels or group chats, it may additionally obtain the ID, type, title, username, and photo of the corresponding chat. Telegram further specifies that such data are shared with the relevant Service Provider and that, once transmitted, Telegram no longer controls the subsequent exchange of information between the user and the provider.

4. Standard Bot Privacy Policy. The Standard Bot Privacy Policy functions as a default privacy notice for third-party bots and Mini Apps hosted on the Telegram platform and applies in the absence of a separate privacy policy disclosed by the Mini App developer. It clarifies that such services are independent third-party applications that are neither maintained nor endorsed by Telegram, and that the policy governs exclusively the relationship between the Developer and the User, without replacing the Telegram Privacy Policy.

3. Related Works

Prior work has extensively investigated privacy and security issues in mini app ecosystems, particularly through static and taint-based analyses aimed at detecting sensitive data flows and inconsistencies between application behavior and declared privacy policies. However, most of this literature focuses on WeChat and other Chinese mini app ecosystems, while Telegram Mini Apps remain comparatively underexplored.

Several studies target privacy leakage and policy compliance. TaintMini constructs a universal data-flow graph to identify tainted flows within and across mini apps. Wang et al. analyze AST nodes to extract data types and operations and use a matching model to assess consistency between application code and privacy policies. MiniTracker instead builds an assignment flow graph (AFG) that integrates JavaScript and HTML data flows and applies property-based taint analysis to track sensitive information at finer granularity. These approaches demonstrate the effectiveness of code-level analysis for detecting privacy-relevant behavior, but fundamentally rely on the availability of inspectable mini app artifacts.

A parallel line of work investigates security vulnerabilities in mini app ecosystems. Wang et al. characterize common bugs in WeChat mini apps and develop automated detection techniques, while Yang et al. identify cross-mini app request forgery attacks. Other studies show that vulnerabilities can originate from the host platform itself. For example, Zhang et al. identify authentication weaknesses that may lead to identity-confusion attacks and unauthorized access to privileged APIs, whereas Wang et al. uncover undocumented and insufficiently protected host APIs that may allow mini apps to bypass platform restrictions.

More recently, MiniEval extends privacy-oriented analysis by combining automated compliance-violation detection with quantitative privacy-risk assessment. Together, these works provide increasingly sophisticated techniques for analyzing privacy and security in conventional mini app ecosystems. Their applicability to Telegram, however, is limited by a fundamental architectural difference: Telegram Mini Apps are Web applications dynamically loaded from developer-controlled URLs rather than packaged artifacts that can be statically inspected before execution.

Research specifically targeting Telegram Mini Apps remains limited. Mohammadi et al. analyze security vulnerabilities and exploits in Telegram Mini Apps and propose a dedicated mitigation framework that focuses on architectural weaknesses such as unproxied communication, insecure HTTP configurations, WebView-related attacks, and general privacy leakage. Their work, however, does not systematically compare runtime third-party communications with the privacy disclosures presented to users, nor does it investigate when potentially undisclosed communications occur with respect to user interaction and consent.

Our work addresses this complementary gap. Rather than inspecting application code or focusing on exploitable vulnerabilities, we analyze Telegram Mini Apps as black boxes at runtime. To the best of our knowledge, this is the first empirical study to systematically assess whether their observed third-party communications are consistent with the applicable privacy policies and whether such communications occur before users are given an opportunity to provide consent.

4. Standard Bot Privacy Policy Analysis

The Standard Bot Privacy Policy defines the default data-handling regime for Telegram third-party bots and Mini Apps when no developer-specific privacy notice is provided. Its role is not merely descriptive: it establishes a baseline of permitted data collection, processing, and disclosure for services relying on the default policy.

The policy defines a Third-Party Service as the bot or Mini App operated by the developer. From a data-processing perspective, such services may access the limited set of user information exposed through Telegram and process it only insofar as necessary for their designated features. This introduces an explicit necessity constraint: the mere availability of user information does not, by itself, justify its collection or processing. Identifiers, profile metadata, and initialization data should therefore be processed only when relevant to the functionality provided by the service.

The policy further constrains downstream disclosure. Private user information must not be transferred or made accessible to third parties unless such sharing is explicitly authorized by the user or otherwise permitted by the policy or applicable law. Consequently, outbound communications with external analytics, advertising, tracking, or auxiliary services become policy-relevant when they involve user-related information and no corresponding authorization or disclosure can be established.

The policy also imposes purpose-limitation and data-minimization requirements. Developers may not use user data outside the scope of the Third-Party Service unless such use is clearly stated and explicitly agreed to by the user, and data collection must remain limited to what is necessary to provide or enhance the service functionality. The developer is further responsible for handling, transferring, and storing user information in accordance with applicable law. We therefore treat processing that is unrelated to the declared service functionality, or sharing with undeclared external recipients, as potentially inconsistent with the default policy.

Finally, the policy grants users rights over personal information collected and stored by the Third-Party Service, including access, deletion, restriction, objection, and withdrawal of previously given consent. Although these requirements cannot be fully evaluated through network observation alone, they reinforce the policy's broader expectation that processing should remain transparent, limited, and accountable.

Table 1 summarizes the policy constraints that can be operationalized through our dynamic analysis. The violation classes derived from the Standard Bot Privacy Policy and their observable network-level indicators include:

• Undisclosed third-party communication: Requests to external domains not identified in the applicable privacy policy, indicating communication with recipients that are not disclosed to the user and may therefore fall outside the declared processing scope.

• Third-party transmission of user data: User identifiers or profile attributes transmitted to an external domain, indicating disclosure of user-related information to a third party, which requires an applicable policy basis or user authorization.

• Potential over-collection: Transmission of Telegram-provided attributes not evidently required by the observed service functionality, which may indicate processing beyond what is necessary for the designated features of the Mini App.

• Pre-interaction third-party communication: External requests generated at page load before meaningful user interaction, identifying data flows occurring before the user can interact with the Mini App or provide application-level authorization.

• Tracking or advertising communication: Requests to domains classified as analytics, advertising, or tracking services, identifying processing that may fall outside the core service functionality and therefore requires explicit disclosure or authorization when user data are involved.

5. TeleGapper: Design and Analysis Workflow

5.1. Framework Overview. We present TeleGapper, a black-box dynamic analysis framework for detecting privacy-policy violations in Telegram Mini Apps. Given only the name of the bot associated with a Mini App, TeleGapper analyzes the application at runtime by combining network-traffic inspection with the applicable privacy policy, without requiring access to its source code.

The workflow consists of three main components: (i) the Start Bot Module, (ii) the Dynamic Analysis Module, and (iii) the Traffic Analyzer Module. At a high level, TeleGapper identifies the target bot, retrieves the privacy policy associated with its Mini App, launches the application from the Telegram client, and performs black-box exploration while intercepting its network traffic. The collected traffic is then analyzed to identify user-data transmissions and compared with the applicable privacy policy. Notably, the workflow distinguishes traffic generated during Mini App initialization from traffic triggered by subsequent user interaction, allowing us to determine when privacy-relevant communications occur.

5.2. Bot Discovery and Privacy-Policy Retrieval. The Start Bot Module, given a bot name or a list of bot names, automatically opens the Telegram client, searches for the target bot, and opens the corresponding chat. The Privacy Policy Scraper Module then accesses the bot profile, navigates to the More options section, and retrieves the privacy policy exposed through the Privacy Policy entry. The retrieved policy is stored as an artifact and is later used by the Traffic Analyzer Module to determine which disclosure regime applies to the Mini App.

5.3. Dynamic Mini App Analysis. The Dynamic Analysis Module separates Mini App execution into two stages: initialization and user-driven exploration. This separation is central to our analysis because it allows us to distinguish network activity generated automatically at page load from activity triggered after the user starts interacting with the application.

The Mini App Initialization Module launches the Mini App from the bot profile and records all network traffic generated during the loading phase, without performing any user interaction. After allowing the application to complete its initial loading phase, the module extracts the HTML content of the rendered page. The HTML snapshot supports subsequent exploration and is also used to inspect the initial application state.

Following initialization, the Mini App Interaction Module explores the Mini App using the previously extracted HTML structure within a bounded exploration budget. Because Mini Apps may rely on standard DOM elements, canvas-based rendering, or a combination of both, TeleGapper adopts three exploration modes:

• Classic DOM Analysis: the module identifies clickable elements on the current page and activates them in randomized order, returning to the previous state after each interaction when possible.

• Canvas-Only Analysis: if no clickable DOM elements are available and a visible canvas is detected, the module partitions the visible canvas into a grid and performs randomized interactions across its cells.

• Hybrid Canvas and DOM Analysis: when both clickable DOM elements and a visible canvas are present, the exploration budget is divided between Classic DOM Analysis and Canvas-Only Analysis.

During exploration, the module records all performed interactions in JSON format to support reproducibility and captures the outbound network traffic generated by user-driven interaction.

5.4. Traffic and Policy Analysis. Once dynamic exploration completes, the Traffic Analyzer Module processes the traffic collected during initialization and user-driven exploration and produces two structured reports. The first report describes traffic observed during Mini App initialization, identifying user-related data transmitted to external services, the corresponding destination endpoints, and whether such transmissions occur before the user can meaningfully interact with the Mini App. The second report applies the same analysis to traffic generated during user-driven exploration.

For each observed transmission, the reports record the detected data type, value, and destination endpoint. The resulting network reports are then evaluated against the applicable privacy policy. When the Mini App relies on Telegram's Standard Bot Privacy Policy, the observed flows are assessed according to the policy-derived violation classes defined in Section 4. When a custom privacy policy is exposed, the reports are reviewed against that policy to determine whether the observed third-party recipients and data-sharing practices are disclosed.

We define a privacy-policy violation as the transmission of user data to a third-party domain that is not disclosed by the privacy policy applicable to the Mini App, namely the custom policy exposed by the developer or, in its absence, Telegram's Standard Bot Privacy Policy.

5.5. Repeated Observation and Review Protocol. The exploration strategy is randomized, and a single execution may therefore cover only a subset of a Mini App's reachable states and generated traffic. We consequently repeat the complete workflow (i.e., launch, initialization capture, interaction, and traffic capture) 5 times for each Mini App, restarting the Telegram client and clearing the WebView state between runs. Repetitions are used to increase behavioral coverage rather than to filter observations. We therefore take the union of the traffic observed across runs: a third-party contact is retained for a given Mini App and execution stage whenever it is observed in at least one run.

When a Mini App exposes a custom privacy policy, the reviewer follows an annotation protocol similar to [8]. The reviewer (i) reads the complete policy and marks statements describing data-collection or data-sharing practices and (ii) compares those statements with the third-party requests reported in the reports. A recipient is considered disclosed whenever the policy can plausibly be read as covering it; otherwise, the corresponding flow is recorded as a privacy-policy violation.

For each Mini App, we independently inspect the initial interface rendered at launch for observable consent artifacts, including cookie banners, consent dialogs, privacy notices requiring acknowledgment, or controls through which the user can accept, refuse, or configure data processing. This inspection is performed independently of the randomized exploration so that the interaction strategy cannot overlook an initially visible consent element.

6. Implementation Details

6.1. Dataset Scraper. To build the dataset used in the experimental campaign, we developed a dedicated scraper for tApps Center. The scraper is implemented in Python on top of Selenium, which drives a headless browser and allows us to collect catalogue entries rendered client-side, for which a plain HTTP-based crawler would retrieve no complete listing. The scraper enumerates the catalogue published by the portal and, for each entry, extracts the associated bot name together with the app title and category.

We selected tApps Center as the source of our sampling frame because it provides a large, publicly accessible, and structured catalogue for discovering third-party applications in the Telegram ecosystem. Its client-rendered listings expose bot names and associated metadata and can be collected automatically at scale using a headless browser. The catalogue also organizes Mini Apps into functional categories, allowing the sampled population to span different service domains rather than a single application type.

6.2. Mobile Automation and Exploration. The Start Bot Module and Dynamic Analysis Module are implemented using Appium, which enables automated interaction with Telegram and its embedded WebView-based Mini Apps. Given a bot name, the framework launches Telegram, locates the bot, opens the corresponding Mini App, retrieves the Privacy Policy, and performs interaction-driven exploration.

The Mini App initialization phase lasts 20 seconds before the HTML snapshot is collected. The subsequent interaction phase uses a 240-second exploration budget. For Canvas-Only Analysis, the visible canvas is partitioned into a grid of 8 rows and 4 columns. The module repeatedly selects a random cell and clicks a random position inside it. In Hybrid Canvas and DOM Analysis, the exploration budget is split evenly between DOM-based and canvas-based interaction.

6.3. Network Traffic Interception. To intercept and inspect network traffic generated by Mini Apps, we use Burp Suite as a man-in-the-middle (MITM) proxy. The analysis is performed on a rooted Google Pixel 9 configured with Magisk, allowing system-wide certificate installation and HTTPS traffic interception. The device routes its traffic through a workstation running Burp Suite, on which a custom CA certificate is installed to enable TLS decryption.

6.4. Traffic Analysis Pipeline. The Traffic Analysis Module is implemented as a post-processing pipeline that consumes the raw HTTP/HTTPS traces exported by the proxy and converts them into structured JSON artifacts. The module parses the plain-text logs and reconstructs individual requests by extracting the HTTP method, URL, host, headers, body, timestamp, and destination IP address.

To separate first-party Mini App traffic from external communications, the module infers the Mini App domain by combining multiple traffic signals, including the Origin and Referer headers and Telegram-specific initialization parameters such as tgWebAppData, initData, query id, and auth date. Requests matching the inferred Mini App domain are excluded from third-party inspection, while the remaining requests are treated as candidates for further analysis.

The pipeline then applies a set of regular-expression extractors to third-party requests to identify potentially sensitive information. The extractors cover Telegram identifiers, profile metadata, authentication tokens, API keys, cookies, device and browser metadata, visited-page URLs, location coordinates, analytics identifiers, and TON wallet addresses. Before matching, request contents are normalized through recursive decoding of URL-encoded values, extraction of query parameters and fragments, parsing of form-encoded payloads, flattening of JSON structures, and selective decoding of Base64-encoded content.

6.5. Background-Traffic Filtering. To reduce background noise, the implementation maintains an EXCLUDED HOSTS set containing infrastructure and runtime-generated domains that are not attributable to the analyzed Mini App. The set was constructed by manually inspecting traffic from 100 Mini Apps randomly sampled from tApps Center and retaining hosts that consistently appeared across unrelated applications and could therefore be attributed to the underlying Android or platform environment rather than to app-specific behavior. The excluded set includes, among others, Android and Google infrastructure used for connectivity checks, device verification, system libraries, and public assets.

6.6. Generated Artifacts. For each analyzed Mini App, the Traffic Analysis Module outputs two JSON reports, corresponding respectively to initialization traffic and interaction-generated traffic. Each report includes the inferred Mini App domain and the detected user-related data transmitted to external destinations.

7. Experimental Campaign and Analysis Results

The experimental campaign is supported by one dataset, DtApps, which comprises all Mini Apps available on tApps Center. DtApps consists of 991 catalogue entries, collected in the first half of June 2026 with the Mini App Scraper described in Section 6.

To answer the research questions, we applied our methodology to a random sample of DtApps. Using a confidence level of 95% and a margin of error of 5% over the 991 entries of DtApps, we set a target of 278 Mini Apps to be manually inspected. We then drew entries from DtApps uniformly at random, without replacement, across all Mini App categories, and submitted each of them to the pipeline described in Section 5, discarding those for which no runtime behaviour could be observed and drawing a replacement, until the target was met.

An entry was discarded according to the following criteria, each verified manually on the device after the automated attempt had failed:

• Deleted bot (27 entries). The bot name published in the catalogue yields no result when searched in the Telegram client, as the developer has deleted the bot after its listing was approved.

• Unreachable frontend (124 entries). The bot exists and the Mini App can be launched, but the WebView fails to render the application, as the domain serving the frontend no longer resolves, has expired, or returns an HTTP error.

• No profile-level entry point (13 entries). The bot exists and is reachable, but its profile does not expose the Open App shortcut on which our Start Bot Module relies, so the Mini App cannot be launched by our automation.

Reaching the target of 278 analyzable Mini Apps, therefore, required drawing 442 entries, 164 of which (37.1%) were discarded. The results reported in the remainder of this section are computed over the 278 Mini Apps that were successfully launched and observed at runtime. The experimental campaign was carried out on a 12th Gen Intel(R) Core(TM) i9-12900KS (3.40 GHz) server with 128 GB RAM, and on a rooted Google Pixel 9 (Android 16) with Telegram 12.7.3.

7.1. RQ1: Do Telegram Mini Apps actually comply with their stated privacy policies?

For each working app, we checked whether at least one violation, as defined in Section 5, occurred at either of the two monitored stages, i.e. at opening or during use. As shown in Table 2, more than half of the analyzed apps (59.4%) exhibit at least one violation with respect to what is declared in their own privacy policies.

Table 2: Privacy policy violations among the 278 working Mini Apps. An app counts as violating if it contacts an undeclared third party at opening, during use, or both.

Category N %

With at least one violation (at opening or during use) 165 59.4%

No violation detected 113 40.6%

We manually classified every third-party domain observed in the violating requests. Each domain was first attributed to the service and the provider operating it, which we then looked up in AppBrain, a publicly available catalogue that indexes third-party libraries and SDKs and assigns each of them to a category, such as ad network, analytics, social, or development tool.

This classification reveals that violations are concentrated in a small, clearly identifiable set of tracking and advertising services. Table 3 reports the five most frequently contacted third parties at app opening and during use, respectively.

Table 3: Five most frequently contacted third parties at opening and during use, across the 165 violating Mini Apps, with the number of Mini Apps in which each was observed.

Third party (opening) Occ. Third party (runtime) Occ.

Google Tag Manager 46 Yandex Metrica 33

Adsgram 40 Google Tag Manager 31

Yandex Metrica 17 Meta Analytics 19

Rtmark 16 TikTok Analytics 13

Monetag 14 Google Marketing 11

The recipients are few and recurring: only eight distinct services occupy the ten top-five positions, and two of them, Google Tag Manager and Yandex Metrica, appear at both stages, always within the top three. All eight are analytics, profiling or ad-serving services; none is a generic technical component or a diagnostic instrument such as a crash reporter. Adsgram, Monetag and Rtmark are advertising networks specific to or commonly used in the Telegram Mini App ecosystem, whereas Google Tag Manager, Google Marketing, Yandex Metrica, Meta Analytics and TikTok Analytics belong to general-purpose tracking and ad-serving infrastructures. A large share of this traffic, moreover, precedes any user interaction: Google Tag Manager is contacted at launch in 46 of the 165 violating Mini Apps (27.9%) and Adsgram in 40 (24.2%).

Table 4 reports, for each violating Mini App, the number of distinct undeclared third-party domains contacted at either monitored stage. In 61 cases (37.0%) the violation involves a single recipient, while the remaining 104 apps (63.0%) contact two or more undeclared third parties; 30 of them (18.2%) contact five or more, and the maximum observed in our sample is 14. On average, a violating Mini App discloses data to 2.78 undeclared third parties (median 2).

Table 4: Number of undeclared third parties per violating Mini App.

Undeclared third parties N %

1 61 37.0%

2 36 21.8%

3 26 15.7%

4 12 7.3%

5 or more 30 18.2%

Total 165 100.0%

Mean 2.78, Median 2, Range 1–14

RQ1 Answer: More than half of the working Mini Apps analyzed (59.4%, 165/278) were observed communicating with at least one third party not disclosed in their privacy policy. Violations are also seldom confined to a single recipient: 63.0% of the violating apps contact two or more distinct undeclared third parties, with an average of 2.78 per app (median 2, up to 14). Rather than isolated technical errors, these violations concentrate on a small, recognizable set of tracking and advertising services (Google Tag Manager, Adsgram, Yandex Metrica, Meta Analytics, TikTok Analytics), suggesting a recurring pattern of undeclared data sharing.

7.2. RQ2: How many Mini Apps use Telegram's Standard Bot Privacy Policy, and does exposing a custom one correspond to better compliance?

As shown in Table 5, out of 278 working Telegram Mini Apps, 219 (78.8%) rely on the Standard Bot Privacy Policy and do not expose a custom privacy policy. Only 59 Mini Apps (21.2%) provided a custom one.

Table 5: Privacy policy type among working Mini Apps.

Privacy Policy type N %

Standard (Telegram default) 219 78.8%

Custom 59 21.2%

With respect to the 219 Mini Apps relying on the Standard Bot Privacy Policy, Table 6 shows that 132 of them (60.3%) exhibit at least one privacy policy violation. Among the 59 Mini Apps with a custom privacy policy, 33 (55.9%) exhibit at least one violation. To establish whether this apparent gap reflects a genuine difference in disclosure accuracy rather than sampling variation, we tested the two groups for independence using Pearson's χ2 without continuity correction, and, as a confirmatory analysis, Fisher's exact test. Neither test reveal a significant association between policy type and violation status (χ2(1) = 0.36, p = 0.55; Fisher's exact test p = 0.55; odds ratio = 1.20, Cramér's V = 0.04).

Table 6: Privacy violations by privacy policy type.

Privacy Policy type Total With violation %

Standard (Telegram default) 219 132 60.3%

Custom 59 33 55.9%

Total 278 165 59.4%

RQ2 Answer: The large majority of working Mini Apps (78.8%, 219/278) rely on Telegram's default Standard Bot Privacy Policy rather than exposing a custom one, suggesting that most Mini Apps rely on the platform-provided disclosure rather than an application-specific policy. Exposing a tailored Privacy Policy, however, does not correspond to a statistically distinguishable improvement in disclosure accuracy. Violations affect 60.3% (132/219) of apps under the standard policy and 55.9% (33/59) of those with a custom one, a difference of 4.4 percentage points that is not significant (p = 0.55). Although our sample does not provide sufficient power to reliably detect an effect as small as the one observed, the practical takeaway remains unchanged: more than half of the custom policies still fail to mention at least one third party contacted during our observation.

7.3. RQ3: At which stages of the Mini App lifecycle do privacy violations occur?

Among the 165 working apps found to violate their stated privacy policy, we further disaggregated violations by the lifecycle stage at which they occur: during app opening, only during use, or at both stages. As shown in Table 7, more than half of the violating apps (88 out of 165, 53.3%) exhibit undeclared communication with third parties at both stages, while violations confined to a single stage are more than twice as frequent at opening (53, 32.1%) than during use (24, 14.5%).

Table 7: Breakdown of violations by session phase.

Sub-category N %

Violation only at opening 53 32.1%

Violation only during use 24 14.5%

Violation at both opening and during use 88 53.3%

Total with at least one violation 165 100.0%

The large majority of violating apps (141 out of 165, 85.5%) already exhibit undeclared third-party communication during Mini App opening, and in almost two-thirds of these cases (88 out of 141, 62.4%), undeclared communication is also observed during subsequent user interaction. This pattern is consistent with the architecture of Telegram Mini Apps, which are web applications loaded in an embedded browser: initialization scripts, third-party libraries, and tracking code may be executed at page load, while additional behaviors can be triggered later by user interactions, navigation between views, and asynchronous callbacks.

Taken together, the two categories involving the opening stage account for 141 of the 165 violating apps (85.5%), i.e. the large majority of violations already manifest before any meaningful in-app interaction. This timing is significant in light of a second, complementary observation: across all 278 working Mini Apps, manual inspection of the launch screen revealed no instance of a consent banner, dialog, or equivalent mechanism. In no case was the user given an in-app opportunity to accept, refuse, or configure data processing before it occurred.

RQ3 Answer: Privacy violations are frequently observed across multiple stages of Mini App execution rather than being confined to a single moment. More than half of the violating apps (53.3%, 88/165) exhibit undeclared third-party communication both at opening and during use, while single-stage violations occur more than twice as often at opening (32.1%) than during actual use (14.5%). This recurring pattern suggests that undeclared data sharing is not limited to isolated or transient events, but often spans both initialization and subsequent user interaction. Moreover, none of the 278 working apps presented an observable consent mechanism at launch, while 85.5% of violating apps already contacted undeclared third parties during the opening stage, before any meaningful in-app interaction or opportunity to express a preference.

7.4. RQ4: What types of user data are predominantly shared with undeclared third parties?

During manual inspection, each detected violation was annotated with the type(s) of data observed in the corresponding outbound request. Every violating Mini App contained at least one identifiable data category, so the annotation covers the full set of 165 violating apps. Table 8 reports the distribution of data categories across them.

Table 8: Categories of user data transmitted to undisclosed third parties.

Data type N % of violating

Device info 157 95.2%

User and Profile info 63 38.2%

Device information is by far the most frequently transmitted category, appearing in all but eight of the violating apps (157/165, 95.2%). User and profile information, such as Telegram specific identifiers and account metadata, is the second most common category (63/165, 38.2%). This is of particular concern, as such data can be directly associated with an identifiable Telegram account, rather than only with a device. Since the two categories are not mutually exclusive and every violating app falls in at least one of them, the two counts also determine their overlap: 55 apps (33.3% of the violating ones, 19.8% of all working Mini Apps) transmit both categories to undisclosed recipients, 102 (61.8%) transmit device information only, and just 8 (4.8%) transmit profile information without any accompanying device attribute. In other words, one violating app in three transmits both device and account-related information to undeclared recipients.

Within the Device info category, the transmitted attributes are not scattered across apps: a set of five fields appears together in almost every request, namely, device model, Android version, browser (WebView) version, device language and Telegram app version. A second group of attributes, comprising device OS, screen resolution and OS version, appears less frequently and predominantly after the user has started interacting with the app. Taken in isolation, none of these fields is particularly sensitive, and each has a plausible technical justification, such as layout adaptation or compatibility checks. Their systematic co-occurrence, however, may increase their fingerprinting potential: the five recurring fields, device model, Android version, WebView version, language, and Telegram app version, provide a combination of device characteristics that may contribute to distinguishing or correlating devices across sessions and applications sharing the same third-party recipient.

The User and Profile info category exhibits a different pattern. Rather than a heterogeneous set of attributes, what is forwarded is primarily information contained in the Telegram initialization payload (initData), often relayed to third parties with little or no filtering. In decreasing order of frequency, the observed fields are: Telegram user ID, first and last name, initData signature, authentication timestamp, profile picture URL, chat instance and chat type, initData hash, the entire initData blob, username, and language code.

RQ4 Answer: Device information is involved in almost every violating app (95.2%, 157/165), followed by User and Profile data (38.2%, 63/165); one violating app in three (33.3%) transmits both categories to undeclared recipients. Undeclared sharing is therefore not limited to technical parameters: device attributes are transmitted as a recurring co-occurring set with potential fingerprinting value, often at page load and before any observable in-app opportunity to express a preference, while user-related fields consist largely of information contained in the Telegram initData payload relayed with little filtering.

8. Discussion

The results presented in Section 7 quantify the divergence between the data practices declared by Telegram Mini Apps and those observed at runtime. RQ1 shows that 59.4% of the working Mini Apps in our dataset contact at least one third-party domain that is not disclosed in the privacy policy applicable to the app (Section 7.1); RQ2 shows that 78.8% of the analyzed apps rely on Telegram's generic Standard Bot Privacy Policy instead of publishing an app-specific one, and that this policy does not enumerate specific third-party recipients (Section 7.2); RQ3 shows that more than half of the violating apps (53.3%) exhibit undeclared third-party communication both at opening and during use (Section 7.3); and RQ4 shows that the data transmitted to undeclared third parties predominantly include device attributes (95.2% of the violating apps) and Telegram profile information (38.2%), with 33.3% of the apps transmitting both categories (Section 7.4).

The absence of observable consent mechanisms. A complementary finding concerns not what is disclosed but whether users are given an opportunity to express a preference before data processing occurs. Across the entire set of 278 working Mini Apps we analyzed, not a single one presented a cookie banner, consent dialog, or other interactive mechanism through which the user could accept, refuse, or granularly configure data processing at launch.

This observation is particularly relevant under Article 5(3) of the ePrivacy Directive, which generally requires prior consent when information is stored on or accessed from a user's terminal equipment, except where such access is strictly necessary for transmitting a communication or providing a service explicitly requested by the user. Accordingly, where the third-party tracking technologies we observe involve non-essential access to or storage of information on the terminal equipment, the absence of a prior consent mechanism raises a potential compliance concern.

As reported in Section 7.3, 85.5% of violating apps (141/165) already contact undeclared third parties during the opening stage, i.e., before any meaningful in-app interaction. This finding is especially relevant for analytics and advertising services, for which comparable Web deployments commonly rely on a consent-management mechanism when their operation requires consent under applicable law.

The absence of an application-level consent interface must also be considered in light of Telegram's own acceptance model. The Standard Bot Privacy Policy, which governs 78.8% of the apps in our sample, states that continued access to and use of a Third-Party Service constitutes acceptance of the policy, the Telegram Bot Terms, and the Telegram Mini App Terms. The Mini App Terms similarly construe continued access and use as acceptance of the applicable terms. This contractual acceptance mechanism, however, is distinct from any consent that may be required for a specific data-processing operation under applicable privacy law. Our measurements further show that undeclared third-party communications can occur immediately at page load, before users can interact with the Mini App or encounter any in-app mechanism through which processing choices could be expressed. This creates a temporal and transparency gap between the execution of data flows and the user's practical ability to understand or control them.

Implications for the platform. We argue that the gap documented by our measurements cannot be addressed solely at the level of individual developers, and that Telegram is particularly well positioned to introduce platform-level safeguards. We identify three concrete mechanisms that could strengthen this ecosystem:

• Runtime verification of declared data flows. Telegram could complement existing platform controls with a dynamic check similar to the one described in Section 5: launching the Mini App, observing its outbound traffic, and comparing contacted domains with the recipients or categories disclosed in the applicable privacy policy.

• Controls against hot updates. Unlike packaged mini apps, Telegram Mini Apps are Web applications served from developer-controlled infrastructure. Their content can therefore change after any initial review without requiring redistribution of a package through Telegram. One-off vetting can therefore provide only a point-in-time view of the application. Mitigating this limitation would require periodic or event-triggered re-verification and could be complemented by platform-level restrictions on external origins, for example through an enforceable Content Security Policy or an equivalent allow-list mechanism associated with the Mini App.

• Verification that apps remain functional. Of the 442 entries drawn from tApps Center, 151 (34.2%) corresponded to bots or frontends that were no longer functional: 124 had unreachable frontends and 27 bots no longer existed. Besides reducing catalogue quality, stale entries may introduce additional security risks. In particular, a domain that expires while remaining referenced by an existing bot or catalogue entry could potentially be re-registered and used to serve content different from that originally associated with the Mini App.

9. Threats to Validity and Limitations

9.1. Construct Validity. Single Telegram account. Our methodology requires an active, logged-in Telegram account on the analysis device. All measurements were therefore collected under a fixed account configuration, including a specific language tag, premium subscription status, theme parameters, and profile metadata. Since these attributes are part of the initialization payload transmitted to Mini Apps, the specific data categories observed in RQ4 may not generalize to accounts configured differently. The presence of undeclared third-party communication, however, does not depend on account configuration, so this threat concerns the characterization of what is shared rather than whether sharing occurs.

Scope of the consent-mechanism inspection. The absence of any consent artifact reported in Section 7.3 was established through manual inspection of the launch screen of each of the 278 working Mini Apps, and through the sessions observed during our analysis. It therefore attests that no consent banner, dialog, or equivalent control was presented at launch in the executions we observed, but it does not exclude the possibility that such a mechanism exists along application paths not reached by our exploration.

9.2. Internal Validity. Manual annotation of custom policies. For the 59 Mini Apps exposing a custom Privacy Policy, the classification of a third-party contact as declared or undeclared rests on a manual reading of the policy text and its comparison against the observed traffic. This judgment is inherently interpretive. We adopted a conservative criterion, counting a recipient as declared whenever the policy could plausibly be read as encompassing it, which biases our results toward under-reporting violations.

Exclusion of platform hosts. Requests to hosts in our EXCLUDED HOSTS set are filtered out before third-party inspection. If a Mini App were to transmit privacy-relevant data through one of these excluded hosts, our pipeline would not detect it, which again biases our results toward under-reporting.

Residual infrastructure traffic. Our pipeline separates first-party from Third Party communication by inferring the Mini App domain and by filtering the hosts listed in EXCLUDED HOSTS. Neither mechanism can capture the full set of endpoints that legitimately belong to a Mini App's own infrastructure: developers routinely serve assets and backend APIs through cloud and CDN providers under domains that cannot be listed beforehand and have no syntactic connection to the first-party origin. Requests of this kind are consequently retained in the report even when they carry first-party traffic routed through a delegated provider, generating noise in the Traffic Analysis Module results.

9.3. External Validity. Sample representativeness and temporal snapshot. Our study relies on a random sample of 278 working Mini Apps drawn from a population of 991 entries in DtApps. Following standard practices in empirical software engineering, this sample size was computed to ensure a 95% confidence level with a 5% margin of error. These parameters provide statistical coverage with respect to the tApps Center sampling frame, but do not guarantee representativeness of the entire Telegram Mini App ecosystem, since applications not listed in tApps Center fall outside our population. Furthermore, because Mini Apps are web applications dynamically served from developer-controlled infrastructure, our measurements inherently represent a temporal snapshot. Developers can alter their applications at any time without platform intervention.

9.4. Limitations. Unreachable Mini Apps due to missing UI entry points. The Start Bot Module opens a Mini App by navigating to the associated bot profile and selecting the Open App shortcut. However, not every bot exposes this shortcut directly from its profile page. When the Open App entry point is absent from the profile, our automated pipeline is unable to reach the Mini App, and the corresponding bot is excluded from the analysis, as was the case for 13 of the 442 entries drawn during sampling. This introduces a potential sampling bias toward Mini Apps that follow the most common, profile-exposed launch pattern.

Exploration coverage. The Mini App Interaction Module explores each app by clicking randomly, within a fixed budget of 240 seconds per run and k = 5 runs per app. Neither the budget nor the randomized strategy guarantees that all execution paths are reached. This limitation primarily affects the interaction stage. The initialization stage requires no exploratory interaction; the Mini App is simply launched and observed during page load. Consequently, the finding that 85.5% of violating apps already exhibit undeclared third-party communication at opening does not depend on interaction-path coverage.

10. Conclusion and Future works

This paper presented the first empirical study of Privacy Policy compliance in Telegram Mini Apps. Applying our dynamic-analysis framework TeleGapper to 278 working apps drawn from tApps Center, we found that 59.4% contact at least one third party that the applicable privacy policy does not disclose (RQ1); that the large majority of Mini Apps rely on Telegram's generic Standard Bot Privacy Policy (RQ2, 78.8%), while apps that do provide a custom policy exhibit a statistically indistinguishable violation rate; that undeclared third-party communication frequently spans multiple stages of execution (RQ3, 53.3% at both monitored stages); and that the data involved extend beyond technical device attributes to identifiable user and profile information in 38.2% of the violating apps, largely in the form of information contained in the Telegram initData payload relayed to third parties with little or no filtering (RQ4). Across all 278 apps, not one presented an observable consent mechanism at launch, while 85.5% of violating apps contact undisclosed third parties before any meaningful in-app interaction is possible.

Taken together, these results reveal a substantial gap between the privacy disclosures presented to users and the runtime behavior of Telegram Mini Apps. In particular, reliance on the default privacy framework provides limited transparency into the third-party communications performed by individual Mini Apps, while undeclared data sharing frequently begins during application initialization. Since our measurements cover only Mini Apps sampled from tApps Center and rely on deliberately conservative classification criteria, the figures we report should be interpreted as estimates for our sampling frame and may understate the prevalence of undeclared data flows.

Several directions remain open. On the tooling side, we plan to extend the framework to iOS, which requires a different automation and interception stack, and to investigate root-free TLS interception in order to lower the barrier to independent replication. On the measurement side, a longitudinal campaign would establish whether the violations we document persist across app updates, a question made particularly relevant by the hot-update capability discussed in Section 8. Finally, we intend to extend the analysis beyond privacy compliance toward the detection of security vulnerabilities and malicious behavior in Mini Apps, complementing the methodology presented here with a security-oriented analysis.

Improvements to AI Systems Based on This Paper

1. AI-Powered Privacy-Policy Compliance Auditor

• Improvement: Train a model to automatically extract disclosed third-party recipients and data-sharing statements from privacy policies (both custom and Telegram's Standard Bot Privacy Policy), then cross-reference them against observed network traffic.

• What it can do: Automatically flag Mini Apps that contact undisclosed domains, classify violation types (tracking, advertising, analytics), and generate compliance reports without manual annotation.

2. Real-Time Data-Flow Anomaly Detector

• Improvement: Build an AI system that learns the expected network behavior of a Mini App (first-party domains, benign infrastructure) and detects deviations in real time—especially during initialization before user interaction.

• What it can do: Alert users or platform operators the moment a Mini App transmits Telegram initData (user ID, profile info) or device fingerprints to an undeclared third party, even before the user interacts.

3. Consent-Mechanism Auditor

• Improvement: Use computer vision and NLP to automatically scan Mini App launch screens for consent banners, cookie dialogs, or opt-out controls, and classify whether they meet ePrivacy/GDPR requirements.

• What it can do: Scale the manual inspection performed in this paper to thousands of apps, detecting the absence of consent mechanisms and flagging apps that process data before any user choice is possible.

4. Predictive Violation-Risk Scorer

• Improvement: Train a classifier on the paper's dataset (policy type, category, third-party domains, data types) to predict the likelihood that a new Mini App will violate its privacy policy.

• What it can do: Prioritize audits for high-risk apps (e.g., those using common tracking SDKs like Google Tag Manager or Adsgram) and help Telegram or regulators target enforcement efforts.

5. Automated Policy-Violation Report Generator

• Improvement: Develop an NLP pipeline that converts raw network traces and policy text into structured, human-readable violation reports—including which data types were leaked, to which domains, and at which lifecycle stage.

• What it can do: Provide developers, regulators, and users with clear evidence of non-compliance, reducing the expertise needed to interpret technical traffic logs.

6. Longitudinal Hot-Update Monitor

• Improvement: Build an AI agent that periodically re-launches Mini Apps, captures traffic, and compares behavior over time to detect silent changes (e.g., new tracking SDKs added after initial review).

• What it can do: Address the hot-update limitation identified in the paper by continuously verifying that Mini Apps remain compliant after deployment, catching violations that appear only after updates.

7. Third-Party SDK Fingerprinting System

• Improvement: Train a model to recognize the network signatures of known tracking/advertising SDKs (Google Tag Manager, Yandex Metrica, Adsgram, etc.) from encrypted or obfuscated traffic patterns.

• What it can do: Identify undeclared third-party services even when domain names are disguised or traffic is encrypted, improving detection beyond simple domain matching.

8. User-Facing Privacy Transparency Assistant

• Improvement: Create an AI assistant that, given a Mini App's name, automatically runs a lightweight version of TeleGapper and presents the user with a plain-language privacy summary: This app shares your Telegram ID and device model with 3 undisclosed ad networks before you click anything.

• What it can do: Empower end-users to make informed decisions before engaging with Mini Apps, without requiring technical expertise.

9. Platform-Level Enforcement Recommender

• Improvement: Train a model to rank the most impactful platform countermeasures (e.g., Content Security Policy restrictions, domain allow-lists, mandatory consent dialogs) based on observed violation patterns.

• What it can do: Help Telegram prioritize engineering efforts by quantifying which safeguards would eliminate the largest share of violations (e.g., blocking Adsgram and Google Tag Manager at launch would reduce violations by 52%).

10. Cross-Ecosystem Privacy Benchmarking Tool

• Improvement: Extend the TeleGapper methodology to other super-app ecosystems (WeChat, TikTok, etc.) using transfer learning on the network-traffic and policy features.

• What it can do: Enable comparative privacy assessments across platforms, identifying which ecosystems have the worst compliance gaps and which architectural choices (WebView vs. packaged apps) correlate with better or worse privacy outcomes.

Telegram Mini Apps are Web applications embedded within the Telegram client, forming an ecosystem of third-party services within one of the world's most widely used messaging platforms. Despite their growing adoption and access to Telegram-provided context, their privacy properties remain largely unexplored. Unlike ecosystems such as WeChat, which rely on tightly controlled, proprietary execution frameworks, Telegram adopts a different model: Mini Apps run inside a WebView, combining platform-provided context with standard Web capabilities and unrestricted outbound networking. This enables applications to transmit sensitive information to analytics, advertising, tracking, or other third parties through ordinary Web requests, often with limited visibility. Privacy disclosures are therefore critical for transparency. Telegram allows Mini Apps either to define an application-specific privacy policy or to rely on a platform-provided default policy. While the latter reduces the developer's disclosure burden, it may lead to generic statements that do not accurately capture actual data practices of individual Mini Apps. In this paper, we present TeleGapper, a black-box dynamic analysis framework to assess the privacy posture of Mini Apps by capturing runtime network traffic, identifying third-party communications, and comparing observed data flows against disclosed privacy information. We evaluate 278 working Mini Apps collected from tApps Center, a community-driven catalogue for discovering third-party applications in Telegram. We find that 59.4% contact at least one undisclosed third party, 78.8% rely exclusively on Telegram's default privacy policy, and none provides a consent or opt-out mechanism. These findings expose a substantial transparency and compliance gap in a widely used yet understudied ecosystem.