Maginot Line: Assessing a New Cross-app Threat to PII-as-Factor Authentication in Chinese Mobile Apps

Maginot Line: Assessing a New Cross-app Threat to PII-as-Factor Authentication in Chinese Mobile Apps

Speakers: Fannv He

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=zTCr0puuMxc

Overview

In the rapidly evolving landscape of mobile application security, especially within the vast Chinese digital ecosystem, the reliance on Personally Identifiable Information (PII) as an authentication factor has become increasingly prevalent. This talk, "Maginot Line: Assessing a New Cross-app Threat to PII-as-Factor Authentication in Chinese Mobile Apps," presented by Fannv He, sheds light on a critical, yet previously under-explored, vulnerability stemming from the interconnected nature of mobile applications. The research introduces PII-as-Factor Authentication (PaFA), a method where sensitive personal data like national ID numbers or bank card numbers are used to verify user identity, often for password recovery or sensitive transactions. While ostensibly designed to enhance security, the study reveals that the simultaneous usage and business interactions between multiple apps can inadvertently create systemic weaknesses, making PaFA less secure than intended.

The core contribution of this work is the identification and systematic analysis of a novel threat termed Bypass Authentication by Cross App Exploitation (Bacae attack). This attack allows an adversary, starting with a limited authentication factor—most notably, just an SMS One-Time Password (OTP)—to exploit less secure applications to harvest additional PII or abuse cross-app authorization mechanisms. This collected information is then leveraged to bypass the ostensibly stronger PaFA of a target application, leading to severe consequences such as account hijacking, unauthorized purchases, and fraudulent loans. To systematically investigate this complex problem, the researchers developed a semi-automatic system named MAGGIE. Their extensive measurement study, involving 234 real-world Chinese mobile apps, exposed a startling reality: 75.4% of apps deploying PaFA are susceptible to Bacae attacks, including highly sensitive platforms like Alipay, WeChat, and UnionPay. This research provides crucial insights for developers, security professionals, and users into the hidden dangers of an interconnected mobile app environment, highlighting the urgent need for a more holistic approach to authentication security.

Background

▶ Watch: Introduction to PII-as-Factor and Bacae attack (0:00)

Mobile application security is foundational to protecting user data and digital identities. In the Chinese market, with over a billion smartphone users engaging with an average of 73 apps daily, robust authentication mechanisms are paramount. Beyond traditional user-chosen passwords, SMS OTPs have gained widespread adoption for their convenience in both login and password recovery. However, SMS OTPs are notoriously vulnerable, susceptible to attacks such as SIM swaps, exploitation by malicious apps with READ_SMS permissions, or even direct purchase on underground markets. Recognizing these limitations, app vendors in China have increasingly adopted PII-as-Factor Authentication (PaFA), where personal information like national ID numbers, bank card numbers, full names, and birth dates serve as additional authentication factors, particularly for critical operations like payment password recovery or linking bank cards. Unlike traditional security questions, which can often be guessed or socially engineered, the PII used in Chinese PaFA is generally considered private and not publicly available, aiming for higher authentication strength.

Modern mobile applications are rarely isolated entities. They operate within a complex ecosystem involving intricate function logic, inter-app communication, and integrations with numerous third-party services. This includes mechanisms like Single Sign-On (SSO), which allows users to log into one app using credentials from another (e.g., Alipay via Taobao), and direct business authorizations where apps might delegate access or services to third-party providers, such as payment apps linking to bank accounts. Each of these interactions, while enhancing user convenience and functionality, introduces potential vectors for security degradation if not carefully managed.

The researchers' threat model assumes a victim, Alice, who is a typical smartphone user with many popular apps installed, all containing her real personal information. The attacker, Mallory, is assumed to initially possess only Alice's SMS OTP. This is a realistic assumption given the prevalence of mobile phone theft, loss, OTP fraud, and underground markets. Mallory's objective is to compromise or bypass the authentication mechanisms of a target app to achieve illegal goals, such as account hijacking, further PII gathering, unauthorized purchases, or even taking out loans in Alice's name. A critical aspect of this model is that Mallory does not need prior knowledge of all Alice's installed apps; popular apps are sufficient targets. The study also explicitly assumes no implementation-level vulnerabilities in the target apps themselves and treats vendor risk control mechanisms as a black box, with their partial impact discussed later.

