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

arXiv:2608.13390 · cs.CR · Submitted 2026-08-13 · Read on arXiv

Luca Ferrari, Mariano Ceccato, Luca Verderame

cs.CR

Submitted: 2026-08-13

Updated: 2026-08-14

Code: https://github.com/Mobile-IoT-Security-Lab/TeleGapper

License: http://creativecommons.org/licenses/by-nc-sa/4.0/

Importance score: 75/100

The gist: 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

Terminology

Summary

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 a…

Improvements for AI systems

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.

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.

Sources

Related papers