Island Password Manager — autofill behaviour tests
loading config…
Running over plain HTTP. Every test will trip Island's transport
warning first, which can mask the checks under test — this is what made the
2026-08-28 T3 result inconclusive. Re-run over HTTPS on real domains.
Save a vault credential for this origin first, then reload.
Watch whether Island auto-injects on page load, and separately what
happens when you click the credential in the popup (manual injection).
T1 — Baseline (same origin, visible fields)
Control case. Nothing insecure here.
Expected: autofill offered/injected normally.
On HTTPS there should be no warning at all.
watching…
T2 — Cross-origin iframe
The login form below is served from the peer origin, a different
origin from this page. The real-world version shows the victim's expected domain
in the address bar while the credential lands elsewhere.
Expected (per white paper): auto-injection
silently blocked. Manual injection should warn about the cross-origin
context specifically.
check the iframe's own readout
T3 — Hidden credential field (known defect 2026-08-28)
A visible form, plus an invisible password field positioned off-screen —
the classic covert-harvesting pattern.
Expected per white paper: visible fields filled;
hidden fields left empty (hidden fields "excluded" and selectors cleared). Observed on HTTP (2026-08-28): hidden fields were filled —
contradicts the documented behaviour. This re-test over HTTPS is the priority:
confirm whether the defect survives once the HTTP path is out of the way.
watching…
T4 — Break the detection, not the check
Hammers the DOM and the message channel to try to make the content-script
inspection error or time out. Combines a cross-origin iframe
and a hidden field with heavy interference.
Watching for: do the warnings still appear under
load? On 2026-08-28 they did — interference did not suppress them.
idle — press the button
T5 — Cross-fill isolation (new)
On 2026-08-28, filling T1 also populated the cross-origin iframes elsewhere on the
page. That could mean one approval covered the whole page, or that the foreign-origin
frame was filled without being separately gated — the outcome alone does not say which.
This test isolates it: a top-level form and a cross-origin iframe, nothing else.
Record: when you fill only the top-level
form, does the iframe below fill too? Is a separate cross-origin warning shown for it,
or does one approval cover both? Only valid if no vault credential is saved for the peer host. Island
matches autofill on the host component (D2), so an entry saved for the peer would make
it fill on its own merits and the result would mean nothing.