From Lab Matrix to Live Web Conditions

The AutoFail study uses several kinds of evidence to answer different questions about Android Autofill Framework security. ADAPT's controlled tests ask what a browser and password manager actually exchange. The web measurements ask whether the embedding conditions required by some attacks appear outside the laboratory. The Kick, AOL, and Internet Archive demonstrations ask whether the mechanism can reach selected live configurations. Reading these layers separately lets readers judge the study's 450 tests and its headline percentages without turning either into a claim that every Android user or every site is exploitable.

That separation is especially important for this subject. A client-side flaw is necessary for an attack, but it is not sufficient. A site must also be frameable or contain the relevant kind of embedded content, an attacker must control the right resource, and the user's browser-manager combination must behave in the vulnerable way. The study's value is strongest when each piece of that chain is kept attached to the evidence that supports it.

What an end-to-end differential test can reveal

ADAPT stands for Android Differential Autofill Pipeline Testing. Its purpose is not merely to observe whether a password appeared in a field. It compares combinations of browsers and password managers while capturing the messages and state changes on both sides of the Android mediation layer. The authors can inspect the browser-generated virtual structure, the request received and processed by the password manager, the returned FillResponse, and the final injection into the browser.

That visibility changes the diagnosis. Suppose two combinations both show a credential in an unexpected field. A result-only test would group them together. An end-to-end test can ask whether one browser exposed fields from an excessive scope, whether one password manager ignored the hierarchy, or whether the browser accepted a response that should have been rejected during injection. Those causes imply different fixes and different expectations for other browser-manager pairings.

The study selected five browsers—Chrome, Samsung Browser, Phoenix Browser, Firefox, and Brave—and nine password managers after a Play Store-based selection process. Six additional apps were excluded because they interfered with the analysis or crashed. The final evaluation ran on a rooted Pixel 6a running Android 16, with a local server, Frida instrumentation, and an orchestrator that drove the test pages. A human analyst focused the field and selected the autofill result, because triggering and accepting the request reliably across varied mobile forms required interaction.

The test suite used ten scenarios across 45 browser-manager combinations, producing 450 tests. The scenarios began with a single-origin login form and then varied the boundaries that matter to autofill: cross-site child frames, fields in both parent and child contexts, recursive embedding, sandboxed and credentialless frames, non-standard ports, HTTP, an embedded object, and an iframe directly inside a form. This is not an exhaustive model of the web.