Jumping to another domain is a trust transfer; high-risk cases need a second confirm

What it is

Opening another domain hands the next inputs, cookies, and the judgment “is this still the company I was with” to a new principal. Trust transfer: in banking, government, health, payment hops, misreading the domain hands credentials to a lookalike. High-risk cases put a second confirm before the jump that lights up the target hostname, so someone can decide whether they still trust this hop. An encyclopedia outbound link on an ordinary content site does not need this layer; marking it external is enough.

Why it happens

People use the current page’s brand and lock icon as a trust proxy and rarely read the address bar. Phishing pages rely on that proxy not yet being taken off: a hop from a bank-like email still looks like the bank at first glance. An interstitial that writes “you will go to payee.example” as a readable hostname cuts the proxy and forces an explicit handoff. Leave-site interstitials at banks and payment institutions, and outbound confirms on some government sites, are about that handoff, not politeness.

The confirm must show the hostname that will actually open, not merely “an external website.” Short links, redirectors, and in-app WebViews hide the final domain behind a 302; if the confirm shows the redirector’s own domain, the handoff is fake. High-risk is judged by what is happening in the current product (a transfer in progress, a medical record being submitted), not by the destination’s PageRank. A hop from a high-risk page to a known partner payment domain still deserves a confirm—partner domains are spoofed too; the hostname is the line people are asked to check.

Studying it

On a simulated bank or medical-record page, place two outbound links: a real partner domain and a spoof. Compare an external icon only, a confirm that shows the hostname, and a “leave this site?” that does not.

• Dependent variables: rate at which the spoof is clicked through, rate at which the partner is abandoned for no reason, whether people read the hostname aloud.
• Independent variables: whether the final hostname is shown, whether the current page is in a high-risk task.
• Methodological note: a clumsy lab spoof that everyone spots yields “no confirm needed.” Use a stimulus that looks like the real site and lies only in the hostname. Do not run this leaf on a content farm; false positives will explode and the conclusion will become “every outbound needs a confirm.”

Where it stops holding

Low-risk content browsing (a news citation, a paper link in docs) plus a confirm produces numbness and also dismisses the real high-risk confirm. A leave the user typed into the address bar is not a product-initiated jump and should not insert a confirm. When an app opens outbound links in the system browser, the system address bar already does the check and the product confirm can be lighter; an embedded WebView must show the hostname itself, because system chrome is hidden.

Applying it

• Confirm outbound links only in high-risk task contexts (money, health, identity, government submit), showing the resolved final hostname.
• Expand redirectors before confirming; do not confirm the short-link domain.
• A partner allowlist may reduce friction (one fewer button), but the hostname should remain visible; do not make the allowlist fully silent.
• Verify: on a transfer page, place a spoofed payment link whose hostname differs by one letter. Someone uninvolved should read that letter-off name on the confirm and stop. The same link in a blog post should not raise the same confirm. Copy that only says “leave this site” with no hostname fails.

Related

• Within the group: G4.08.1 External links must look different from in-site links so the jump can be predicted · G4.08.2 Leaving with unsaved changes must intercept, not silently discard · G4.08.4 Leave prompts only where data would actually be lost; overuse numbs people · G4.08.5 Outbound jumps may send referrer data; sensitive cases must disclose or block
• Adjacent: H4.01 Timing of requests · G4.04 New window versus in-place navigation · H3.05 Overuse of confirm dialogs
• Search terms: trust transfer · leave-site interstitial · outbound confirm