arXiv CSopen access

Don't Trust the Super-App: A Case Study of Russia's Max

Don’t Trust the Super-App: A Case Study of Russia’s Max Richa Priyanka 1 , Aaron Ortwein 1 , Joel Reardon 2 , Michael Specter 3 , Piyush Kumar Sharma 4 , Roya Ensafi 1

arXiv:2609.11814v1 [cs.CR] 10 Sep 2026

1 University of Michigan

2 University of Calgary

3 Georgia Institute of Technology

4 Indian Institute of Technology, Delhi

Abstract Super-apps, an emerging mobile architecture, host third-party mini-apps inside a single app, allowing users to access diverse services. A decade of security research on the super-app ecosystem has all assumed super-apps to be a trusted intermediary. We argue this implicit trust is difficult to justify: China’s WeChat is already shown to passively track its user’s activity across mini-apps at extraordinary scale; Russia’s MAX’s parent company is reported to be deeply entangled with the state prosecution of online speech; and Iran’s Bale was reported to be functioning in the world’s longest internet shutdown due to its state-backed support. In this paper, we show how malicious super-apps have undeniable capabilities to silently undermine the security and privacy of mini-apps and users without leaving any trace. Using MAX as an example, we show how it can capture miniapp UI, read and write mini-app local storage, inject arbitrary JavaScript into a mini-app’s runtime, mediate mini-app network traffic, and control authentication context in ways that can enable silent user impersonation. Sadly, these capabilities manifest themselves in any super-app because of the architectural privileges granted to them by design. We argue that mobile OS and app store interventions are urgently needed to close this architectural blind spot before it is further exploited.

1

Figure 1: Super-app Position in Android. Android treats super-apps like normal apps, despite their privileged visibility into and control over hosted mini-apps. ties, and fixes with the goal of improving the super-app itself [31, 53, 55, 64]. While extremely valuable, prior work largely accepts the super-app as an OS layer atop the mobile OS, and assumes it can be trusted to act in the best interests of mini-app developers and users. Treating super-apps as trusted intermediaries is dangerous as it ignores the global reality where information control is not just a feature of authoritarian regimes, but also a growing part of digital governance. In the West, the United Kingdom, Canada, and Sweden have recently pursued legislative measures that would, in practice, weaken or bypass end-to-end encryption on major platforms [19, 22, 25, 45, 46, 62]. Where platforms already operate under strong government pressure, a super-app can be an unusually efficient instrument for surveillance and censorship. Notably, Wang et al. demonstrated that WeChat passively tracks user activity across its mini-app ecosystem at extraordinary scale [55], and reports from Iran (Bale), Vietnam (Zalo), and India (Paytm) document parallel trajectories in which government-aligned platforms have become deeply embedded in everyday communication and commerce [17,38,40,50]. These trends make the implicit trust placed in super-apps increasingly difficult to justify, yet no prior work has systematically examined what happens when that trust is actively violated by the super-app itself. Under government pressure, how can a super-app actively undermine the security of its users and mini-apps? Without a user’s knowledge, can it interfere with their mini-app activities in real time? Without

Introduction

Super-apps, as popularized by WeChat, are an emerging mobile architecture in which a host app embeds third-party miniapps, delivering diverse services and functionality within a single unified app [52]. Security researchers have scrutinized this model, demonstrating that current super-apps cannot consistently isolate mini-apps, enforce least-privilege access to sensitive resources, prevent cross-platform exploits, or contain data exposure at scale [31, 53–55, 63–68]. They also collaborated directly with super-app developers through responsible disclosure, resulting in vendor patches, bug boun1

Figure 2: Launch Timeline of Selected Super-apps. Sources: WeChat [27], Zalo [50], Baidu [13, 28], DingTalk [2, 21], Paytm [38, 44], BiP [51], M-Pesa [39], Absher [24], Bale [40], Rubika [40], and MAX [9]. a mini-app’s knowledge, can it forge connections on behalf of its users? And, most importantly, does the super-app hand authorities the client-side backdoor they have long sought to obtain through conventional legislative action?

Playing the role of an active adversary, we found five distinct capabilities that allow MAX to act as a man-in-themiddle for all mini-app interactions: (1) MAX can capture screenshots of mini-app content without holding any special system permissions, and without alerting the user; (2) It holds full read and write access to all mini-app local storage, meaning no data a mini-app persists on-device is private from MAX; (3) It injects JavaScript into running mini-apps, enabling silent, undetectable modification of mini-app functions at run-time; (4) It mediates all mini-app network traffic, and in the Russian regional build specifically, routes this traffic through a GOST TLS proxy, raising acute concerns about state-level interception [18]; (5) Finally, it controls the authentication tokens and session context supplied to each mini-app, granting it the ability to silently impersonate any user to any service hosted within the super-app ecosystem. These findings uncover that MAX’s super-app architecture can actively and silently undermine the security guarantees that users assume when interacting with each mini-app.

In this paper, we aim to show how a malicious super-app can abuse its privileged position to design active attacks that undermine the confidentiality, integrity, and availability of information. Specifically, we illustrate this threat through an in-depth analysis of MAX, Russia’s state-backed super-app that has been coercively forced on Russian citizens since March 2025. MAX is developed by VK whose flagship social network, VKontakte, is deeply entangled with the state prosecution of online speech. Journalists have documented that over a fourteen-year period, VK was involved in nearly 46% of criminal cases related to social media posts in Russia and is now sanctioned by the European Union over abusive surveillance [10,14,15]. Worse, MAX is no longer optional in Russia, as it has become the sole gateway to access essential public services like school, payments, and digital identity. We focus on MAX not just because of the above reasons, but also because Russia’s rapid descent towards digital authoritarianism showcases a blueprint any government can follow, making MAX both the most urgent and the most exportable case for studying the super-app architecture.

Unfortunately, as we show in Section 5, these capabilities do not require exploitation of a vulnerability but are a consequence of the architectural privileges granted to super-apps by design. Consequently, these capabilities are not specific to MAX but are inherent to any implementation of the super-app architecture. Android’s security model treats the super-app and all its mini-apps as a single, unified trust principal, providing no mechanism to constrain, audit, or observe the super-app exercising these capabilities. The consequence is that hundreds of millions of users interact with what appear to be independent, sand-boxed services, while in reality operating entirely within a single app.

However, conducting such an investigation is not straightforward as MAX employs several mechanisms that impede systematic analysis. MAX offers a different APK in Russia (pre-installed on Russian phones) compared to what is available via the Google Play Store, and a large set of mini-apps only function in Russian networks. We found MAX performs location detection by cross-referencing VPN API signals, SIM card metadata, GPS coordinates, and other device identifiers, making it difficult to execute the app in a controlled analysis environment without triggering detection. Moreover, instead of transmitting data in standardized formats such as JSON or XML, MAX employs a custom RPC protocol for its network communication. Therefore even after the traffic is decrypted, standard parsing techniques fail to yield intelligible output, necessitating a full reverse-engineering effort. To overcome these challenges, we designed and implemented a custom end-to-end analysis pipeline to instrument the app, capture all events, and reconstruct MAX’s runtime behavior from a Russian proxy and a local US network.

Any progress on advancing super-app security has to first take into account that super-apps are an active threat. We therefore propose recommendations aimed for the mobile OS and app store in Section 6. In the near term, the OS should provide users controls to revoke network access and background execution. In the longer term, OS constraints should be developed to enable better accountability, so super-app capabilities match the security and privacy assumptions of mini-apps and users. To this end, we recommend adding user-facing transparency mechanisms, auditability over super-app to mini-app communication, and architectural isolation, so that mini-apps can establish trust independently of the super-app. 2

Figure 3: Daily Google Play Store Installs for the MAX Super-app (June 2025–June 2026).

2

Background

that provides minimal safeguards for electronic data [17, 38]. Because super-apps concentrate payments, communication, government services, and large facets of daily life, disabling a user’s account becomes a way to enforce partial expulsion from society, as seen from the effects of Tencent blocking WeChat accounts in 2022 [61]. MAX makes this concern more pressing. Launched by VK in March 2025, MAX messenger was positioned to absorb functions that extend beyond private communication to include payments, school and government services [9]. Figure 3 shows that MAX’s adoption rose in distinct waves that align with Russia’s disruption of competing messengers. The first major surge occurs in mid-August 2025, when the 7day rolling mean rises to roughly 823,000 installs per day. This coincides with Roskomnadzor, Russia’s communication agency, restricting voice and video calls on WhatsApp and Telegram, after which MAX briefly became the top-ranked app in Russia [26, 34]. Around this time, all school chats also started being transferred to MAX [33]. A second smaller wave appeared in late November and early December 2025, when the rolling mean reached roughly 480,000 installs per day. This followed the widespread Telegram disruptions and widening restrictions on foreign communication apps like FaceTime [37]. The largest spike appears in late March 2026, when daily installs peaked near 2.9 million amid major Telegram outages and reports of state employees, and public institutions being pushed onto MAX [20, 35, 47]. Together, this pattern shows how MAX’s growth has been influenced by a sequence of events where the Russian government degraded services for all competitive messengers while promoting a preferred domestic super-app. These developments have also prompted substantial scrutiny of MAX among independent security researchers and digital-rights groups. Since its launch, researchers have inspected MAX’s Android permissions and compared them with other messengers, examined its APK and embedded thirdparty libraries, and performed network measurements to characterize the services and endpoints it contacts [7, 8, 12, 23]. Other community-led analyses have examined telemetry and environment-detection logic exposed through static reverse

