What the Browser's Autofill Tree Forgets
The Android Autofill Framework can protect a credential only if the browser's translated structure preserves the web facts that make a destination trustworthy. This chapter supplies those facts: what an origin is, how a site differs from an origin, why an iframe is a separate browsing context, and what sandbox and credentialless are meant to signal. With that model in place, readers can tell whether an autofill failure comes from a browser omission, a password-manager policy, or the combination of both.
The distinction matters because a password manager often wants a usable rule such as “offer credentials for this site.” The web's actual rules are more precise. A site-level relationship can support storage and usability decisions, but it does not erase the difference between two origins or between a top-level document and an embedded one. Autofill is safe only when the simplification retains the distinctions relevant to the secret being placed.
Origin, site, and browsing context are different boundaries
An origin is the exact combination of a URL's scheme, host, and port. Changing any one of those components produces a different origin. The scheme separates HTTP from HTTPS; the host identifies the domain; and the port identifies the network endpoint. The Same-Origin Policy uses this exact boundary to restrict how scripts from one origin interact with another page's resources and DOM.
A site is broader. It is based on the registrable domain, the portion of a name that identifies the domain available to an organization or service under the public suffix rules. Two subdomains can therefore belong to one site while remaining different origins. That broader relationship is useful for mechanisms that want to partition storage or make a usability decision across related subdomains. It is not a permission for one origin to read another origin's DOM, and it is not automatically precise enough for releasing a password.
The difference becomes visible with an iframe. An iframe creates a nested browsing context inside the parent page. The parent and child can be visually integrated, but the browser keeps their documents separate when their origins differ. A script in the parent does not gain unrestricted access to the child's DOM merely because the child is displayed inside the parent. The embedded document may also have a different site relationship from the top-level document.
That relationship has security meaning for autofill. A password field directly owned by a page and a visually identical field inside a cross-site frame may have the same HTML type and similar labels, but they are not the same destination. If the password manager receives only a field type and a broad domain hint, it may not be able to apply the boundary the browser normally enforces.
Two iframe features make the missing context still more consequential. A sandboxed iframe without allow-same-origin is assigned an opaque origin. The browser is deliberately saying that the embedded content should not be treated as having its ordinary origin for many security decisions. A Chromium credentialless iframe is an ephemeral context in which browser autofill and password-manager functionality are typically disabled. In both cases, the frame's state is a policy signal, not just another attribute of its layout.
The AF representation must therefore answer several separate questions: What exact origin owns this field? What broader site relationship does it have? Which documents are its ancestors? Is the field in an opaque or ephemeral context? Is the request secure, and does the port matter? Collapsing those questions into one webDomain value makes the password manager's job easier to implement but harder to make safe.
A concrete way to see the difference is to hold the registrable domain constant while changing one part of the origin. A page at https://account.example and a page at http://account.example may be associated with the same broader site name, but the scheme changes the origin and changes whether a network observer can read the request. Likewise, https://account.example:8443 is not the same origin as the default HTTPS port even though the host is unchanged. A site-level autofill rule may be convenient for related pages, but it must not silently become a rule that treats every scheme and port as interchangeable.
The ancestor chain adds another independent dimension. Suppose a field from one document is embedded inside a second document that is itself embedded in a third. The field's own origin does not tell the password manager whether the user reached it directly or through contexts controlled by other parties. Those ancestors can affect who can frame the document, whether the frame is visible, and whether the field is being used as part of a trusted login flow or an attacker-controlled container. Omitting an intermediate context can make two requests with the same focused origin look equivalent even though their trust paths are different.
Isolation flags also require a semantic response, not just a string. Adding allow-same-origin to a sandboxed frame restores the frame's initial origin, but it also removes one of the sandbox's main isolation effects. Combining it with script execution can make the frame substantially less isolated. A password manager that sees only a domain value cannot decide correctly if it cannot tell whether that value came from an ordinary frame, a frame with an opaque origin, or a frame whose developer deliberately restored its original origin. The browser's translation must preserve the condition under which the value is meaningful.
These distinctions explain why the security model cannot be reduced to “does the domain match?” A domain match is an input to a policy, not the policy itself. The service still needs to know which field was focused, which fields are its direct companions, and which contexts surround them. The browser also needs a way to reject a response that tries to reach beyond that scope. The more the message omits, the more the receiver must infer; the more the receiver infers, the more a browser-specific representation becomes a security dependency.
The diagram is not a claim that Android exposes each web concept as a separate class. It shows the relationships that a safe policy needs to preserve while the browser compresses web content into a virtual structure. WebOrigin and Site are different kinds of boundary; BrowsingContext supplies ancestry; IsolationState qualifies how a frame may be trusted; and the password manager consumes whatever survives the translation.
How the translation collapses those distinctions
The AutoFail study found no universal representation that makes every browser and password manager interpret web content in the same way. One failure is omission. In the study's cross-site iframe test, Phoenix and Brave transmitted child nodes without a useful webDomain, making the embedded case resemble a simple single-origin form. Samsung Browser could omit domain information from form-field nodes and leave only a top-level domain on another node. A service that sees a domain somewhere in the structure may therefore attribute the wrong domain to the focused field.
Another failure is hierarchy. A browser can transmit the right field values but arrange them so that the password manager cannot tell which document contains which field. Firefox's tested structure could flatten fields from different contexts and vary their order. Chrome could preserve the outermost and innermost documents while collapsing an intermediate chain. Other browsers could expose only the top-level document in cases where the child context was the important one. These are not interchangeable representations of the same tree: each leaves the service with a different amount of evidence about the trust path.
The missing port is a different kind of loss. A password manager may be able to distinguish HTTPS from HTTP if the scheme is present, yet it cannot apply an exact origin rule if the port is unavailable. A same-site page served on a different port can then look equivalent at the autofill boundary even though the web's origin definition treats it as different. The study also found password managers that silently offered credentials on HTTP pages when the browser had triggered the request. Here the browser and the service disagree about how much warning an insecure scheme requires.
Opaque origins show how a value can be present and still be unsafe. Chrome represented a sandboxed child with the string null. That string is meant to stand for an opaque origin, but a password manager can mistakenly treat it as an ordinary domain value or use it as a shared bucket. LastPass, according to the study, ignored the opaque indication and fell back to the parent's domain. Other managers treated the sandboxed form like a normal embedded form. The problem is not only that a flag was omitted; it is that the receiving component may assign the wrong meaning to the replacement value.
The credentialless case is more direct. The attribute is intended to create an ephemeral context, but all browsers tested in the study ignored it when translating the DOM for autofill. The password manager consequently had no indication that the frame should be excluded from stored-credential behavior. The measured websites contained no credentialless iframe, so the study does not establish broad real-world use of the feature. It does establish the design risk: a security restriction that disappears before the policy decision cannot protect the field.
The password manager then becomes a second source of variation. A restrictive matcher might use the focused node and its immediate siblings. A weak matcher might flatten the whole structure and select the first non-null domain it encounters. In the study's analysis of Bitwarden's behavior on Firefox's inconsistent structure, the first-domain approach could make the suggested credential depend on node ordering. Other affected password managers showed similarly unpredictable behavior. An indiscriminate filler may go further and apply a response to every field in the structure when one domain value happens to match a stored credential.
This is why the cause cannot be assigned by looking only at the browser or only at the password manager. A browser omission creates an opportunity, but the impact depends on what the receiving service does with the omission. A password manager's heuristic may be weak, but a better structure could prevent it from seeing unrelated fields. A browser-side injection check can contain a bad response in some cases, while its absence lets an over-broad response become a secret-bearing write. The study describes these as browser and PWM flaws whose intersections produce the security issues.
The abstraction boundary is therefore asymmetric. The browser knows more than it transmits. The password manager decides with less than it needs. Android faithfully mediates the message without supplying the missing web meaning. None of those statements implies that ordinary web isolation has vanished. It means the autofill path has introduced a second decision path that does not automatically inherit the browser's full security model.
A useful diagnostic is to ask four questions in order. What exact origin owns the focused field? What is the field's ancestor chain? Does any isolation state make the context opaque or temporary? Finally, does the password manager's response target only the fields that the user intended to authorize? If the first three answers are unavailable, matching is guesswork. If the fourth is unchecked, even a reasonable match can be written too broadly.
The next step is to follow that ambiguity into an attack. The important change will not be that a malicious script suddenly defeats the Same-Origin Policy. It will be that autofill treats a field in one web context as if it belonged to another, or offers a credential for the wrong destination. The resulting difference between a misplaced suggestion and an actual cross-site write is where the boundary failure becomes a concrete security impact.