Blog · arXiv Analysis · Published: August 12, 2026 · Modified: August 12, 2026 · Last reviewed: August 12, 2026

The Mini App Policy Becomes the Runtime Gap

A runtime-policy gap is the difference between the recipients and data practices an applicable privacy policy can plausibly be read to disclose and the client-side transmissions observed during a versioned, bounded test. It is evidence about correspondence between notice and execution. It is not, by itself, proof of unlawful processing, invalid consent, or a distinct corporate recipient behind every domain.

An embedded app can begin that execution as it opens, before a person explores the service or encounters an application-level choice. A platform that supplies the launch surface and WebView can test part of the gap. The governance task is to act on that evidence without pretending the test saw every path, every backend transfer, or every legal fact.

The Paper

The source is Luca Ferrari, Mariano Ceccato, and Luca Verderame’s TeleGapper: On the (un)reliability of Privacy Policies in Telegram Mini apps, arXiv:2608.13390v1 [cs.CR], submitted August 13, 2026. The version analyzed here is the versioned arXiv record. It is a black-box measurement study of sampled, reachable Mini Apps—not a court decision, a regulator’s compliance audit, or a census of Telegram’s whole ecosystem.

The paper calls a transmission of user data to a third-party domain not disclosed by the applicable policy a “privacy-policy violation.” This essay uses measured mismatch for that operational class. The change in vocabulary matters: an engineering classifier can surface a discrepancy for review, while a legal conclusion also depends on jurisdiction, roles, purpose, necessity, lawful basis, and the accuracy of the domain-to-recipient mapping.

This differs from the site’s Android permission essay, which compares device authority with store declarations. A permission says what an app may access; a privacy notice says what an operator represents; a runtime trace says what one execution transmitted. None substitutes for the other.

The App Opens With Context

Telegram describes Mini Apps as services operated by third-party providers. Its Mini App terms say a provider automatically receives the user’s IP address and, depending on launch mode and service design, may receive Telegram user ID, public name, username, profile picture, language, premium status, theme parameters, and chat context. The same terms say Telegram does not control later exchanges between the user and provider after the initial transmission.

The paper’s architecture account separates four positions that a policy can blur: the Telegram client and WebView, the developer-hosted frontend, an optional developer backend, and outside services contacted by either layer. Telegram’s current Mini App documentation also documents location and device-sensor interfaces, hardware context, and local, cloud, or secure storage. Availability is not evidence that an app used a capability, but it makes the object of governance broader than a list of HTTP destinations.

A Mini App is served from developer-controlled Web infrastructure rather than redistributed as a fixed mobile package. Its behavior can change without an app-store-style release. A notice may remain available while the code, dependencies, recipients, and launch sequence drift underneath it.

What TeleGapper Measured

The authors collected 991 tApps Center catalogue entries in the first half of June 2026. They had to draw 442 entries to obtain 278 apps that could be launched and observed: 27 bots had been deleted, 124 frontends were unreachable, and 13 lacked the required profile-level entry point. The result is therefore a sample conditional on discoverability through one community catalogue and successful launch through one path. It is not a prevalence estimate for every Mini App on Telegram.

TeleGapper retrieved the applicable default or custom policy, launched each app on a rooted Pixel 9 running Android 16 and Telegram 12.7.3, and intercepted device traffic through a TLS proxy. Its protocol repeated the workflow five times per app, clearing WebView state between runs, and took the union of contacts observed across runs. Each run separated a 20-second initialization window from up to 240 seconds of randomized exploration.

The analyzer inferred the app’s own frontend domain, excluded it and a documented set of platform/background hosts, decoded request content, and looked for specified categories including Telegram identifiers, profile metadata, authentication material, cookies, device and browser attributes, location, analytics identifiers, and wallet addresses. For custom policies, a reviewer counted a recipient as disclosed whenever the text could plausibly cover it. That conservative reading reduces some false positives, but it does not remove judgment from the classification.

The results found at least one measured mismatch in 165 of 278 apps, or 59.4 percent. Of those 165, 141 contacted an undeclared domain during opening and 104 contacted at least two across the observed runs. Device information appeared in 157 of the 165 mismatch cases; user or profile information appeared in 63. Recurring combinations of device model, Android version, WebView version, language, and Telegram version may increase fingerprinting potential, but the trace does not prove that a recipient actually constructed or reused a fingerprint. That distinction connects to the browser fingerprint as shadow identity.