Super-apps are mobile applications in which a single native app provides the runtime environment, permission mediation layer, and distribution channel for third-party services, commonly called mini-apps. Super-apps allow users to conveniently access diverse services through one app, often with a shared account. This model has been adopted widely by WeChat, Alipay, Telegram, TikTok, and others [29, 30, 48, 67] The proliferation of this architecture reflects convergent incentives for both the super-app providers and mini-app developers. Mini-apps can be developed with standard web technologies (HTML, JavaScript, CSS), distributed instantly to the super-app’s existing user base without per-release app store review, and gain access to native device capabilities such as cameras, contacts, and location through the super-app’s bridge APIs. These mini-apps also increase user engagement and retention on the super-apps. A user who pays bills, messages with friends, and books transit on the same app is less likely to abandon the app than one using standalone apps for each service. The super-app can also profit from mini-apps by charging fees to all payment transactions that occur through the super-app’s payment infrastructure. Finally, daily use of the super-app also sustains its privileges because keeping it in foreground preserves permissions Android would otherwise restrict to foreground-only or auto-revoke after disuse. The same consolidation that makes super-apps commercially successful also makes them appealing to authorities. This is why state-aligned super-app models are emerging in different countries (Figure 2). In Iran, government-backed apps such as Rubika and Bale reportedly lack meaningful endto-end encryption, and route user-clicked URLs through backend servers for monitoring [40]. In Vietnam, Zalo serves 79 million monthly users under expanded data collection terms, legally bound to comply with government data requests under the Cyber Security Law [50]. Similarly, in India, Paytm was reported to have shared user data from the geopolitically sensitive Jammu and Kashmir region with the Prime Minister’s office, operating under a legacy legal framework 3

provided by the platform OS (Android’s WebView, iOS’s WKWebView) that lets native components render and execute web content within their process [5]. The host instantiates and configures the WebView, making it the execution sandbox for all hosted mini-apps. Mini-apps do not require any OS level installation and can be discovered and launched from the host’s marketplace. The host app manages the fetching, caching and entire lifecycle of the mini-app. The mini-app also does not have its own application package, UID, or a dedicated storage directory [32]. It operates entirely within the host’s OS-level identity and sandbox. Access to native device capabilities like camera, contacts, location, storage, is mediated by the host through its bridge layer rather than granted by the OS. Figure 4: Super-app Architecture. Mini-apps call a shared JavaScript API Layer, which crosses a JavaScript Bridge to the Native Layer for permission checks and access to OS-level system resources.

The JavaScript Bridge The JavaScript bridge is the central architectural element of the super-app model. It defines the API surface available to mini-apps and mediates all interaction between web-based mini-app code and native device capabilities. It is the mechanism by which mini-app code running in a WebView invokes native capabilities provided by the host. Since the WebView executes standard web content, it has no direct access to device hardware or OS services. The bridge provides this access by exposing host-implemented methods to the mini-app’s JavaScript context. On Android, the host application makes calls to addJavascriptInterface() to bind a Java object into the WebView, making its methods callable from JavaScript. A mini-app invokes these methods to access native functionality like reading from device storage or requesting a contact, and the host executes the corresponding native operation. This bridge is bidirectional: in the reverse direction, the host can call evaluateJavascript() to execute arbitrary JavaScript within the mini-app’s WebView context. This allows the host to inject scripts, modify page behavior, or invoke callbacks.

engineering, while RKS Global conducted controlled tests of MAX’s access to sensitive device resources and later analyzed its VPN-detection behavior [1, 42, 43]. These independent investigations reflect the considerable suspicion surrounding MAX’s rapid expansion and have helped document aspects of its permissions, bundled components, and observable network and application behavior.

2.1

Super-app Architecture

Beyond the standard components of a mobile application, a super-app introduces three architectural elements that are central to its operation: the host application, the mini-app layer, and the JavaScript bridge (Figure 4). The Host Application The host application is a native mobile app that is installed from a platform app store (Google Play, Apple App Store, RUStore, Huawei App Gallery, etc.). It provides a WebView-based execution environment for the mini-apps it hosts, a JavaScript bridge layer exposing native capabilities, a lifecycle manager, a mini-app marketplace and launcher, and a permission mediation layer governing mini-app access to device resources. In addition to managing the runtime, the host typically provides shared platform services like authentication, payment processing, and push notifications that multiple mini-app developers can invoke through encapsulated APIs. This abstraction is a key part of the model’s appeal: a mini-app developer calls a single bridge method (e.g. requestPayment()) rather than integrating with platform specific SDKs, substantially reducing development effort and time to deployment.

2.2

Prior Work

A growing body of security and privacy research has substantially advanced our understanding of super-apps. At the ecosystem level, measurement work has characterized the scale and structure of these apps, showing how large mini-app marketplaces have grown and how much functionality superapps expose to third-party developers [67]. This shows the breadth of the attack surface a single super-app inherits when it mediates millions of mini-apps. A second line of work has shown that this architecture is difficult to secure. Studies have demonstrated identity confusion, hidden or undocumented APIs, permission bypasses, unauthorized access to sensitive resources, privilege escalation, and UI deception attacks, each reproduced across billion-user apps [31, 54, 63, 64]. Cross-platform analyses further show that the same super-app can expose different security properties across mobile and desktop clients, leading to several possible exploits [53, 68]. More recently, malware studies

The Mini-app Layer Mini-apps are light-weight applications that execute within the host’s runtime environment. Unlike native mobile applications, mini-apps are built with web-based technologies (HTML, CSS, JavaScript). They are rendered inside a WebView, which is a browser component 4

have examined the supply side of these ecosystems, showing that malicious mini-apps can evade super-app vetting and affect users at scale [60]. Finally, Wang et al. analyze superapp design through the lens of browser security, focusing primarily on isolation among mini-apps within a shared host runtime [56]. Closest to our work is a growing line of privacy research that turns from malicious mini-apps to the privileged position of the super-app host itself. These studies show that miniapp ecosystems enable leaked secrets and systematic privacy over-collection [65, 66]. Recent work on first-party tracking in WeChat and inference attacks over mini-app interaction histories shows that the super-app can passively observe user behavior across all its mini-apps [6, 55]. Our work builds on existing academic research on superapps, but adopts a different threat model. Prior work largely treats the super-app as a flawed but trustworthy intermediary between the mini-apps and the OS. In that model, the adversary is typically a malicious mini-app, an external attacker, or a bug to be patched. Even the work that explores a superapp collecting a wide array of private data, studies them as a passive observer [55]. In this paper, we aim to ask what happens when the host itself becomes adversarial. Rather than asking only what the host can observe, we study whether it can actively act as a man-in-the-middle for all mini-app interactions in real-time without any safeguards.

3

the universal build). After static analysis, we learned that these APKs were mostly similar, except for the cryptographic layer. In our initial testing, the universal build operated without any obvious issues or connection restrictions. In contrast, the Russian build, once launched, remained indefinitely stuck at the login screen. On further investigation, we found that the backend servers (api-gost.oneme.ru on ports 443 and 8443, serving authentication, configuration, messaging, and media channels) were unreachable from non-Russian IPs. We confirmed this by observing that direct connections from our measurement machine were timing out. Without a Russian vantage point, the app only loaded a login screen but did not allow us to authenticate, rendering it unusable. The Russian build restricts access through location checks, including client IP, device location, VPN interfaces, timezone, and SIM/network identifiers. Hence, we carefully designed an egress tunnel to an endpoint in Russia that operated outside of Android’s VPN feature. MAX queries NetworkCapabiliti es.hasTransport(TRANSPORT_VPN) during session setup, and so we used iptables NAT REDIRECT to transparently route MAX’s traffic through our proxy. In all subsequent captures from this build, MAX’s VPN probe returned false. To address other signals that reveal our real location, we configured the device timezone to Europe/Moscow, locale to ru_RU, and emptied the SIM slot. We also cleared the data directory for MAX to avoid any persistent identifiers that could link sessions. After these steps MAX loaded successfully. Finally, activating an account on MAX requires SMS verification. Earlier versions of MAX (until 25.14) restricted this registration to Russian phone numbers, which made account creation impractical for our test environment because new Russian SIMs require identity verification [49]. We registered test accounts and began dynamic testing after version 25.15 (released November 2025), which expanded registration to the Commonwealth of Independent States.

Methodology

In this section, we present our setup and the detailed methodology for analyzing the MAX super-app. Figure 5 shows our high-level analysis pipeline for setting up a test environment, executing the MAX app, collecting raw data, processing it, and then performing systematic analysis. We now explain in detail each part of our analysis.

3.2

Threat Model Our adversary is a super-app host, that either because of malicious intent or under coercion, wants to abuse its privileged position. The adversary’s goal is to compromise the confidentiality, integrity, and availability of mini-app interactions. We explore the capabilities that this adversary has by design. We assume that the mini-apps installed on this super-app are benign, and want to provide legitimate services to their users via the super-app. The victim uses the super-app normally and has at least one mini-app installed.

3.1

Instrumentation

The challenge in instrumenting a super-app is that the app mediates mini-app activity across multiple layers including TLS-encrypted RPC to its own backend, JavaScript bridge calls between the super-app and mini-apps, callbacks that fire from the mini-app’s WebViews, and Android system APIs that access sensitive resources. To get a complete picture of the app’s runtime behavior, we designed a unified capture script that attaches to the running MAX process via Frida and arms hooks across four functional layers. These hooks emit logs prefixed with a tag to indicate the type of event logged. At start-up, the script detects the app build by probing for ru.CryptoPro.ssl.SSLSocketImpl. If this class is present, the script enables the Russia-specific GOST TLS hooks. Otherwise, it falls back to BoringSSL hooks. The implementation had to address two sources of brittleness. First, arming 80+ hooks simultaneously destabilizes

Test Environment