Prior research has extensively explored various facets of mobile authentication security. Studies have highlighted the vulnerabilities of personal security questions for account recovery, demonstrating their susceptibility to guessing and social engineering. Other works have focused on password attacks, the effectiveness of multi-factor authentication, and biometric bypasses. Account recovery processes have also been shown to inadvertently leak private information. While privacy leakage detection in mobile apps is a well-researched area, this study distinguishes itself by focusing specifically on PII exposed on UI pages that an attacker can actively gather and leverage for authentication bypass, rather than PII passively collected or transmitted by apps. This unique focus on actively harvested UI-displayed PII within a cross-app context forms the foundation of the Bacae attack.

Key Findings

▶ Watch: Motivating case: UnionPay, AirChina, PICC attack (0:50)

The comprehensive study revealed a profound and widespread vulnerability in PaFA mechanisms across the Chinese mobile app ecosystem. The most striking finding is that 75.4% (49 out of 65) of apps that deploy PaFA are susceptible to Bacae attacks, meaning their authentication can be bypassed by an attacker starting with only an SMS OTP. This vulnerability extends to highly sensitive operations such as login, login password recovery, bank card connection, and even payment password recovery, impacting major platforms like Alipay, WeChat, and UnionPay.

The researchers identified two primary root causes contributing to the efficacy of Bacae attacks:

1. Ubiquitous PII in Apps: Mobile applications widely collect and store PII for various business functions, and critically, this PII is frequently displayed on UI pages. An attacker, starting with a weak authentication factor like an SMS OTP, can exploit this prevalence to harvest PII from less secure apps, then use this harvested data to break into stronger PaFA systems.

• Full Exposure: Many apps directly display complete PII on normal UI pages, accessible post-login. Examples include flight booking records in travel apps like Ctrip, order lists, personal centers, or even privacy data collection lists. PII can also be found in external files, such as PDFs generated by financial apps like Qianzhan.
• Risky Partial Exposure: A significant vulnerability arises from the inconsistent and often inadequate masking strategies employed by different apps. Attackers can meticulously stitch together partially masked PII from multiple sources to reconstruct complete sensitive information. For instance, combining a last name from Didibike with a given name from Anjuke can yield a full name. Similarly, different apps might expose different parts of an ID number—Airbnb showing the first 6 digits, MOMO the last 4, and Soul/Blued providing the birth date (which is embedded in the ID number)—allowing an attacker to reconstruct the full ID number. This inconsistency creates realistic and exploitable risks.
• Case Study (Figure 4): The research illustrated a complex attack chain. An attacker with only an SMS OTP could aim to transfer money from UnionPay and access QQ mail. The path involves logging into Agoda, Zhihu, and Bettas (all requiring only SMS OTP) to extract first name, last name, and the last four digits of an ID. Stitching these pieces yields the full name. Subsequently, logging into Umetrip (potentially also with SMS OTP and partial PII) provides the full ID number. With the full ID, the attacker can reset the Etax login password to obtain the victim's email, then use this to reset the QQ mail password. Simultaneously, logging into Pahealth (again, with SMS OTP) can yield the victim's bank card number. With the full name, ID number, and bank card number, the attacker can then reset UnionPay's payment password and initiate unauthorized money transfers. This intricate chain demonstrates how seemingly minor PII leaks, combined across multiple apps, can lead to a catastrophic compromise of a strongly protected target.

1. Cross-App Business Partnerships: The convenience offered by inter-app connections, while beneficial for users, can significantly downgrade security if not properly secured.

• Account Sharing (SSO): Single Sign-On, where one app's account can be used to log into another, can introduce vulnerabilities. If the SSO provider (e.g., Taobao for Alipay) has weaker authentication requirements than the connected app, an attacker can bypass the stronger app's security by compromising the SSO provider. Furthermore, inconsistent PII masking across SSO-connected apps (e.g., Alipay masking an ID number while Qunar fully displays it, even when connected via SSO) creates exploitable avenues for PII harvesting.
• Business Authorization: Apps often authorize third-party vendors to provide services. If a bank authorizes a third-party payment app (e.g., UnionPay, BestPay) with weaker authentication requirements, an attacker can exploit this delegated trust. A common service in China, "Add without entering card number," allows linking bank cards using only an ID number, full name, and SMS OTP. The researchers successfully performed a Bacae attack on one of the authors' bank cards using this method, demonstrating a real-world exploit.
• Case Study (Figure 4, Alipay Hijack): Another illustrative attack path for hijacking Alipay involved an attacker with an SMS OTP. They log into Bettas (requiring only SMS OTP) to obtain the last four digits of an ID. Using this partial PII along with the SMS OTP, they then log into Taobao. Finally, leveraging Taobao's SSO functionality, they gain unauthorized access to Alipay, bypassing its potentially stronger direct authentication.

