Checkpoint: Follow the Boundary, Not the Popup
The web attacks examined so far look different on the surface: one places a credential in an attacker-controlled field, while another offers the wrong site's credential to a user. They become easier to judge when viewed through one Android Autofill Framework chain: browser representation, password-manager decision, final browser write, and the user's awareness of the context. The useful judgment is to locate the point where context or control was lost, then distinguish a direct secret exposure from a misleading suggestion or a concealed trust boundary.
This model also prepares a broader question. If the autofill path can reveal more than it should to a web frame, can it reveal something sensitive to a native app before any password is released? Before turning to that app-based case, the web findings can be consolidated into a small set of failure points.
One chain, several ways to break it
A safe autofill decision needs the browser to represent the relevant web context, the password manager to interpret that representation conservatively, and the browser to restrict the returned response when it writes values. A user-facing warning adds a fourth condition: even a credential matched to the correct embedded document may need to be identified as occurring inside a cross-site context.
The first break is omission. A browser may leave out a child document's webDomain, collapse part of the frame ancestry, omit the port, or fail to signal that a frame is sandboxed or credentialless. The password manager then receives a request in which the field exists but its security meaning is incomplete. Omission does not yet tell us the final impact, but it creates the conditions for the next break.
The second break is misinterpretation. A password manager can treat the first domain it sees as authoritative for the whole structure, flatten nodes that should remain separated, or fill every field associated with a matching domain. The service is not necessarily making a random choice. It is applying a rule to a representation that does not contain the distinctions the rule needs. A deterministic heuristic can therefore produce an unsafe result consistently, while an unstable structure can make the result change with node order or browser behavior.
The third break is missing validation. The browser still owns the actual DOM and knows which fields are focused, related, and inside the relevant context. If it accepts any field assignment returned by the service, an over-broad response can become a cross-context write. This is why password-manager matching and browser injection cannot be evaluated as one step. Matching chooses a possible credential; injection decides where the secret actually goes.
The fourth break is missing awareness. A credential may be placed into the correct site's field, yet the field may be inside a cross-site embedded document. If the password manager gives no warning, the user sees a successful fill without seeing the surrounding trust relationship. In that case the immediate destination can be correct while the interaction still violates the isolation assumptions that protect embedded contexts.