Our test environment consists of OnePlus mobile devices, rooted and configured with appropriate instrumentation for analysis (Section 3.2). We obtain the MAX APK through two channels: our Russian collaborators (henceforth called the Russian build) and the Google Play Store (henceforth called 5

Figure 5: Measurement Pipeline. In stage 1, we instrument MAX on an Android device with Frida and tunnel its traffic to a controlled vantage point while collecting plaintext logs. In stage 2, we decode binary RPC messages, and stitch network and bridge events together. In stage 3, we store the synthesized results like WebView events and network flows into a SQLite database for further analysis. Android’s just-in-time (JIT) compiler. The process sometimes crashes during garbage collection because Frida’s runtime patching can leave invalid metadata for JIT-compiled frames. To avoid this, we disable optimized execution for boot-image methods at script startup, forcing them through the interpreter. This trades some performance for more reliable instrumentation. Second, MAX’s R8/ProGuard obfuscation changes short class and method names across releases, so hooks tied to obfuscated symbols fail on update. Rather than bind hooks only to obfuscated symbols, we identify targets using stable string-constant fingerprints in decompiled smali, such as locating the bridge dispatcher by the method body containing WebAppDeviceStorage* constants. We then maintain a perversion symbol table, with class enumeration as a fallback when these symbols change.

capable certificate chain. Hooking MAX’s own TLS API surface is therefore the only practical way to observe Russian build’s plaintext. The universal build follows Android’s conventional Conscrypt/BoringSSL path. There, we hook native SSL_read and SSL_write in the device’s libssl.so, capturing plaintext below the Java SSLSocket abstraction and immediately after Conscrypt’s JNI bridge. To join each decrypted payload with endpoint metadata, we add companion hooks on connect and getpeername and reconstruct the mapping from SSL session to socket and remote peer. Bridge Surface Enumeration In our capture script, we hook WebView functions addJavascriptInterface and removeJavascriptInterface to detect JavaScript bridge registration and teardown. When a bridge is registered, the hook reflects over the Java object and enumerates all methods annotated with @android.webkit.JavascriptInterface. Each registration emits a bridge enumeration log with the interface name, the associated obfuscated class, full signatures of JavaScript-callable methods, and exposed-method counts. This gives us the full bridge surface as the app declares it, including any methods we would have missed during static analysis alone. To capture mini-app to MAX calls, we hook the bridge method postEvent on each registered bridge class. We also hook MAX’s internal dispatcher which receives every postEvent invocation regardless of which bridge class it entered through. Each dispatch emits a bridge dispatch log containing the verb (named operation strings routing to a specific plugin handler), JSON payload, originating WebView URL, public bridge flag, and any application-level correlation identifier such as requestId or queryId. To capture MAX to mini-app events, we hook the WebView function evaluateJavascript, which is used by MAX to inject code into the mini-app context. This records bridge responses, including host-injected WebApp.sendEvent calls, as well as host-installed code such as the navigator.share polyfill and FCP telemetry probes. Each injection emits a

Plaintext TLS Capture MAX’s primary communication channel is a persistent TLS connection carrying a custom binary RPC protocol. We attach hooks to MAX’s TLS read/write routines, at the point where plaintext enters or leaves the cryptographic stack. This captures inbound payloads after decryption and outbound payloads before encryption. Since the two regional builds use different TLS stacks, the plaintext capture is build-specific. In the Russian build, MAX uses CryptoPro’s pure-Java implementation of GOST TLS, which uses Russia’s own national cryptographic algorithms and certificate authorities [18]. We hook SSLSocketImpl.read and write, which sit at the terminal I/O boundary of the CryptoPro stream. At this point, inbound bytes have already been decrypted after GOST cipher processing, and outbound bytes have not yet been encrypted. Since CryptoPro’s abstraction hides which server each TLS session connects to, we hook the socket-creation path to recover this mapping. This design is necessary because the Russian build’s GOST TLS stack is incompatible with standard interception tooling like mitmproxy, Burp Suite, and Wireshark’s SSLKEYLOGFILE workflow, which do not natively support the required GOST cipher suites. Additionally, a proxy-based approach would also require a trusted GOST6

3.3

JS injection log with the injected source and target URL. This also gives us redundant coverage of the bridge. Across all sessions, every per-bridge postEvent record matches a dispatcher record with the same payload, and every dispatcher record has a corresponding bridge-entry record.

App Execution & Data Collection

Each measurement session consisted of a single Fridaattached run of MAX. We connected the device to the lab laptop over USB, launched MAX, attached our instrumentation script, and then used the app normally while the script captured both the foreground and background activity from the MAX process. Each session produced a plaintext capture file containing event logs and session metadata such as app version, timestamp, test location, and network configuration. Within a given session, we searched for mini-apps from inside MAX, opened the corresponding chatbot, launched the mini-app through its visible “Open App” icon, interacted with it, and then closed it before moving to the next one. For each mini-app, we performed a set of standardized interactions: opening the bot chat, launching the mini-app WebView, waiting for the page to load, and exploring the primary user-visible flows available without external identity verification. Where supported, we performed browsing, search, form-entry, and navigation actions for each mini-app. While we interacted with the mini-app, the Frida script captured MAX activity across layers, including sensitive API access, JavaScript injections into mini-app contexts, WebView navigation and lifecycle callbacks, bridge dispatches, and network traffic. In each session we interacted with around 8–10 mini-apps. This kept individual logs small enough for downstream parsing and manual validation while still allowing us to observe multiple mini-app launches with the same device, account, build, and network conditions. Unlike other well-known superapps, MAX has no documented public catalog of available mini-apps. Therefore, we iteratively searched mini-apps on the MAX app manually. Altogether, we exercised 90 miniapps, spanning healthcare, government services, banking and finance, telecom, commerce, education, and tourism (refer to Table 4 in Appendix for the full list of mini-apps we tested).

WebView Lifecycle We hook MAX’s WebView callback surface to observe how it mediates mini-app navigation, resource loading, trust decisions, and browser UI. We capture shouldInterceptRequest on resource requests from mini-apps, logging the URL, method, and headers with rate limiting to avoid excessive output. We capture shouldOverrideUrlLoading on page navigations, and onPageStated/onPageFinished to mark page-loads. For error and certificate handling, we hook onReceivedHttpError, onReceivedError, onReceivedSslError, and onReceivedClientCertRequest, recording HTTP failures, network errors, TLS validation failures and host responses, and mutual-authentication challenges. We also capture MAX’s mediation of browser features exposed to mini-apps. When a mini-app tries to open a popup window, MAX intercepts the request and redirects it to the system browser. We hook this interception point to log where popups are sent. Hooks on onJsAlert, onJsConfirm, and onJsPrompt record JavaScript dialogs. Hooks on onShowFileChooser record mini-app file-upload requests, including accepted MIME types, capture flags, and selection mode. The mini-app WebView’s console output is captured through onConsoleMessage. Finally, we instrument WebView storage access from MAX’s side. CookieManager hooks capture Javaintiated cookie reads, writes, removals, and flushes, while WebStorage hooks capture attempts to enumerate, query, or delete origin-scoped DOM storage. To catch direct access that bypasses these APIs, we also hook FileInputStream, FileOutputStream, and RandomAccessFile constructors and filter for paths under app_webview in MAX’s data directory, including cookies, IndexedDB, local storage and service worker state. The same file-output hooks emit logs for likely download destinations, allowing us to trace whether WebAppDownloadFile writes bytes into MAX’s private storage or user-visible download paths.

3.4

Decoding and Correlation

This section describes the steps we take to convert the raw text logs captured during data collection stage into structured, cross-referenced events suitable for analysis. Binary RPC Protocol Instead of using HTTP for the API traffic, MAX maintains a persistent TLS connection (api-gost.oneme.ru in the Russian build, api.max.ru in the universal build) and exchanges data using a custom binary RPC protocol. This is a purpose-built binary wire format that standard MITM proxies cannot parse without custom protocol dissectors. We reverse-engineered the protocol and discovered that each message consists of a 10-byte header followed by a MessagePack-encoded body (see Table 1 for details).

Sensitive APIs To document MAX’s access to privacysensitive Android resources, we hook system APIs across several categories: clipboard access, contact lookups, telephony and carrier metadata, location access, camera and microphone use, network-state and VPN-detection checks, package enumeration, and file I/O. For each observed access, the script records the API category, method invoked, arguments, return value, and a truncated stack trace.

TLS Session Correlation Our capture script emits each TLS read/write event as a structured triplet. [EVT] records metadata such as TLS/SSL session ID, sequence number, direction, byte count, peer/local addresses, and stream class. 7

Offset

Field

Description

0 1 2 4

magic direction request_id opcode

6

flags

7 10

body_length body

Always 0x0a (protocol version 10). 0x00 request, 0x01 response. 2-byte big-endian ID to match responses to requests. 2-byte big-endian RPC method identifier, e.g., 0x0001 heartbeat, 0x0013 init-sync, 0x0023 contacts presence, 0x0080 send-message. 0: MessagePack body; non-zero: 2-byte vendor prefix precedes MessagePack. 3-byte big-endian payload length, excluding the header. MessagePack payload; if flags ̸= 0, MessagePack starts after the 2-byte vendor prefix.

tacted, which RPC methods were invoked, which identifiers appeared in which flows, which Android APIs were accessed, and what WebView activity occurred around the same time. This is what allows us to make claims about data flows, identifier persistence, sensitive-resource access, and regional/build differences rather than relying on isolated log excerpts.

4

We now discuss MAX’s potential capabilities based on our analysis database that contains a cross-session view of MAX’s behaviors. Each subsection focuses in detail on an architectural capability and the security threat it enables. We first outline the default Android architecture that supports the underlying capability. Then we zoom into MAX’s specific implementation and show how the security threat can be exploited. As discussed in Section 3.2, MAX ships two concurrent builds that are mostly identical but differ at the cryptographic layer. Both builds implement the same RPC protocol and miniapp mediation design, including the bridge API, JavaScript injection path, storage and network mediation. Since superapp security issues stem from this common design, we present our results from the Russian build only for simplicity.

Table 1: Max Binary RPC Frame Header Layout. [DATA] carries the base64-encoded plaintext payload, prefixed with a 16-byte fingerprint for fast filtering. [PROBE] provides an ASCII preview for quick inspection before offline parsing. The analysis pipeline joins these records by (ssl_id, seq, dir) and decodes the binary RPC envelope from the captured payload. In practice, this layer captures MAX’s TLS traffic to its API endpoints, along with other host-originated encrypted flows such as TracerSDK crash telemetry, VK analytics pings, and CDN fetches. By design, we are not aiming to directly hook in to the WebView process to observe the raw mini-app traffic directly, since that is something MAX would not be able to do either.

4.1

Bridge Request–Response Pairing The bridge protocol does not explicitly indicate whether a WebApp.sendEvent() call is responding to a mini-app request or delivering an event initiated by MAX. Both are delivered through the same evaluateJavascript path, so request responses and hostinitiated events appear structurally similar in the trace. To distinguish them, our decoder pairs bridge dispatch requests with JS injected responses using application-level identifiers such as requestId, and emits bridge pair records with roundtrip latency. Unmatched injections are retained as standalone host-to-mini-app events for later analysis.

3.5

Results

Control Over Mini-app UI

In Android, the mini-app WebView is a View embedded into the super-app view surface and its rendered output is ultimately presented inside a window owned by the super-app process. Although the WebView executes in an isolated process, this does not make the UI opaque to the super-app because it still owns the View and receives the final visual output. Given this architectural capability, we ask if MAX can take a screenshot of its mini-app UIs. To check, we tried two screen capture paths from within MAX’s process using Frida. First, we tested Canvas-based capture by invoking View.draw(Canvas) on the mini-app UI from within MAX’s process [3]. This method was not consistently reliable, and it only captured screenshots 73% of the times due to limitations of software View for hardware-accelerated WebViews [57]. The second capture path uses Android’s PixelCopy API to copy the pixels currently displayed in the host’s window into an image buffer created by the host’s code. It copies from the most recently queued buffer in the Window or Surface behind the displayed UI [4]. Even when the WebView isolates web content in a separate renderer process, the GPU services that produce the final pixel output still run inside the host app’s process. Thus, renderer-process isolation does not make the rendered pixels opaque to the super-app host. During our experiments, we found that PixelCopy was more robust to hardware-accelerated rendering state. It returned mini-app UI in 31 of 35 attempts, for an 88.5% success rate. Crucially, in cases where View.draw(Canvas) returned a blank Bitmap, PixelCopy retrieved valid rendered content,

Analysis

Finally, in the analysis stage, we ingest the decoded and stitched events from the previous stage (Section 3.4) into a SQLite database with tables to group similar events together for easier analysis. Events table contains all events logged. Network flows contain network events materialized from decoded and stitched TLS events. Identity Sightings keep track of authentication related parameters captured across all events, like user ID, API keys, etc. WebView Events keeps track of WebView callbacks across all mini-apps exercised during instrumentation. Every time the analysis script parses a new plaintext capture file, it also stores important context flags for account, region, device, app version, and build. This database turns raw hook output into a cross-session view of MAX’s behavior. It lets us connect events that are otherwise scattered across logs: which endpoints were con8

Figure 6: Mini-app Screenshot Taken as MAX. Screenshots taken by invoking Android’s screenshot API from within MAX, showing a mini-app login form.

Figure 7: DeviceStorage Round-trip. Ak Bars Bank miniapp persisting a push token via MAX’s bridge. MAX receives the token in clear text, persists it, and confirms to the mini-app.

indicating that the displayed surface buffer was available even when the View-level Canvas path failed. Notably, the UI capture provides information that no other channel can decisively reveal. For example, text entered in a form before submission, auto-complete drop-down selections, and any UI state that exists only in the WebView’s visual output. Figure 6 shows test credentials entered into a mini-app login form, captured by our instrumentation mid-keystroke. Repeatedly capturing screenshots when a user is typing their password will reveal the value even when this field is masked. Similarly, during our tests, we were able to successfully capture frames that showed search queries as they are being typed, previous booking history, and SSO provider selection options—all pre-submission and visible only in the renderer’s visual output. At this moment, we did not find evidence that MAX itself invokes these UI-capture paths during normal mini-app use. However, the architecture leaves the mini-app UIs exposed to MAX by default, and if MAX activates this UI capture users and mini-apps would not find out.

Direct Storage MAX owns the private directory in which its WebView-based mini-apps store their cookies and originscoped state such as localStorage, sessionStorage, and IndexedDB. This means that the super-app MAX can access all mini-apps’ local storage because it is part of its own. There is no Android security barrier that will prevent MAX from accessing or modifying mini-app local storage. Bridge-mediated Storage MAX does not technically require mini-apps to use the bridge for client-side storage. It enables DOM storage through setDomStorageEnabled(true) in WebAppRootScreen, so mini-apps could store data directly in localStorage or using Web Storage APIs. The bridge-mediated storage follows a consistent request–response pattern through the WebViewHandler bridge. First, the mini-app invokes postEvent with a plaintext JSON payload containing the key name and a requestId. Next, MAX’s dispatcher receives the request, performs the storage operation on the mini-app’s behalf, and constructs a response. Finally, MAX injects the result back into the mini-app via evaluateJavascript invoking WebApp.sendEvent with either the stored value or a structured error. We found two bridge storage variants implemented: 1. Device Storage. Figure 7 illustrates a typical DeviceStorage round-trip by zooming into the flow of Ak Bars Bank mini-app (online.akbars.ru) persisting a device push token through MAX’s bridge. The banking mini-app’s 38-byte push token passes through the bridge in plaintext where it persists the value in local storage, and confirms back. Four seconds later, when the mini-app transitions to a new page, a second GetKey for the same token succeeds, completing the mediation cycle. As we can see, every byte of this token is visible to MAX as it brokers the operation. 2. Secure Storage The federal school portal (school-ap p.gosuslugi.ru) shows how SecureStorage works in practice (Figure 8). During Unified System of Identification and Authentication (ESIA) login, the mini-app stores a session key siMAX through MAX’s bridge. Although the final on-disk

▶ Takeaway: A malicious super-app has a reliable, readily exercisable path to capture mini-app UI, including transient user-visible state.

4.2

Access to Mini-app Local Storage

In Android, WebView persists its state inside the super-app’s private data directory, including cookies, localStorage, sessionStorage, and IndexedDB. The super-app controls the WebView container and can interact with it through WebView management APIs like CookieManager and WebStorage. Given this architectural capability, we ask how MAX can access and modify mini-app local storage and whether there are any security barriers. In MAX implementation, when a mini-app wants to persist any data it uses one of these two mechanisms: (1) direct storage, and (2) bridge-mediated storage, where the mini-app can request MAX to store things in its DeviceStorage or SecureStorage. 9

Figure 9: JavaScript Injection. MAX injects three categories of JavaScript into the mini-app’s WebView via evaluateJavascript: an API polyfill that reroutes filesharing through MAX, a performance probe that reports page load timing back to MAX, and bridge responses.

Figure 8: SecureStorage Round-trip. The government school portal persisting a post-ESIA session identifier (siMAX and its UUID value) through MAX’s bridge. MAX receives the value, encrypts and stores it into Android’s secure storage, and confirms back to the mini-app.

two JS bridges expose three callable methods: postEvent and resolveShare on WebViewHandler, and trackFcp on AndroidPerf. These are the only entry points through which mini-app JavaScript can reach the super-app’s Java process. Both of these bridges are torn down on mini-app exit via removeJavascriptInterface. In the super-app to mini-app direction, the surface is unbounded. This means, evaluateJavascript can execute MAX’s code in the miniapp’s context, with no restriction on content, timing, or frequency. During our experiments, we observed MAX use this capability for three purposes.

value is protected using Android Keystore-backed encryption, the ESIA session key first crosses the host bridge in plaintext, where MAX observes it before encrypting and persisting it. The pattern is consistent across sectors. The federal culture portal stores a device UUID, an API key, and a geocoder API key through DeviceStorage, and stores a per-user auth flag and a 908-byte telemetry batch through SecureStorage. Nine healthcare mini-apps request the user’s MAX authentication token through DeviceStorage. In every read and write, regardless of storage variant, the value transits through MAX in plaintext. Despite the fact that a mini-app can persist data directly, every mini-app we tested used MAX’s bridge API for persistence rather than the private DOM storage. This turns MAX into a plaintext storage broker that sees every key–value pair mini-apps store, retrieve, or delete.

API Polyfilling Mini-apps call the Web Share API, navigator.share, to allow users to share documents, images, tickets, links, or other mini-app content through Android’s native sharing interface. Since Android WebView does not provide this API, we observed that MAX injects a compatibility polyfill into hosted mini-app pages. Unfortunately, this replacement is invisible to the mini-app because the standard API signature is preserved by the polyfill. When a mini-app shares a file using this method, the polyfill reads the file content and routes it through the bridge. MAX receives the full file bytes inline before any sharing occurs. Files exceeding 3 MiB are silently dropped with no error callback. MAX arms the Web Share polyfill on every pageload, but we did not observe the function being invoked by any mini-apps during our captures.

▶ Takeaway: A malicious super-app has several ways to read and write any information that a mini-app wants to persist on device.

4.3

JavaScript Injection Into Mini-app

In Android, evaluateJavascript exposes a direct codeinjection channel from the super-app into a mini-app’s currently loaded page. The API evaluates JavaScript in the context of the currently displayed page, making it such that the super-app-supplied code executes with the same page-level authority as the mini-app’s own scripts [5]. It can access the DOM, window, global variables, and any Web APIs available to the page context. Given this architectural capability, we ask how MAX can inject its own code into a mini-app’s runtime. In MAX, the communication channel between mini-app and superapp is bidirectional but asymmetric. In the mini-app to super-app direction, the surface is narrow and fully fixed:

Performance Telemetry When a mini-app loads a new page, we observed that MAX injects a one-shot probe that measures first-contentful-paint and reports the result back to it via a dedicated JavaScript bridge. The probe is not injected uniformly for all mini-apps, suggesting host or session-level configuration. This is used to capture the performance of each page by observing the time (in milliseconds) since navigation start. Bridge Response MAX sends data to a mini-app by injecting JavaScript into the mini-app’s context. Most bridge calls follow a normal API request-response flow: the mini10

Event

Purpose

DeviceStorageGetKey DeviceStorageSaveKey SecureStorageGetKey SecureStorageSaveKey BackButtonPressed HapticFeedbackImpact HapticFeedbackNotification MaxShare DownloadFile RequestPhone

key–value read response key–value write ack Encrypted key–value read response Encrypted key–value write ack Synthetic UI event Haptic impact ack Haptic notification ack Share completion Download state Phone-number request response

Figure 10: Network Interception. Intercepted mini-app requests reveal important travel booking details like origin/destination, dates, party composition, the specific Pobeda flight DP435 with offerId, and a named hotel property.

Table 2: Bridge Response Events. All event names share the prefix WebApp.

surface would lead one to conclude that the mini-app traffic is completely invisible to the super-app. However, the WebView client APIs, including WebViewClient, WebChromeClient, and the @JavascriptInterface bridges registered, run in the super-app process by design. Given this architectural capability, we ask whether MAX can use it to intercept a mini-app’s network activities. In MAX, the aforementioned APIs can be invoked for every observable event in a mini-app’s lifecycle. Taken together, the callbacks in response to WebView lifecycle, navigation, resource, console, and error events reconstruct an almost complete activity trace of every mini-app session. During our experiments we observed several observational channels (see Table 3): (1) Resource Requests. MAX observes each mini-app’s requests for resources before they leave the WebView and has the ability to block, rewrite, or inject content into any of these requests. (2) URL Loads. On every page navigation initiated by the webpage, user, or an HTTP redirect, MAX is presented with the full destination URL. This includes the mini-app’s initialization payload containing user ID, chat ID, authentication date, and an HMAC tag passed as a URL fragment. (3) Network & HTTP Errors. MAX gets a detailed view of its mini-app’s operational health as it reviews private error information via callbacks. This includes HTTP errors, host name resolution failures, SSL protocol failures, connection errors, and time-outs. (4) Page Lifecycle & Performance. MAX receives a timestamped log of every page the user visits within a mini-app, at millisecond resolution. Combined with the performance telemetry (Section 4.3), MAX has complete details about the entire lifecycle and performance of each page in a mini-app. (5) Application Runtime Outputs. MAX receives console logs from the JavaScript calls made by its mini-apps. Through our instrumentation, we observed several critical details leaking from these console log messages, including the user ID, authentication errors, and, in some cases, the full authentication payload. (6) File Download. When a mini-app starts a file download via the bridge, the file bytes transit through MAX’s process rather than being delivered directly to the mini-app. Altogether, these methods give MAX a comprehensive runtime view of every mini-app session: which pages the user

app calls postEvent, and MAX returns the response through WebApp.sendEvent with a matching requestId. For others, MAX unilaterally sends data to the mini-app: For example, we observed WebAppBackButtonPressed event was MAXinitiated. The mini-app receives both bridge responses and super-app initiated events through the same mechanism. Unless the mini-app implements its own provenance checks, it has no built-in mechanism to verify whether an incoming event is a genuine reply to a request it made or super-app initiated event. The response channel also carries identity material. We observed three distinct identifiers in transit through bridge responses: device-token-max-app: Persistent per-device token, siMAX: post-ESIA session UUID, and delegatedAuthorizationCounter: ESIA auth-state counter. Overall, while this JS injection capability currently provides legitimate functionality to mini-apps, it gives the superapp control over both code and data flowing into the mini-app. First, MAX can run JavaScript in the mini-app’s context, with full access to the DOM, window, and all Web APIs. The polyfill and telemetry injections documented above confirm that MAX is actively exercising this capability. Next, super-app injected events arrive through the same WebApp.sendEvent interface as responses to mini-app requests, making them indistinguishable from a genuine reply. Lastly, the response channel carries sensitive material like persistent device identifiers, storage values, and authentication state in plaintext. The mini-app must trust that these values are authentic because it has no mechanism to verify them independently. ▶ Takeaway: A malicious super-app can silently inject and execute arbitrary JavaScript inside a mini-app, with no mechanism for the mini-app to distinguish injected code or data.

4.4 Interception of Mini-app Network Activity In Android, a mini-app’s HTTP requests do not traverse the super-app’s HTTP client, connection pool, or socket layer and should not appear in the super-app’s process-level network statistics. Instrumenting only the super-app’s network 11

visits, what resources they fetch, which API endpoints they contact, what errors occur, what the developer logged to the console, and what files the user downloads. The WebView’s process isolation protects the mini-app’s JavaScript heap and DOM from direct super-app inspection but nearly everything the mini-app does is reported to the super-app through the WebView client API surface. ▶ Takeaway: A malicious super-app can intercept a miniapp’s network requests and reconstruct a detailed image of its activities at runtime, including page loads, resource requests, errors, console logs, and downloads.

4.5

Figure 11: MAX’s Consent Response. MAX’s response to a mini-app when the user declines the phone-share consent dialog. User Consent All mini-app permission requests are mediated by MAX. Mini-apps request for permissions via the JS bridge, while MAX holds the underlying permission and returns its response through the evaluateJavascript channel. As a result, the mini-app cannot independently verify whether the returned decision matches the user’s choice. For example, WebAppRequestPhone allows a mini-app to request the user’s phone number; MAX is responsible for displaying the consent dialog and returning the response to the mini-app. MAX sees the following identity attributes during miniapp interactions: the user’s user.id and persistent per-device tokens issued by MAX itself, and JWTs, OAuth tokens, ESIA credentials, or session cookies the mini-app accumulated, visible in transit, readable from the shared cookie jar, or stored in bridge-mediated storage. The mini-app does not seem to have any independent verification path for the user’s identity.

Impersonation of User to Mini-app

In a standard Android app, the app-server authenticates the user directly through its own login flow, its own session tokens, and direct integration with identity providers. Typically, an app does not rely on its hosting environment to vouch for who the user is. However, a super-app interposes itself between the user and the mini-app, issuing identity on the user’s behalf and mediating access to device capabilities through a bridge API. Given this architectural capability, we ask whether MAX has identity attributes that can enable it to impersonate a user to mini-apps. During our experiments, we observed three points where MAX sits between a user and a mini-app for authentication and authorization: (1) super-app issued identification, (2) third-party authentication, (3) user consent.

▶ Takeaway: A malicious super-app has everything it needs to present itself as the user to any hosted mini-app, or to present a fabricated response as though it came from the mini-app’s own backend. This opens up a channel that can be misused by a super-app with malicious intent to impersonate a user to a mini-app.

Super-app Issued Identification Every mini-app page load arrives with a WebAppData URL fragment that MAX constructs and appends to the mini-app’s URL. The bundle contains six identity fields: user.id, chat.id, auth_date, query_id, ip, and an HMAC integrity token as a hash. Beyond the per-session initData, MAX issues persistent identifiers that mini-apps store and retrieve through the bridge.

5

Third-party Authentication When a mini-app authenticates via an external provider, MAX can observe authentication material that should remain between the mini-app and the identity provider. We observe this at multiple layers: mini-apps pass authentication URLs through MAX before opening them in the system browser, share WebView cookies across unrelated mini-app contexts, expose credentials in console output captured by MAX, and store cookies and web storage under MAX’s UID. An illustrative case that we saw in our captures was the federal school portal (school-app.gosuslugi.ru) initiating ESIA authentication through WebAppOpenLink with a URL containing a client_secret parameter that contained approximately 4 KB of X.509 certificate material from Russia’s Roskazna PKI. As a result, we saw the full authentication bundle for the state services portal, including the cryptographic client credential transit through MAX before the system browser opened.

Super-apps within Android’s Threat Model

In this section, we use Mayrhofer et al.’s account of Android’s security model as a baseline for analyzing super-apps [32]. Their model recognized that Android must give developers enough flexibility to support diverse application patterns, while also providing guardrails that preserve interoperability and prevent misuse of OS mechanisms. Super-apps sit exactly at this intersection, where the design provides significant convenience but lacks meaningful guardrails to prevent architectural misuse. Android’s security relies on its ability to provide adequate isolation between untrusted applications. A core assumption is that each app is distributed as a single Android package, assigned its own UID by developer, and can therefore be isolated from other apps at the process, storage, and network boundaries. This allows Android, via a combination of runtime permissions, SELinux MAC policies, and standard unix12

based filesystem controls, to identify the app requesting a resource, check the permissions granted to the app, and grant or deny access. Since the OS can no longer mediate permissions or provide isolation, the super-app architecture weakens Android’s ability to provide any guarantees to the mini-app. A super-app is still isolated from other Android apps installed on the device, but Android cannot mediate mini-apps as separate apps. Though Android’s security model anticipates “external web resources loaded by an embedded WebView,” it treats them as belonging to the hosting app’s domain [32]. Mini-apps, however, are not webpages: they can implement complicated app-like functionality through super-app mediated APIs. As we discussed in Section 4, the super-app has minimal isolation from the mini-apps, allowing for several active attacks. It can screenshot mini-app content, read and write all of its local storage, inject arbitrary JavaScript, mediate all network traffic, and control its auth tokens to silently impersonate any user to any mini-app. Another natural consequence of this isolation collapse is the loss of multi-party authorization. Android’s security model is based on multi-party authorization which means an action should only be permitted if all parties (user, developer, and platform) authorize it [32]. When a native app requests for a permission on Android, the user and the platform may veto granting that permission, and the platform needs to enforce that decision. However, when a mini-app asks for a permission, the platform and the user have no visibility or control over granting or denying that permission, and the super-app remains the sole arbiter. Further, Android’s open-ecosystem assumes that thirdparty code remains “packaged, signed, and reviewed before execution” [32]. In contrast, a super-app is capable of dynamically loading mini-app code at runtime, and Android has no way to attest what code actually runs. Viewed through the security model’s own threat assumptions, the super-app is positioned to mount the very threats against its mini-apps that the Android tries to neutralize between two apps. This raises a crucial question: What is Android’s position in the super-app architecture? Android remains the platform for the host app, but it is no longer serving as a platform for the mini-app. For mini-apps, the super-app becomes the trusted computing base providing runtime, storage, network, and permission mediation. This creates an authorization collapse. Android can mediate the super-app’s access to the device capabilities, but it cannot directly mediate a mini-app’s access to these capabilities. From Android’s perspective, all the permissions requested by the super-app are reasonable given its delegated role as a platform. It is equally impossible to statically audit if the super-app manages these permissions appropriately, given the mini-apps that may use it will be dynamically loaded at run time. Finally, this trusted computing base is unverified by Android and unconstrained by any compatibility requirements, platform integrity checks, and

system-level access control rules. It remains an ordinary thirdparty app, yet mini-apps must trust it with OS-like authority.

6

Recommendations

In this section, we propose a set of defenses aimed at constraining the super-app’s unchecked capabilities. Our results show how malicious super-apps have dangerous capabilities that silently undermine the security and privacy of mini-apps and users. They also show how these capabilities violate the core security assumptions of the Android security model. We offer near-term strategies as well as longer-term architectural responses and discuss their relative strengths and weaknesses. Our recommendations are designed around the premise that a super-app enforcing its own guardrails is insufficient specifically when a super-app operates under government pressure. Meaningful protections must therefore come from the operating system, or the app store. Fine-grained Permissions. Android could offer immediate relief by allowing users to revoke INTERNET and ACCESS_NETWORK_STATE permissions, or “allowed only while in use”, as we currently have for fine-grained location. Paired with a restriction on background execution for such apps would prevent a disabled super-app from passively collecting data while offline and exfiltrating it once connectivity is restored. Architectural Changes. In the longer term, the OS can close the visibility and isolation gaps it currently leaves unaddressed. We propose three escalating classes of defense: transparency, auditability, and architectural redesign. First, we recommend user-facing transparency mechanisms. The OS should notify the user when the super-app captures a mini-app’s UI. This also naturally extends naturally to two further disclosures that are omitted by the current model. First is an explicit, OS-level indication when a user enters a super-app mediated context, similar to the security indicators indicating VPN or location use. Ideally, there should be an OS-level list of all installed mini-apps, so that the user has the ability to see and revoke permissions through an OS interface. Second, the OS should enable auditability through OSenforced mechanisms that detects when a super-app accesses or modifies mini-app content, storage, or traffic. For example, every time shouldInterceptRequest is called, the function should be logged along with the resource request intercepted by the super-app. Logs of super-app to mini-app actions should be tamper-resistant and written such that when the super-app misbehaves, it leaves evidence the OS can attest. Third, we call for innovation in the super-app architecture that lets mini-apps establish trust independently of the super-app. Structurally, the OS should create delineation and restriction in the way it imposes security barriers among apps. With that delineation, the OS should provide per-mini-app sandboxing similar to browser site isolation, assigning each mini-app a distinct security principal with its own storage partition and process boundary so that the super-app can no 13

longer read across mini-apps. It should offer OS-mediated secure channels through which a mini-app reaches its own backend without any network intermediaries, so that even a malicious super-app cannot read or alter the traffic. Finally, there should be some attestation schemes through which a mini-app’s backend can verify it is talking to genuine, unmodified mini-app code, and signed mini-app bundles recorded in a transparency log, restoring the provenance and tamper-evidence guarantees that APK signing provides today.

7

Conclusion

In this paper, we analyze the capabilities of a super-app architecture using a case study of Russia’s state-backed super-app. Through detailed instrumentation and reverse engineering, we show dangerous capabilities available to a super-app to silently act as a man-in-the-middle for all the mini-app interactions. While we didn’t observe MAX actively exploiting these capabilities maliciously, none the less our finding reveal that MAX, like any other super-app, is architecturally capable of exercising them. With all mini-apps running under a single Android principal, Android security model does not have any built-in mechanisms to constrain or audit a super-app. Users and mini-app developers are similarly blind, and do not have a way to meaningfully defend against a malicious super-app. We therefore argue that super-apps should not be treated as ordinary apps by mobile operating systems and app stores. The mobile OS needs defenses that make super-app’s mediation of mini-apps constrained and easily auditable. In the near term, Android should give users stronger control over internet access and background execution. Long term, the mobile OS should support increased transparency, tamperresistant audit logs, and architectural isolation between the super-app and mini-apps.

14

References

[15] P. Dietrich. The key player in Russia’s cybersphere: What the West needs to know about VK company. DGAP Analysis 4, German Council on Foreign Relations (DGAP), September 2023. [Online]. Available: https://dgap.org/en/research/publications/ key-player-russias-cybersphere.

[1] 3ntr0py. Полная доказательная база аудита мессенджера MAX. Habr, June 2026. [2] Alibaba Cloud. Dingtalk: The all-in-one super app, 2023.

[16] D Dittrich and E Kenneally. The Menlo Report: Ethical Principles Guiding Information and Communication Technology Research. Technical report, U.S. Department of Homeland Security, August 2012.

[3] Android Developers. How android draws views, May 2026. [4] Android Developers. Pixelcopy, 02 2026. [5] Android Developers. Webview, 2026.

[17] P. Dixit. India’s largest digital wallet has been accused of handing over user data to the government. BuzzFeed News, 2018. [Online]. Available: https://www.buzz feednews.com/article/pranavdixit/india-pay tm-data-sharing-government-jammu-kashmir.

[6] Y. Cai, Z. Zhang, M. Yao, J. Liu, X. Zhao, X. Fu, R. Li, Z. Li, X. Chen, Y. Guo, and D. Li. I can tell your secrets: Inferring privacy attributes from mini-app interaction history in super-apps. In Proc. 34th USENIX Security Symposium (USENIX Security), 2025.

[18] E. Alekseev Ed. S. Smyshlyaev, D. Belyavskiy. Rfc 9189. gost cipher suites for transport layer security (tls) protocol version 1.2. Technical report, RFC Editor, 2022.

[7] Chumikov Sec. Какие запросы и куда отправляет MAX. https://habr.com/ru/articles/939550/, September 2025.

[19] Electronic Frontier Foundation. The UK is still trying to backdoor encryption for Apple users. EFF Deeplinks Blog, October 2025. [Online]. Available: https://ww w.eff.org/deeplinks/2025/10/uk-still-tryin g-backdoor-encryption-apple-users.

[8] Chumikov Sec. Разрешения MAX для Android. Cравниваем с Telegram и WhatsApp*. https: //habr.com/ru/articles/939006/, August 2025. [9] CNN Business. Kremlin-backed Max messenger app to be pre-installed on all smartphones sold in Russia. CNN, August 2025. [Online]. Available: https://ww w.cnn.com/2025/08/21/tech/max-messenger-a pp-russia-smartphones-intl.

[20] France 24. Russia’s Max: The unencrypted super-app being forced on citizens. France 24, March 2026. [Online]. Available: https://www.france24.com/en/li ve-news/20260323-russia-s-max-the-unencry pted-super-app-being-forced-on-citizens.

[10] Council of the EU, 2026. [Online]. Available: https: //www.consilium.europa.eu/en/press/press-r eleases/2026/07/13/human-rights-violation s-in-russia-council-lists-four-individuals -and-five-entities-over-abusive-surveilla nce/.

[21] Freedom House. Freedom on the net 2021, 2021. [22] Global Encryption Coalition. Sweden’s proposed law threatens encryption security. MediaNama, April 2025. [Online]. Available: https://www.medianama.com/ 2025/04/223-sweden-encryption-backdoor-law -global-encryption-coalition-warning/.

[11] Jedidiah R. Crandall, Masashi Crete-Nishihata, and Jeffrey Knockel. Forgive us our SYNs: Technical and ethical considerations for measuring Internet filtering. In Ethics in Networked Systems Research. ACM, 2015.

[23] Maksim Grishutin. Технический разбор Max: что внутри APK. https://habr.com/ru/articles/9 38518/, August 2025.

[12] CyberB. MAX без оболочки: Что мы нашли в его APK. https://habr.com/ru/articles/945306/, September 2025.

[24] Human Rights Watch. Saudi arabia’s absher app: Controlling women’s travel while offering government services, 2019.

[13] Sarah Dai. Baidu strengthens ‘super app’ foothold with 100 million monthly active mini-program users. South China Morning Post, 2018.

[25] Infosecurity Magazine. Signal may exit Sweden if government imposes encryption backdoor. Infosecurity Magazine, February 2025. [Online]. Available: https://www.infosecurity-magazine.com/ne ws/signal-exit-sweden-government/.

[14] Daria Talanova. Like, share, deadline. Novaya Gazeta, December 2024. [Online]. Available: https://novaya gazeta.eu/articles/2024/12/02/laik-sher-s rok. 15

[26] Izvestia. Messenger MAX topped the ratings of Google Play and App Store. Izvestia, August 2025. [Online]. Available: https://en.iz.ru/en/1937454/2025-0 8-15/messenger-max-topped-ratings-google-p lay-and-appstore.

[38] Observer Research Foundation. This isn’t just about Paytm — laws on government access to data need to change. ORF, 2018. [Online]. Available: https://ww w.orfonline.org/research/this-just-paytm-l aws-government-access-data-need-change/.

[27] J. Knockel, C. Parsons, L. Ruan, R. Xiong, J. Crandall, and R. Deibert. We chat, they watch: How international users unwittingly build up WeChat’s Chinese censorship apparatus. Technical Report 127, The Citizen Lab, University of Toronto, May 2020. [Online]. Available: https://citizenlab.ca/2020/05/we-chat-the y-watch/.

[39] George Obulutsa. Kenya’s government to sell more of its stake in safaricom, finance minister says, 2025. [40] Open Technology Fund Security Lab. Iranian messaging apps security audit. Technical report, Open Technology Fund, 2024. [Online]. Available: https://www.open tech.fund/security-safety-audits/iranian-m essaging-apps-security-audit/.

[28] Jeffrey Knockel, Ken Kato, and Emile Dirks. Missing links: A comparison of search censorship in china. The Citizen Lab, 2023.

[41] Reethika Ramesh, Ram Sundara Raman, Apurva Virkud, Alexandra Dirksen, Armin Huremagic, David Fifield, Dirk Rodenburg, Rod Hynes, Doug Madory, and Roya Ensafi. Network responses to Russia’s invasion of Ukraine in 2022: A cautionary tale for Internet freedom. In USENIX Security Symposium. USENIX, 2023.

[29] Rita Liao. Alibaba’s alternative to the app store reaches 230m daily users, 2019. [30] Rita Liao. Telegram founder pavel durov says he received summons in russia addressed to ’suspect’, 2026.

[42] RKS Global. Testing for surveillance in MAX on android and iphone. https://rks.global/research/ max/?lang=en, September 2025.

[31] H. Lu, L. Xing, Y. Xiao, Y. Zhang, X. Liao, X. Wang, and X. Wang. Demystifying resource management risks in emerging mobile app-in-app ecosystems. In Proc. ACM SIGSAC Conf. Computer and Communications Security (CCS), pages 569–585, 2020.

[43] RKS Global. Detecting surveillance in 30 popular russian apps. Technical report, RKS Global, April 2026. [44] Shivani Shinde. It’s loading: Paytm looks to become a super app by the end of year. Business Standard, 2021.

[32] René Mayrhofer, Jeff Vander Stoep, Chad Brubaker, Dianne Hackborn, Bram Bonné, Güliz Seray Tuncay, Roger Piqueras Jover, and Michael Specter. The android platform security model (2023). ACM Transactions on Privacy and Security, 2023.

[45] The Citizen Lab. Signal warns it would pull out of Canada if made to comply with lawful access bill. The Citizen Lab, University of Toronto, May 2026. [Online]. Available: https://citizenlab.ca/signal-warns -it-would-pull-out-of-canada-if-made-to-c omply-with-lawful-access-bill/.

[33] Meduza. Starting september 1, all school and parent chats in moscow will be transferred to the max messenger., August 2025.

[46] The Globe and Mail. Signal warns it would pull out of Canada if made to comply with lawful access bill. The Globe and Mail, May 2026. [Online]. Available: https://www.theglobeandmail.com/politics/a rticle-signal-warns-it-would-pull-out-of-c anada-if-made-to-comply-with-lawful/.

[34] Meduza. Whatsapp says russia’s ban on calls is an attempt to ‘violate people’s right to secure communication’, August 2025. [35] Meduza. Telegram blocking rate in russia reaches 95%, April 2026. [36] Arvind Narayanan and Bendert Zevenbergen. No encore for Encore? ethical questions for web-based censorship measurement. Technology Science, 2015.

[47] The Moscow Times. Telegram outages reported across Russia as block rumors swirl. The Moscow Times, March 2026. [Online]. Available: https://www.them oscowtimes.com/2026/03/16/telegram-outages -reported-across-russia-as-block-rumors-s wirl-a92233.

[37] Novaya Gazeta Europe. Russian telecom operators block new users from registering with Telegram and WhatsApp. Novaya Gazeta Europe, October 2025. [Online]. Available: https://novayagazeta.eu/articl es/2025/10/31/russian-telecom-operators-b lock-new-users-from-registering-with-teleg ram-and-whatsapp-en-news.

[48] TikTok. Thanks a billion!, 2021. [49] The Moscow Times. So you want to travel to russia. here’s what you should know., July 2025. 16

[50] Tuoi Tre News. Zalo updates terms to expand personal data collection, sparks backlash in Vietnam. Tuoi Tre News, December 2025. [Online]. Available: https: //news.tuoitre.vn/zalo-updates-terms-to-e xpand-personal-data-collection-sparks-bac klash-in-vietnam-103251229133905443.htm.

[61] Zeyi Yang. Wechat users are begging tencent to give their accounts back after talking about a beijing protest. MIT Technology Review, October 2022. [62] C. Zakrzewski. U.K. orders Apple to let it spy on users’ encrypted accounts. The Washington Post, February 2025. [Online]. Available: https://www.washington post.com/technology/2025/02/07/apple-encry ption-backdoor-uk/.

[51] Turkish Minute. Messaging app promoted by erdoğan can analyze users’ state of mind, 2021.

[63] J. Zhang, L. Yang, Y. Han, Z. Xiang, and X. Hei. A small leak will sink many ships: Vulnerabilities related to mini-programs permissions. In Proc. IEEE 47th Annual Computers, Software, and Applications Conf. (COMPSAC), 2023.

[52] Fernando N van der Vlist, Anne Helmond, Michael Dieter, and Esther Weltevrede. Super-appification: Conglomeration in the global digital economy. New Media & Society, 27(6):3314–3337, 2025. [53] C. Wang, Y. Zhang, and Z. Lin. One size does not fit all: Uncovering and exploiting cross platform discrepant APIs in WeChat. In Proc. 32nd USENIX Security Symposium (USENIX Security), 2023.

[64] Lei Zhang, Zhibo Zhang, Ancong Liu, Yinzhi Cao, Xiaohan Zhang, Yanjun Chen, Yuan Zhang, Guangliang Yang, and Min Yang. Identity confusion in WebViewbased mobile app-in-app ecosystems. In Proc. 31st USENIX Security Symposium (USENIX Security), pages 1597–1614, 2022.

[54] C. Wang, Y. Zhang, and Z. Lin. Uncovering and exploiting hidden APIs in mobile super apps. In Proc. ACM SIGSAC Conf. Computer and Communications Security (CCS), 2023.

[65] X. Zhang, Y. Wang, X. Zhang, Z. Huang, L. Zhang, and M. Yang. Understanding privacy over-collection in WeChat sub-app ecosystem. In Proc. 32nd USENIX Security Symposium (USENIX Security), 2023.

[55] Mona Wang, Pellaeon Lin, Jeffrey Knockel, Will Greenberg, Jonathan Mayer, and Prateek Mittal. What WeChat knows: Pervasive first-party tracking in a billion-user super-app ecosystem. In Proc. Privacy Enhancing Technologies Symposium (PoPETs), volume 2025, 2025. [Online]. Available: https://petsymposium.org/p opets/2025/popets-2025-0163.php.

[66] Y. Zhang, Y. Yang, and Z. Lin. Don’t leak your keys: Understanding, measuring, and exploiting the AppSecret leaks in mini-programs. In Proc. ACM SIGSAC Conf. Computer and Communications Security (CCS), 2023. [67] Yue Zhang, Bayan Turkistani, Allen Yuqing Yang, Chaoshun Zuo, and Zhiqiang Lin. A measurement study of WeChat mini-apps. ACM Transactions on Measurement and Analysis of Computing Systems, 2021.

[56] Yue Wang, Yao Yao, Shangcheng Shi, Weiting Shen, and Lin Huang. Towards a better super-app architecture from a browser security perspective. In Proceedings of the 2023 ACM Workshop on Secure and Trustworthy Superapps. Association for Computing Machinery, 2023.

[68] Yue Zhang, Chao Wang, and Zhiqiang Lin. RootFree attacks: Exploiting mobile platform’s super apps from desktop. In Proc. 19th ACM Asia Conf. Computer and Communications Security (ASIA CCS), 2024.

[57] WebView docs. Software draw deprecated. [58] Mingshi Wu, Ali Zohaib, Zakir Durumeric, Amir Houmansadr, and Eric Wustrow. A wall behind a wall: Emerging regional censorship in China. In Symposium on Security & Privacy. IEEE, 2025. [59] Diwen Xue, Benjamin Mixon-Baca, ValdikSS, Anna Ablove, Beau Kujath, Jedidiah R. Crandall, and Roya Ensafi. TSPU: Russia’s decentralized censorship system. In Internet Measurement Conference. ACM, 2022. [60] Yuqing Yang, Yue Zhang, and Zhiqiang Lin. Understanding miniapp malware: Identification, dissection, and characterization. In Proc. Network and Distributed System Security Symposium (NDSS), 2025. 17

A

Appendix

Open Science

Ethics Considerations

As per the open science policy, we make all of our artifacts available at the following link: https://github.com/censoredplanet/rmax. It contains the sanitized plaintext capture logs that underpin our results, the instrumentation used to collect them, and the decoding and analysis tooling used to process them. A README at the top level details the artifact and folder structure, the software and device requirements, and the format of the capture logs. In the following, we detail all parts of our artifact.

There are several aspects of this study where we considered the ethical risks that could arise from our work. The goal of this study is to analyze the super-app architecture, zooming into the security risks it poses for its users. Therefore, we designed and conducted this study following the ethical principles of the Menlo Report [16] and in accordance with community norms established by similar measurement work [11, 36, 41, 58, 59]. Below we identify the stakeholders potentially affected by our work, the harms and benefits relevant to each, the safeguards we adopted, and our justification for conducting and publishing this research.

Instrumentation. The unified Frida script described in Section 3.2 is located in runtime-capture/max-capture-unified-ru.js. It arms hooks across the four functional layers we describe — TLS read/write, the JavaScript bridge, WebView callbacks, and sensitive Android APIs — and detects the app build at startup, selecting the CryptoPro GOST hooks for the Russian build and the Conscrypt/BoringSSL path otherwise. A single script covers both builds. The wrapper runtime-capture/max-capture-ru.sh spawns or attaches to the app, injects the run configuration, and writes a timestamped capture file.

Stakeholders. We identify four groups of stakeholders: (1) ordinary MAX users in Russia, (2) MAX’s operator and the broader MAX platform/ecosystem, (3) the research and activist communities who stand to benefit from an accurate understanding of MAX’s region-dependent behavior and VPNdetection practices, (4) the Internet freedom community member who provided our Russian vantage point. Potential harms and mitigations. For our analysis, every interaction with MAX and its mini-apps was generated by test accounts on devices controlled entirely by our research team. We proxied our MAX traffic through a Russian vantage point (VP) to capture MAX’s native behavior. The VP was acquired through our collaboration with an Internet freedom community member with years of experience on network traffic analysis in Russia. They have been collaborating with the research community for the last 6 years, and explicitly consented to use their VP for this study. The VP was used solely for the traffic strictly necessary to evaluate region-dependent behavior in MAX. We manually interacted with MAX and selected mini-apps from our test accounts as ordinary users and did not run any tests or generate any traffic that would trigger the Russian censorship system. We also did not probe any Russian infrastructure, or generate large volumes of traffic which could degrade availability for other users.

Decoding and Analysis. runtime-capture/ingest_capture.py implements the decoding and correlation stage of Section 3.4 and the analysis database of Section 3.5. It parses the binary RPC envelope specified in Table 1, joins the [EVT]/[DATA]/[PROBE] triplets by (ssl_id, seq, dir), reassembles the per-connection byte stream before extracting RPC frames and pairs bridge dispatches with injected responses by requestId, emitting round-trip latencies and retaining unmatched injections as host-initiated events. Capture Logs. runtime-capture/sanitized-data/ contains the sanitized session logs, organized into three capture sets. This is the source data for the capabilities we report in Sections 4.1 through 4.5, and cover the mini-apps listed in Table 4. The log format is documented in detail in the README so the logs can be re-parsed independently of our tooling. Mini-app UI Capture. screenshot-capture/ contains the Frida script used for the UI capture results of Section 4.1 and Figure 5, together with the frames it produced. Every released frame has been manually reviewed.

Justification We believe the safety and privacy risks of this study were minimal by design: no real users were studied, no censorship infrastructure was probed, no traffic volumes large enough to affect availability were generated. Against this limited risk, we weigh the benefit of publicly documenting how a widely used platform could be used for undermining user privacy and security. The generated knowledge is valuable both to the research community studying privacy and surveillance, and ultimately, to the users such mechanisms affect. We therefore believe the balance of risks and benefits favors conducting and publishing this work.

Anonymization. Every capture log has been sanitized to remove material that identifies our test accounts, our devices, or our measurement vantage point: account phone numbers and names, user and session identifiers, authentication tokens and one-time codes, device fingerprints and hardware serials, all IP addresses, and any free-text message content. Values are replaced rather than deleted. Each secret becomes a stable placeholder derived from a keyed hash, so that the same value 18

Category

Function

Description

Resource Request URL Load Network & HTTP Errors Network & HTTP Errors Network & HTTP Errors Network & HTTP Errors Network & HTTP Errors Page Lifecycle & Performance Page Lifecycle & Performance Application Runtime Outputs File Download

shouldInterceptRequest shouldOverrideUrlLoading onReceivedHttpError onReceivedError net::ERR_CONNECTION_TIMED_OUT net::ERR_SSL_PROTOCOL_ERROR net::ERR_NAME_NOT_RESOLVED onPageStarted onPageFinished onConsoleMessage WebAppDownloadFile

Host inspects a WebView resource request and can optionally supply its own response. Host decides whether WebView should load a navigation URL. Reports HTTP errors, i.e., response status codes ≥ 400. Reports resource-loading failures, such as connection errors. Chromium error for a timed-out connection attempt. Chromium error for an SSL protocol failure. Chromium error for failed hostname resolution. Reports that a load has started. Reports that a page load has finished. Reports JavaScript console messages. Bridge function used to support mini-app file downloads.

Table 3: Observed WebView Callbacks and Runtime Events.

Figure 12: Mini-app Search. Navigate to search on Max, and search for the mini-app’s name or related keywords; (2) Click on one of the entries from search to launch the associated chatbot; (3) Launch the mini-app from the "Start" button. always yields the same placeholder across the corpus. This preserves the properties our analysis depends on without the underlying value being recoverable.

19

Table 4: Observed MAX Mini-apps. Names, English names, and bot identifiers are preserved as collected. Name Национальная электронная библиотека Республики Татарстан JetBot - конструктор чат-ботов Ozon Fresh Ozon Travel Чат-Бот МФЦ Республики Дагестан Чат-бот МФЦ Чеченской Республики Алиса Al Министерство ЖКХ и ТЭ РСО-Алания Teeeams T2 Сферум Помощник Сферума Мосбилет: афиша Москвы Мос.Фото ГИС-бот Ямал Моё здоровье - Запись на прием - Омская область Доктор Миша (запись к врачу в Хабаровском крае) Тыва. Запись к врачу Запись к врачу в Кузбассе Госуслуги Культура Госуслуги Дом Госуслуги Камчатского края Госуслуги Республики Татарстан Госуслуги. Моя школа Госуслуги Решаем Вместе «Мое здоровье» Магаданская область Мое здоровье Республика Алтай Смоленск. Моё здоровье Мое здоровье. Забайкалье RUSSPASS Бот Моё здоровье. Ленинградская область Интервидение 2025 Сервис «Мое здоровье» Мурманской области Электронные сервисы в здравоохранении области Курской Запись к врачу СПб -Служба 122 Новогодний адвент-календарь МАХ Запись к врачу и Телемедицина. Краснодарский край Бессмертный полк онлайн Телемедицинские консультации Архангельской области Город заданий Моё здоровье Ростовская область Помощник Министерства Имущества | Хабаровск ЕКЦ СФР WiFi в ЯНАО Амбассадоры Пушкинской карты Чат-бот Республики Адыгея "Бэла"

English Name

Bot_id

National Electronic Library of the Republic of Tatarstan

rt_kitap_bot

JetBot Ozon Fresh Ozon Travel

support_jet_bot ozonfresh_bot ozontravel_bot

Multifunctional Centers (MFC) of the Republic of Dagestan.

mfcrd2025_bot

Multifunctional Centers (MFC) of the Republic of Chechen.

mfcchr_maxbot

Yandex Alice AI

alice

Ministry of Housing and Public Utilities, Fuel and Energy of the Republic of North Ossetia-Alania Teeeams T2 Sferum Sferum Assistant

minjkh_rso_a_bot teeeams_bot t2russia_bot sferum_bot sferum_help

Mosbilet: Moscow Poster

mosbilet_bot

Mosphoto GIS-bot Yamal

mosfoto_bot gisyamal_bot

My Health

kvrachu_omsk_bot

Doctor Misha (appointment with a doctor in the Khabarovsk Krai)

mishakhv_bot

Tuva. Doctor’s appointment Appointment with a doctor in Kuzbass Gosuslugi Kultura Gosuslugi Dom Gosuslugi Kamchatka Krai

zdrav_tuva_bot kuzdrav_vrach42_bot gosuslugi_culture_bot gosuslugi_dom_bot gosuslugi41_kamchatka_bot

State Services Portal of the Republic of Tatarstan

UslugiRT_bot

Gosuslugi Moya Shkola Gosuslugi. We Decide Together

school_bot reshaem_vmeste_bot

"My Health" Magadan Oblast

magadanzdrav_bot

My Health Republic of Altai

minzdrav_respaltay_bot

Smolensk. My Health My health. Zabaykalye RUSSPASS Bot

reg67_medicina_bot zapv_75_bot russpass_bot

My health. Leningrad Region

doctor_lenobl_bot

Intervision 2025 "My Health" Service Murmansk Region Electronic services in healthcare of the Kursk region

intervision_2025_bot

kurskzdrav_bot

Doctor’s appointment St. Petersburg - Service 122 New Year’s Advent Calendar MAX

spb_122_bot max_advent_2025_bot

Doctor’s appointment and Telemedicine. Krasnodar Krai

zapis_na_priem_kk_bot

Immortal Regiment Online

polk_app_bot

Telemedicine consultations of the Arkhangelsk Region

zdrav29_bot

mur_zdrav51_bot

City of Tasks

gorod_zadaniy_bot

My health Rostov region

zdrav_rnd_bot

Ministry of Property Assistance | Khabarovsk

Yamalo-Nenets Autonomous Okrug (YNAO)

min_imushestvo_khabarovsky_kray_bot sfr_chat_bot free_yanao_bot

Ambassadors of the Pushkin Card

ambassador_pushkincard_bot

Republic of Adygea "Bella"

adg_bela_bot Continued on next page

20

Continued from previous page Name

English Name

Bot_id

Конструктор открыток Post Card Builder Ак Барс Онлайн Ak Bars Online Страховая компания «Согласие» Soglasie Insurance Company Знание. Премия: народное голосование Znanie.Award Переменка Peremenka Банк Русский Стандарт Russian Standard Bank АльфаСтрахование AlfaStrakhovanie Чат-бот «Мои Документы Москвы». My Documents Moscow Чат-бот «Активного Active Citizen Chatbot гражданина» ЕМИАС.ИНФО EMIAS.INFO Помощник от Rosgosstrakh Росгосстраха Помощник Курского приграничья Assistant to the Kursk Borderland Виртуальный помощник по вопросам ЗАГС Virtual assistant for civil registry office (ZAGS) matters in the Мурманской области Murmansk region Карта жителя РТ Citizen Card of the Republic of Tatarstan Мое Здоровье. My Health. Vladimir Region Владимирская область Глиф х Дзен Dzen Острова.65 Сахалинская область Ostrov.65 Sakhalin Region Мой рецепт Челябинская область My Prescription - Chelyabinsk Region МФЦ Кировской области MFC Kirov Region МФЦ Республика MFC My Documents Алтай

maxpostcards_bot akbarsonline_bot soglasie_bot znanie_premiya_bot. peremenka_bot bank_russian_standart_bot alfastrah_bot mfc_moscow_bot

Мошенник Не Пройдет

stop_moshennik_bot

Карта жителя Курской области Почта Бизнес Афиша Тверской области МФЦ Республики Ингушетия МФЦ РСО-Алания Чат-бот региональных услуг Кировской области план б Ингосстрах Пульс образования Salebot Техническая поддержка. Стикеры в МАХ Сервис «Медицинский личный кабинет Мурманской области» Купер Почта России Арсенал услуг 71 Департамент животного мира Республики Марий Эл Защитники. Под крылом Архангела. Архангельская область Поддержка для СВОих в HCO Глолайм Школьное питание Я здесь живу - приложение Белгород. Рядом ВСК | Страховой Дом Открытка для учителя

ag_mos_ru_bot emiasinfo_bot rosgosstrakh_bot help_kursk_bot zags_murman_bot citizencardrt_bot k_vrachu_33_bot glifaidzen_bot sakhalin_ostrova65_bot myrecept_74_bot mfckirovbot mfcrespaltai_max_bot

The Fraudster Will Not Pass Kursk Region Resident Card Pochta Biznes Tver Oblast Events MFC of the Republic of Ingushetia MFC RSO-Alania Chatbot of regional services of the Kirov region

kgko_kursk_bot pochta_business_bot tverafisha_bot mfc_ingushetia_max_bot mfcrsoalania_max_bot gosuslugi43_kirov_bot

Plan B Ingosstrakh Pulse of Education Salebot Technical Support Stickers in MAX Medical Personal Cabinet of the Murmansk Region

bee_plan_b_bot ingos_bot sferumpuls_bot salebot_support_bot stickers mur_mlk51_bot

Kuper Pochta Rossii Arsenal of services 71 Department of Wildlife Management of the Mari El Republic

kuper_miniapp_bot pochtarus_bot arsenaluslug_bot depohot12_bot

Archangel of Spetsnaz

defenders_ao_bot

Support for Our Own in NSO GloLime School Meals I live here - the app Near Belgorod VSK Insurance House Teacher Day Card

svoi_nso_bot glolime_bot spb_mesto_bot belgorod_app_bot vsk_insurance_bot teacherday_bot

21