Same look. Different destination.: sources & model
Peel a familiar-looking message away from its destination. Take apart real URL structure, compare passwords, codes and passkeys, and discover why checking through a known route changes the evidence.
The source and model records are available for inspection. No external scientific reviewer has signed off yet.
account-security-1 · content 1 · setup format 1
What supports the explanation?
Different authentication methods have different phishing boundaries
NIST distinguishes verifier-bound cryptographic authentication from manually entered passwords and OTPs. This supplies the mechanism distinction, not a success-rate estimate.
Related origins are an explicit exception outside the base model
Level 3 Candidate Recommendation, May 26, 2026, includes related-origin request mechanisms. Do not interpret the base example as an absolute rule across all supported configurations.
HTTPS does not establish the honesty of the endpoint
The Chromium team’s 2023 lock-icon design explanation addresses this distinction. The historical UI is not copied or presented as every current browser.
This is a closed fictional environment. Reserved addresses stay inert; no real account, password, code, message or passkey prompt is used.
A parsed hostname is an observation about syntax, not proof of ownership, honesty or an uncompromised device.
Enrollment, form action, HTTPS, RP scope and the service’s allowed origins are explicit story conditions. Real systems can have redirects, federated sign-in and multiple legitimate origins.
The fixed suffix comparison is not a general public-suffix validator. Related-origin requests, embedded cross-origin flows and native apps are outside this model.
All proof and service checks are simulated. No signature is computed, no attack probability is estimated, and playback seconds are not measured network latency.
Authentication does not secure every recovery path, session or later action. An accepted modeled sign-in is not a blanket safety guarantee.
Independent security-educator review and learner trials are pending. The exercise does not certify anyone’s ability to detect scams.
Hostname and origin are different: For ordinary HTTP(S), an origin combines scheme, host and port. The same hostname with port 8443 is a different origin from default HTTPS. A path change normally does not change that origin.
Parsing is not reputation: We compare full hostnames against fixed fictional examples. Taking only the last two labels is not a universal registration rule: public suffixes vary. The parser’s normalized output can also differ from the original spelling.
Credentials have a scope: Our fixed RP ID is club.example. The browser permits this registered parent-domain request from club.example or an eligible subdomain, with HTTPS required here. Newer related-origin mechanisms exist; this base model omits them.
The service performs separate checks: An eligible request is not automatic acceptance. The service checks its allowed origin, the expected challenge and the signature, among other requirements. Our gates show a selected subset as explicit booleans, not a conforming WebAuthn implementation.
A fingerprint is not the passkey: A local PIN or biometric check can authorize use of a credential. The website receives public-key evidence, not a fingerprint image. Our main view shows a device-bound example; synced passkeys can be available through a credential manager on other devices.
Why codes still help, and where they differ: The password-only comparison assumes the other factor remains unavailable. That can stop sign-in with an exposed password. A manually entered code can still be handed to an impostor and relayed while valid; different MFA methods should not be treated as one mechanism.
The page can submit elsewhere: A real form’s action determines its submission destination. Our exercise deliberately fixes it to the displayed page origin. It does not teach that every form submits only to the address shown in the bar.
Interface cues need evidence too: A 2019 field experiment and surveys found little benefit from the particular identity-indicator changes tested. This was not a trial of Brytalearn or children’s learning. Highlighting a domain cannot guarantee that a learner will identify every attack.
What has been checked
Analytical reference cases, conservation or transition invariants, finite drawing commands, bounded setup parsing, discovery and route integrity are checked automatically. These checks do not establish anatomical fidelity, learner outcomes or browser/device compatibility. Independent subject review, learner trials, comprehensive accessibility review and browser video encoding checks remain pending.
Each source supports the associated claim. Sources do not certify this implementation or its visuals.
About the cover illustration
Actual browser-rendered frame of the lesson’s original illustrative phone, laptop and separated page layer. The fixed fictional destination is inert. This is original teaching hardware and UI artwork, not a commercial device teardown or real account screen.