Statistic Results:

The study's quantitative analysis provided critical insights:

• PaFA Deployment: 65 out of 234 apps (27.8%) deployed PaFA, predominantly in sensitive categories like payment, lending, and shopping. PaFA was used for various critical operations: login (20 apps), login password recovery (29 apps), bank card connection (30 apps), and payment password recovery (27 apps). The type of PII required varied, with login recovery often using easier-to-obtain PII (e.g., ID digits), while payment recovery demanded more complex PII (full ID, bank card number).
• Business Connection: A substantial 172 apps allowed SSO, with mainstream providers (WeChat, QQ, Alipay, Taobao) supporting 95% of these. Alarmingly, 12 apps' login conditions were effectively weakened by their third-party SSO integrations. Furthermore, 38 third-party payment apps were identified as potential key nodes in attack paths due to their PII handling and authorization mechanisms.
• PII Availability: A staggering 224 apps (95.7%) displayed PII on their UI pages, with 86.3% showing complete PII. Nearly half of the apps fully exposed PII such as phone numbers and full names. Inconsistent masking was rampant, allowing for the PII stitching attacks. Different app categories predictably exposed different types of PII (e.g., social apps revealing names/birthdays, financial apps exposing bank card numbers). A further 193 apps displayed additional PII post-login, expanding the attacker's harvesting opportunities.
• Attack Paths: MAGGIE discovered 3,437 optimized attack paths. The 75.4% vulnerability rate for PaFA-deploying apps highlights the systemic nature of the threat. Even biometric authentication methods like FaceID were found to be bypassable in certain scenarios through these multi-app exploitation chains.

Dissecting Attackers without SMS OTP: The analysis also extended to scenarios where the attacker lacked an SMS OTP. Even in these cases, PaFA remained vulnerable. For example, with only an email verification code, an attacker could compromise login authentication for two apps. If an attacker initially obtained only partial PII (e.g., ID and bank card numbers), they could compromise several apps (e.g., Vipshop, Shengbei) to gain full PII and then reset phone numbers for other apps, demonstrating the cascading nature of these vulnerabilities.

Impact: The consequences of Bacae attacks are severe, ranging from account hijacking and unauthorized purchases to fraudulent activities like applying for loans in the victim's name. The researchers successfully demonstrated Proof-of-Concept (PoC) attacks on their own accounts. A user survey involving 208 participants further underscored the practical implications, revealing that 94.2% of users had at least one attack path within their simultaneously used applications, confirming the widespread susceptibility of real users.

Technical Deep Dive

▶ Watch: Assumptions of the attacker and victim (threat model) (2:20)

The core technical challenge addressed by this research is the systematic identification of how an attacker, starting with limited authentication factors (e.g., only an SMS OTP), can exploit the complex interconnectedness of mobile applications to bypass the PaFA of a target app. Given the vast number of apps and the astronomical number of possible operation sequences, a brute-force approach is infeasible. The researchers ingeniously modeled the combined usage process of multiple apps as a state transition system and leveraged model checking techniques to efficiently discover attack paths.