Execution Precedes Choice

The sequence creates the sharpest governance problem. Telegram’s Standard Bot Privacy Policy and Mini App terms construe continued access and use as acceptance, while 141 of the 165 mismatch cases included an undeclared contact during the opening stage. Across the 278 analyzed apps, manual inspection found no observable launch-time banner, dialog, acknowledgment, or accept/refuse/configure control. The authors inspected the rendered launch surface separately from automated exploration, but they could not rule out controls on paths they did not reach.

Contractual acceptance of terms, notice, legal basis, and consent are separate questions. Where the EU General Data Protection Regulation applies, its Articles 13 and 14 require purposes, legal basis, and recipients or categories of recipients; they do not prescribe a one-domain-per-name test. Its consent definition requires a freely given, specific, informed, and unambiguous indication through a statement or clear affirmative action. Consent is not the only possible lawful basis, and the study did not determine the basis applicable to each transmission. Device storage or access can raise a further, technically distinct question under Article 5(3) of the ePrivacy Directive, whose scope the EDPB addresses in its technical guidance.

A person cannot use a post-launch explanation to prevent a request already made at launch. That is an inference about interface order, not a legal holding. A launch banner would not cure the sequence if optional traffic ran first or the recorded choice never propagated downstream. This is why the site’s consent-machine essay treats the whole signal path, rather than the button alone, as the unit of review.

A Custom Notice Is Not a Runtime Test

The sample included 219 apps governed by Telegram’s default policy and 59 with custom notices. The measured mismatch rates were 60.3 percent and 55.9 percent. Both Pearson and Fisher tests returned p=0.55. The observed difference was small, and the paper estimates only about 0.09 statistical power to detect an effect of that size; with these group sizes, roughly a 20-percentage-point difference would have been needed for 80 percent power. The result does not show that custom policies are useless, equivalent in quality, or incapable of a smaller real effect.

Telegram’s Bot Platform Developer Terms require an accessible policy describing what data an app stores, how it collects the data, and why. They assign the default policy when no custom one is registered and require a separate policy when the default does not fit the service. Telegram also states that apps violating their policies may be removed. Those are contractual requirements and stated remedies, not evidence about how consistently Telegram reviews or enforces them.

A custom notice can still be a real improvement: it can name the operator, purposes, categories, recipients, retention, rights, and contacts. But prose is not proof that declarations match live behavior. For hosted software, correspondence needs an observation step, a version binding, and re-review when code, dependencies, configuration, policy, or destinations change.

The Platform Has the Vantage Point

The paper’s discussion proposes platform-side runtime verification, recurring or change-triggered checks, restrictions on outbound origins, and liveness checks for broken apps and abandoned domains. These are design proposals, not evaluated controls. A credible governance plane would make each proposal operational:

Declare. Before launch, require the operator’s legal identity, frontend origins, service providers or recipient categories, data fields, purposes, stage of use, claimed legal basis, retention, and a hash of the applicable notice. Domain names should be mapped to responsible entities and roles; a hostname alone is not a controller, processor, or corporate recipient.

Test. Run a zero-interaction boot capture and bounded task-based exploration on supported clients. Compare observations with the declaration, preserve the classifier and excluded-host versions, and send uncertain infrastructure mappings to review rather than automatically branding the app unlawful.

Constrain. An enforceable origin allowlist or Content Security Policy can reduce undeclared browser egress. Optional launch-time requests should remain off until the relevant choice or other authorization condition is satisfied. These controls can limit client behavior; they do not establish purpose limitation, data minimization, or a lawful basis, and they do not control onward sharing from an allowed backend.

Recheck. Bind the review to content, script, configuration, policy, and recipient hashes. Re-run on material changes and periodically because hosted code can update without redistribution. Liveness and domain-ownership checks matter too: an abandoned frontend that remains linked can become a different risk from the app originally reviewed. This is the review-runtime drift problem also examined in the agent-store essay.

