A Rosetta Stone for MiniApp Security: Mapping WeChat's Walled Garden onto Telegram's Web Runtime

Qualitative taxonomy comparing two super-app MiniApp architectures — not a vulnerability scanner, but the prerequisite map for building one cross-platform.

Imagine you're an electrician trained on American wiring codes who gets a job in Germany. The physics of electricity is identical, but the junction boxes are different shapes, the color codes are swapped, and the breaker panels have different labeling standards. Before you can safely inspect a German house, you need a wiring-code translation table — not because one system is safer, but because your American multimeter won't fit German outlets without an adapter. That's what this paper builds for MiniApp security analysis. The committed claim: existing WeChat security analyzers (like MiniScope, WMPChecker, and others built on WeChat's packaged .wxapkg format and proprietary JS APIs) cannot be directly ported to Telegram MiniApps, because the two platforms have fundamentally different execution architectures. WeChat runs MiniApps in a dedicated dual-thread runtime (render thread + logic thread) with its own component model. Telegram runs MiniApps as standard web pages inside an Android WebView, communicating with the host app through a JavaScript bridge. The paper's contribution is a shared taxonomy — security controls, assets, threat sources, trust boundaries — that maps equivalent concepts across the two ecosystems. The architectural comparison is the load-bearing section. WeChat's approach is a custom sandbox: MiniApps are packaged, downloaded, and executed in a proprietary runtime where the platform mediates all access to device capabilities through WeChat-specific APIs. Telegram's approach is thinner — a standard web execution context (Chromium WebView) plus a postMessage-style bridge (TelegramWebviewProxy) to the host app. Both models push backend authentication responsibility onto the developer, but the trust boundaries sit in different places. In WeChat, the platform is the gatekeeper for capability access. In Telegram, the WebView plus host-app code share that role, and the boundary is fuzzier. Two worked examples illustrate where the translation breaks down concretely. First, credential handling: WeChat issues session tokens through a platform-controlled login flow (wx.login → code → session_key), while Telegram uses initData validated by the bot's secret via HMAC. The credential roles map loosely but the validation boundaries are different entities. Second, capability access: WeChat exposes device features through named JS APIs gated by platform permission dialogs; Telegram routes capability requests through the WebView bridge, where the host app's Java/Kotlin code decides what to grant. An analyzer that hooks WeChat's permission API calls would need to hook entirely different code paths in Telegram. Integrity-wise, this is a qualitative comparison paper, not an empirical study. There are no benchmarks, no vulnerability counts, no detection rates. The authors are explicit about this — they disclaim 'ranking the ecosystems by security or claiming validated vulnerability detection.' The grounding is official documentation, prior published research (cited thoroughly), and manual analysis of a specific Telegram Android source revision (commit hash provided). This is honest scope-setting, but it means the paper is a map, not a measurement. The milestone question is where the paper's value becomes clear: the MiniApp ecosystem is growing fast (WeChat has 4M+ MiniApps, Telegram's are newer but expanding), and cross-platform security tooling doesn't exist yet. This taxonomy is the prerequisite for building it. The concrete next step would be an automated analyzer that operates on Telegram MiniApps the way MiniScope operates on WeChat's — hooking the WebView bridge, tracing capability grants, flagging misconfigurations. The paper explicitly sets up that future work without delivering it. The obvious experiment not run: actually building and validating a Telegram MiniApp analyzer using this taxonomy. The authors frame the paper as 'informing future automated analysis,' which is honest but leaves the hard engineering undone. Most likely explanation: this is a scoping/framing paper meant to precede the tool paper, which is probably in progress. The taxonomy is the prerequisite, not the product.