The process begins by identifying "weak authentication apps" that an attacker can easily access with their initial limited factors. These apps serve as initial points to obtain "seed PII." This seed PII then triggers a snowball effect, where the newly acquired PII is used to access other apps, gathering more PII, until the attacker either achieves their goal (bypassing the target app's PaFA) or exhausts all relevant apps. Crucially, the system explicitly models cross-app authorization rules, recognizing that these delegated relationships can significantly weaken authentication strength.

To achieve this, the researchers designed and implemented MAGGIE, a semi-automatic system (Figure 3). MAGGIE operates as an adversary, starting with incomplete authentication factors, to interact with apps and determine if a target app's authentication can be weakened. It comprises three core modules:

1. XHelper: An auxiliary tool responsible for exploring app UIs, gathering available PII, and assisting a human analyst in extracting authentication requirements.
2. Model Builder: This module generates the formal state machine model, specified in the NuSMV language, based on the metadata collected by XHelper.
3. Model Checker: The off-the-shelf NuSMV model checker analyzes the generated model against a defined security property. It outputs counter-examples, which represent the concrete attack paths, subsequently verified manually.

A critical component of MAGGIE is the Authentication&Reward (AuthR) metadata. AuthR is a 4-tuple that comprehensively describes the authentication requirements for an app operation and the PII that can be obtained upon successful authentication. Its format is: AuthR ::= (App.Op, Cond, Authorz, Reward).

• App.Op refers to specific operations within an app requiring authentication (e.g., login, payment, bank card connection).
• Cond is the set of authentication factors required for App.Op's successful authentication, including factors for any pre-operations (e.g., payment Cond includes login password).
• Authorz records third-party operations with delegated authorization relationships (e.g., Taobao's SSO allowing login to Alipay).
• Reward is the set of PII obtained from the app after completing App.Op's authentication (e.g., a connected bank card number from PICC).

While Cond and Authorz often require manual collection due to anti-automation mechanisms like captchas and security keyboards, Reward extraction is more complex, as PII can be displayed in various formats, partially obscured, or even derived from third parties. XHelper automates the traversal of app pages to find potential PII leaks.

Implementation Details

XHelper is designed to automatically traverse app UIs and gather displayed PII. It consists of two main components:

1. Depth-first UI exploration (Algorithm 1): XHelper launches the app from its MainActivity and performs a depth-first exploration of all clickable widgets. A page_stack maintains the exploration state. To prevent infinite loops and improve efficiency, a Page Repository stores visited UI pages, and a Tree Matching algorithm compares the structure and content of new pages with existing ones. If a new page is highly similar, it's popped out without further exploration. The maximum stack depth was empirically set to 4, as deeper exploration yielded diminishing returns for PII detection while dramatically increasing test duration. A blocklist for widgets like "Logout" and prioritization for "Personal center" guide the exploration.
2. Matching PII: Before XHelper runs, a tester (acting as Alice) manually sets up account information. XHelper then collects widget texts from UI pages, applies 24 regular expressions to filter potential PII into 9 types (e.g., ID number, bank card number, full name). These suspected PII are then byte-by-byte matched against the tester's stored ground truth information. The PII classification is tailored to the Chinese app ecosystem, where an ID number serves multiple purposes.

Formal Modeling with Model Builder: The Model Builder generates the NuSMV model by representing the combined usage process as a state machine M = (S, O, T, s0, ss).

• S is the set of states. s0 is the initial state where the attacker possesses only inadequate authentication factors. ss is the SUCCESS state where the attacker achieves their goals.
• O is a finite set of operations on apps.
• T is a transition function. A state sj is defined by sj = (FV, app.op), where FV is the set of authentication factors known by the attacker, and app.op is the last operation performed. An operation app.op causes a state transition if the attacker's FV satisfies the Cond of AuthR for app.op, or if a third-party operation in AuthR.Authorz is satisfied. Upon successful operation, the attacker's FV is updated by AuthR.Reward.

To optimize model efficiency, several strategies were implemented:

• AppCluster: Apps with identical AuthR.Cond and AuthR.Reward are merged into a single AppCluster, reducing the number of nodes in the model.
• Path Pruning: Insignificant authentication options and redundant paths (e.g., if one login option's factors are a superset of another, the weaker one is pruned) are removed.
• Meaningless State Transitions: Transitions where the Reward is a subset of the Cond (i.e., no new PII is gained) are removed.

Detecting Security Flaws with a Model Checker: With the generated model, NuSMV is used to detect security flaws. An Access path (Def. 4) is defined as an ordered sequence of operations (op1, op2, ..., opn) that leads from an initial state si to a target state sj, effectively expanding the attacker's authentication factors. The core Security property (Def. 5), expressed in Computation Tree Logic (CTL) as AG ((A.FV AuthRt.Cond) AuthRt.Cond), states that for a given target operation AuthRt.app.op and an attacker A with initial FV, there should be no access path from the initial state s0 that allows the attacker to expand their FV sufficiently to pass the authentication conditions of the target operation and perform the sensitive operation. If NuSMV finds such a path, it's a counter-example, termed an attack path. The system also performs attack path optimization to filter out redundant transitions that do not contribute to expanding the attacker's knowledge for the target or subsequent authentication conditions.

For implementation, the Python library uiautomator2 was used to interact with app UIs. NuSMV was deployed on an Ubuntu 18.04 VM with an 8-core CPU and 16GB RAM, and custom scripts automated the process, taking approximately 8 hours to complete all tasks for the dataset.

Evaluation of XHelper: XHelper's accuracy was assessed by manually analyzing 78 apps (two from each of 39 categories) for PII, serving as ground truth (362 instances of PII identified in 83 man-hours). XHelper achieved 100% precision and 87.6% recall (317 out of 362). The 45 missed PIIs were primarily attributed to UIAutomator's limitations with WebView pages, the exploration depth limit, long loading times, and PII located at the bottom of overlong pages.

The motivating example (Figure 1) perfectly illustrates MAGGIE's workflow. The adversary starts with only SMS OTP (s0 = sms, null). The target is UnionPay.pay. XHelper extracts AuthRs from AirChina, PICC, and UnionPay. The Model Builder generates the state machine. The Model Checker then finds an attack path: T(s0, AirChina.login, PICC.login, UnionPay.LPwdRecovery) = sj, where sj = (sms, fn, id, bcn, UnionPay.pay). This path demonstrates that an attacker, knowing only SMS OTP, can bypass UnionPay's payment authentication by first logging into AirChina and PICC to gather the full name, ID number, and bank card number.

Demo / Proof of Concept

▶ Watch: Technical approach: state transition systems and model checking (4:10)

The research extensively incorporates real-world demonstrations and case studies that function as compelling Proofs of Concept (PoCs) for the Bacae attack. While no live demo recording was explicitly described as part of the article's scope, the detailed attack scenarios presented in the "Key Findings" section serve this purpose.

For instance, the complex chain illustrated in Figure 4 (Case Study: UnionPay money transfer and QQ mail access) meticulously outlines how an attacker, starting with just an SMS OTP, can sequentially compromise apps like Agoda, Zhihu, Bettas, Umetrip, Etax, and Pahealth to harvest a full name, ID number, email, and bank card number. This collective PII then enables the attacker to reset the UnionPay payment password and initiate unauthorized money transfers, as well as gain access to QQ mail. This is a clear demonstration of how the PII stitching and cross-app exploitation mechanism works in practice.

Similarly, the Alipay hijack scenario (Figure 4, Case Study: Alipay Hijack) provides another concrete PoC. Here, an attacker uses an SMS OTP to log into Bettas to obtain the last four digits of an ID. This partial PII, combined with the SMS OTP, allows access to Taobao, which then facilitates an SSO-based login into Alipay, circumventing Alipay's stronger direct authentication requirements.

Furthermore, the researchers explicitly stated that they successfully demonstrated PoC attacks on their own accounts, including compromising one of the authors' bank cards using the "Add without entering card number" service. This direct, real-world validation underscores the practical feasibility and severe impact of the Bacae attack, moving it beyond theoretical possibility to a confirmed threat. These demonstrations highlight that the identified vulnerabilities are not merely theoretical constructs but represent actionable attack vectors against popular and critical financial and personal applications.

Defensive Implications

▶ Watch: Introduction to MAGGIE system design and architecture (6:00)

The findings of this research present critical defensive implications for various stakeholders in the mobile app ecosystem: app developers, users, and even regulators. The pervasive nature of Bacae attacks, where SMS OTP often becomes the single point of failure, necessitates a paradigm shift in how authentication security is approached.

For App Developers:

1. Rethink SMS OTP Reliance: Developers must recognize that SMS OTP, while convenient, is a weak authentication factor and should not be considered the sole or primary protection, especially for sensitive operations. PaFA, when implemented in isolation, provides limited benefits against cross-app threats.
2. Implement Strong, Mandatory Multi-Factor Authentication (MFA): Biometric authentication (e.g., FaceID, fingerprint) is recommended as a stronger factor. However, it must be mandatory for sensitive operations, not merely optional. If users can bypass biometrics, its security benefits are diminished.
3. Standardize PII Masking Consistently: A critical vulnerability lies in inconsistent PII masking. Developers must implement uniform and robust masking strategies across all UI pages, including order lists, personal centers, and privacy settings. This consistency must extend to affiliated services, such as linked websites and services accessed via SSO or third-party authorizations. Partial PII exposure, even if seemingly minor, can be stitched together by attackers.
4. Adopt a Cross-App Security Posture: Authentication strength should not be assessed in isolation. Developers must consider the broader app ecosystem and how their app's authentication mechanisms interact with other applications that a user might have installed. This requires a holistic view of potential PII leakage and authorization delegations.
5. Scrutinize Cross-App Authorization Mechanisms: SSO and other third-party authorization relationships must be meticulously evaluated. If an SSO provider or an authorized third-party service has weaker authentication requirements or displays more PII, it effectively downgrades the security of the connected app. Developers should demand and enforce consistent security standards across all business partners.
6. Enhance Risk Control Mechanisms: While some apps implement risk control (e.g., requiring additional authentication for new devices or IP addresses), the study showed that many were still vulnerable. Risk control systems need to be more sophisticated, considering behavioral anomalies, and ideally, be resilient to common bypass techniques. Their effectiveness should be regularly audited and tested against cross-app attack vectors.

For Users:

1. Be Wary of Minimal Authentication: Users should be cautious of apps that require minimal authentication (e.g., only SMS OTP) for access to sensitive PII.
2. Enable and Mandate Biometrics: Where available, users should enable biometric authentication and, if given the option, make it mandatory for critical operations.
3. Use Strong, Unique Passwords: Traditional advice remains crucial. Strong, unique passwords for high-value accounts can mitigate some risks, although the Bacae attack primarily targets PaFA.
4. Protect Your Phone Number: Given that SMS OTP is often the initial entry point, users must be vigilant against SIM swap attacks, phone theft, and malicious apps that can intercept SMS messages.
5. Limit PII Disclosure: While often unavoidable, users should be mindful of the PII they provide to apps and only share necessary information.

For Ecosystem Owners and Regulators:

1. Mandate Consistent Security Standards: App store operators and regulatory bodies should mandate consistent security standards for PaFA and PII handling across all applications, especially those that integrate or share data.
2. Encourage Cross-Vendor Collaboration: Addressing cross-app threats requires industry-wide collaboration. Platforms and regulatory bodies should foster environments where vendors share threat intelligence and work together to establish stronger, unified security protocols.

The "Maginot Line" analogy aptly describes the situation: strong, isolated defenses (PaFA) are rendered ineffective when the broader, interconnected landscape allows attackers to simply bypass them. A multi-layered, ecosystem-aware defensive strategy is imperative.

Key Takeaways

• Bacae attacks are a novel and significant cross-app threat: This research introduces and systematically validates the Bypass Authentication by Cross App Exploitation (Bacae) attack, demonstrating how an attacker can leverage limited initial factors (like an SMS OTP) to harvest PII and abuse cross-app authorizations to bypass stronger PaFA in target applications.
• Widespread Vulnerability in Chinese Apps: A staggering 75.4% of PaFA-deploying apps among 234 popular Chinese mobile applications were found to be susceptible to Bacae attacks, including critical platforms like Alipay and UnionPay.
• Ubiquitous PII Exposure is a Primary Enabler: The widespread collection and display of PII on app UIs, coupled with inconsistent or partial masking strategies across different applications, allows attackers to stitch together fragments of PII to reconstruct complete sensitive information.
• Cross-App Business Partnerships Weaken Security: Single Sign-On (SSO) and other third-party business authorization mechanisms, while convenient, can significantly downgrade authentication strength if the connected services have weaker security postures or PII handling policies.
• SMS OTP is Often the Single Point of Failure: Despite the intention of PaFA to enhance security, the prevalence of Bacae attacks effectively makes SMS OTP the de facto single point of failure in many cases, highlighting its inherent vulnerabilities to SIM swaps and other attacks.
• A Holistic, Cross-App Perspective is Crucial: App developers and security professionals must shift from an isolated app security model to a holistic, ecosystem-aware approach that considers inter-app interactions, PII flows, and delegated authorizations to design truly robust authentication mechanisms.

About the Speaker(s)

The research was presented by Fannv He at the NDSS Symposium. The provided transcript and metadata do not offer further biographical details about Fannv He beyond their affiliation with this significant research.