Remediate. A mismatch should produce a developer notice, evidence summary, correction window, and appeal. Repeated or high-risk discrepancies may justify quarantine, egress blocking, or removal, but the platform should record the rule, reviewer, notice, developer response, user-facing consequence, and restoration criteria. Platform leverage does not erase developer responsibility; it adds a duty to use platform visibility carefully.

The Evidence Boundary

The authors’ limitations narrow every conclusion. The study used one Android device, Telegram account, configuration, catalogue, and profile-launch mechanism. Randomized exploration cannot reach every authenticated, conditional, or multi-step path; five runs cannot reveal every behavior; and a June snapshot can age as hosted code changes. No mismatch detected means only that none appeared within this observation budget.

Domain classification is also an imperfect proxy for recipient identity. A cloud or content-delivery domain may support the developer’s own service, one company may operate many hostnames, and an applicable transparency rule may permit a recipient category rather than an endpoint-by-endpoint list. Conversely, excluding common platform hosts can hide app-attributable behavior. The paper used a plausibility-favoring policy rule, but only a case-specific inquiry can establish the parties’ actual roles and obligations.

By inference from the architecture and capture point, TeleGapper observes traffic leaving the test device; it cannot see a developer backend’s later server-to-server transfer after the client reaches the inferred first-party domain. A network trace also does not directly audit reads and writes through local or secure storage, sensor use that produces no captured request, backend retention, deletion, security, or downstream reuse. Platform-side measurement is broader than a user’s view, but it is not total visibility.

The released repository includes the scraper, 991-entry catalogue dataset, TeleGapper modules, proxy configuration, extractors, and excluded-host list. It omits raw traces, per-app reports, interaction logs, and manual annotations because the records contain the authors’ account data and allegations tied to named apps. That choice protects subjects and credentials, but it means outsiders can inspect and rerun the method without independently re-auditing every reported classification from the published artifacts.

Source Discipline

This page treats arXiv v1 as the fixed source for the study’s method, sample, results, limitations, and proposals; the public repository as evidence of the code and artifacts actually released; Telegram’s documentation and terms as primary evidence of the platform’s stated interfaces and contractual position; and EU legal texts and EDPB guidance as authority for narrow distinctions about transparency, consent, and terminal access. Telegram’s statement that it may remove noncompliant apps is not evidence that removal occurs consistently. The paper’s operational label is not a regulator’s finding.

Three units must remain separate. A domain is an observed technical destination. A recipient is an entity or category described in a notice. A legal determination assigns roles, applicable rules, facts, and responsibility. Mapping between them is necessary for governance, but it is not automatic.

The statistics describe 278 analyzable apps reached from one June 2026 catalogue and one launch path. Percentages are not silently generalized to all Telegram Mini Apps. The absence of public per-app evidence also limits independent verification of the aggregate classifications. Any follow-up claim should preserve the app and policy versions, sampling frame, client configuration, run budget, classifier version, reviewer judgments, and artifact availability under the site’s research-integrity standard.

The Runtime-Policy Receipt

A governed check should record the app, bot, operator, frontend, backend, content and configuration hashes; the policy URL, text hash, version, retrieval time, and declared recipient entities or categories; observed domains, fields, purposes inferred, and initialization-versus-interaction stage; the device, account state, client version, run count, paths, and exploration budget; the first-party and excluded-host rules; and any launch-time choice interface and resulting traffic difference.

The receipt should then separate four layers: observation (what bytes went where), mapping (which entity and role the destination represents), assessment (what policy or rule applies), and intervention (warn, block, quarantine, remove, or clear). Each needs confidence, reviewer, correction history, developer response, appeal status, expiry, and recheck trigger. A person reviewing the receipt should be able to disagree with a mapping without erasing the trace.

The audit can itself become a privacy and security hazard because traces may contain identifiers, profile data, authentication timestamps, signatures, or tokens. Test accounts, field minimization, redaction where compatible with analysis, encryption, access controls, short retention, and deletion verification belong in the design. This follows the site’s data-minimization and privacy stewardship commitments.

The Spiralist boundary is simple: a policy is not a charm placed over execution. It becomes evidence only when its claims can be compared with what ran, the comparison preserves what it could not see, and somebody is answerable for correcting the gap.

Sources

Return to Blog