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

The Mini App Policy Becomes the Runtime Gap

An embedded app can begin network activity as it opens, before a person has explored the service or inspected its privacy notice. At that point, disclosure is no longer only a document problem; it is a runtime correspondence problem.

A platform that supplies the execution environment can test that correspondence. The hard boundary is to report observed flows without turning a bounded measurement into a universal or legal verdict.

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. It is a black-box measurement study of sampled Mini Apps, not a court decision or a census of Telegram’s entire app ecosystem.

This is distinct from the site’s Android permission essay, which compares device authority with store declarations. TeleGapper examines whether an embedded Web app’s observed third-party data flows correspond to the privacy policy that applies to it.

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 access and service design, may receive account data such as Telegram user ID, public name, username, profile picture, language, premium status, and theme parameters. Telegram also says it does not control later exchanges between the user and provider after transmission.

The paper’s architecture account matters because a Mini App is a Web application rendered in Telegram’s WebView and hosted on developer-controlled infrastructure. There is no stable package for an outsider to decompile before use. A notice may be present, yet still fail to describe the recipients reached by the running app.

What TeleGapper Measured

The authors built TeleGapper to retrieve the applicable custom or default policy, launch a Mini App, intercept outbound traffic through a proxy, separate initialization from later interaction, and compare transmitted user data with disclosed recipients. Their method used five runs per app: a 20-second initialization window followed by up to 240 seconds of automated exploration. They analyzed 278 working apps sampled from a 991-entry tApps Center catalogue collected in June 2026.

Under the paper’s operational definition, a “violation” occurred when user data went to a third-party domain not disclosed by the applicable policy. The results found this mismatch in 165 of 278 apps, or 59.4 percent. Of those 165, 141 had an undeclared contact during opening; 104 contacted at least two undeclared recipients. These are observed disclosure mismatches under the study protocol, not findings that every request was unlawful.

Execution Precedes Choice

The sequence creates the sharpest governance problem. Telegram’s terms construe continued use as acceptance, while the study observed most mismatches in the initialization stage. Across the 278 analyzed apps, manual launch-screen inspection found no observable consent banner, dialog, or control. The paper’s discussion notes that this does not establish the absence of a valid legal basis for every processing operation.

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. At minimum, a platform should distinguish policy availability, runtime correspondence, and legal authorization. Showing a policy addresses the first question; TeleGapper tests the second; neither by itself resolves the third.

A Custom Notice Is Not a Runtime Test

The sample included 219 apps governed by Telegram’s default Standard Bot Privacy Policy and 59 with custom notices. The measured mismatch rates were 60.3 percent and 55.9 percent, respectively; the difference was not statistically significant at p=0.55. This does not prove custom policies are useless, and the smaller custom-policy group limits the power to detect small differences.

Telegram’s default policy is intentionally general and tells developers to publish a policy suited to their services and governing law. Specific prose can improve notice, but prose is not evidence that declared recipients match the live application. Correspondence needs an observation step and a recheck when the app changes.

The Platform Has the Vantage Point

The paper’s discussion proposes platform-side runtime verification, recurring or change-triggered checks for Web apps that can update without redistribution, restrictions on outbound origins, and liveness checks for broken Mini Apps. These are design proposals, not evaluated interventions.

The platform’s advantage is shared visibility: it supplies the launch surface and execution container across many apps. A useful gate could compare a versioned recipient declaration with initialization traffic before publication, flag changes, and preserve an appeal path for misclassified analytics, content-delivery, or infrastructure domains. The developer would still own the accuracy and legality of its processing.

The Evidence Boundary

The authors’ limitations narrow every conclusion. The work used one device, account, configuration, catalogue, and launch mechanism; randomized exploration cannot reach every path; five runs cannot capture every conditional flow; and the June snapshot can age as hosted code changes. Platform hosts were excluded, policy interpretation required manual judgment, and infrastructure domains can blur first- and third-party boundaries. The released scraper and catalogue dataset support follow-up work, but raw traces and per-app reports were withheld to protect account data and avoid publishing named-app allegations. Absence of a detected mismatch therefore means only that none appeared within the observation budget.

The Runtime-Policy Receipt

A governed check should record the app and bot identifiers, frontend version or content hash, policy version and retrieval time, declared recipients and data categories, observed domains and fields, initialization-versus-interaction stage, first-party classification rule, excluded hosts, device and account configuration, run count, exploration budget, consent interface observed, uncertainty, reviewer correction, appeal, retention, and recheck trigger.

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, when the comparison preserves its limits, and when somebody is responsible for fixing the gap.

Sources

Return to Blog