Two characters put 20 lookalike domains past Chromium's checks: a 29-letter list and an 8,462-domain list

Two characters, 20 domains, and a defence that is two lists

Have I Been Squatted registered 20 lookalike domains, all in .com, using two characters. The Cyrillic letter U+04E9 (CYRILLIC SMALL LETTER BARRED O, which looks like a Latin o or e) is in 15 of them, and the Latin letter U+0199 (LATIN SMALL LETTER K WITH HOOK, which looks like a Latin k) is in the other 5 (counts derived from the 20 names the researchers list). Their write-up of 3 October 2026 shows Chrome 154 displaying one of the Cyrillic names in Unicode, with a valid certificate, as if it were a famous brand's genuine address. It works because Chromium's two lookalike defences are lists. One is a list of 29 Cyrillic letters, and it blocks a Cyrillic label only if every letter in the label is on it. The other is a list of 8,462 popular domains, and a lookalike has to match one of them. A letter that is not on the first list, or a brand that is not on the second, is not tested. Both counts were made by this briefing from Chromium's source files as read on 10 October 2026.

"Two characters" is the size of the demonstration, not the size of the gap. The researchers' own table names three Cyrillic letters that pass today (U+04AF, U+04E9 and U+0457), and says that 64 lowercase Cyrillic letters in Chromium's allowed set are not on the 29-letter list. This briefing reproduced the 64 from the Unicode 17.0.0 data files and the list in the source (derived). It does not follow that 64 letters are usable: the researchers' third test, that the letter looks like a Latin one to a reader, is a judgement, and they name five letters that met it.

What that does not establish matters as much as the count. No source read reports any use of these characters in an attack, and none says there has been none. No statement from Google or Microsoft was found, and no fix for these characters: in the source as read on 10 October, and unchanged on a re-read at 20:30 BST, the three Cyrillic letters are still off the list. Nothing read says whether Firefox or Safari show these labels as Unicode, because the researchers did not test them. The researchers did not measure Safe Browsing, spam filtering or link scanning against the 20 domains. No victim count exists. And the write-up is a vendor's: Have I Been Squatted sells lookalike-domain detection and takedown, and its post ends with an offer of a free trial. Its figures are checkable, and the ones used here were checked.

What the count does show is where the control sits. A list of known-bad letters fails open: it allows whatever it has not been told to block. A list of popular brands protects the brands on it and no others. Every UK bank, retailer, council and public service that is not on the 8,462 gets no help from the list at that stage. This briefing read the list, so it can say what is on it: 71 entries end in .uk, four of them in .gov.uk and two in .nhs.uk, and none ends in .ac.uk or .org.uk (counted). The control that does not depend on anyone's eyes is a password manager or passkey that checks the exact origin, and the last section turns that into an ordered list.

The five gates: where each character gets through

The researchers split Chromium's per-label function, SafeToDisplayAsUnicode, into seven checks, and the Register repeats "seven". Chromium's own document lists thirteen steps for the whole decision, and the types file in the source defines ten result codes, eight of them reasons to show Punycode (counted by this briefing). The number depends on where the cut is made. The diagram below uses five gates, the ones that matter for these two characters, and each statement in it was checked against the source or a published table.

Gate by gate, with what the source says:

• The registry. Verisign's published .com tables list U+04E9 in the Cyrillic table (version 1.2, effective 25 October 2014) and U+0199 in the Latin table (version 2.6, effective 4 March 2020). Both tables are as listed by IANA on 10 October 2026.
• Allowed set and script mixing. The label has to use allowed characters and one script, and some letters are accepted only under some top-level domains. A label written entirely in Cyrillic, or entirely in Latin, with allowed letters, passes.
• The whole-script rule. For 17 scripts the source holds a list of letters that look like Latin ones. If every letter of a single-script label belongs to the list, the label is shown as Punycode, unless the top-level domain suits the script (for Cyrillic: bg, by, kz, pyc, ru, su, ua and uz, or any TLD containing a Cyrillic letter) or the label is one of 12 allowed words. The check uses a set-containment test, so one letter off the list ends it. A comment in the source says ICU's own whole-script check has been a no-op for a single string since ICU 58.1, and Chromium's check is its own list.
• The skeleton check. Chromium removes accents, applies its own extra mapping and then ICU's UTS #39 mapping, and compares the result with the list. A letter such as U+0199 has no accent to remove, so it is not stripped. Unicode's confusables file then maps it to a k plus a combining mark, and U+04E9 to an o plus a combining bar. Neither letter appears in Chromium's extra mapping (searched), so the mark stays and the skeleton no longer equals the brand's.
• The navigation warning. A later check compares the skeleton with sites the user visits often and with the top group of the list, and looks for one edit or one swap. It skips names with fewer than five characters before the suffix, on either side of the comparison: the source builds its near-match list only from names that pass that test, and applies it to the visited name as well. In the researchers' examples a Cyrillic lookalike of a five-letter brand is two edits away, and the four-letter brand is below the threshold.

The five-character threshold is in the code as a constant, with a comment that gives a UK example: a name such as abc.co.uk has a length of 3 and "will not be considered". Near matches, one edit or one swap, are looked for only against the top group of the list and against sites the visitor uses often, and an exact skeleton match is looked for against all 8,462. Of the 836 names in the top group, 138 have fewer than five characters before the registry suffix, leaving 698 as near-match targets, and across all 8,462 the figure is 1,034, or 12.2 per cent (counted using the Public Suffix List; the researchers give the rule, not these counts). Twelve of the 71 UK entries have fewer than five characters, and three of the nine UK names in the top group do.

The two lists, as read in Chromium's source

The 29 letters. The Cyrillic list in the source holds 29 letters (counted). Until a commit dated 11 September 2026 it held 28. That commit adds U+043C, and its message says the letter "was omitted" and let Cyrillic labels containing it "bypass whole-script-confusable detection". It adds: "This change does not impact a significant number of sites' URL displays in Chrome." The researchers say Chrome 155 still ships 28 letters. The issue behind the commit is marked access-denied on the tracker, so who reported it and when is not stated. The point for this briefing is the pattern: the defence is extended one letter at a time, and the letters it has not been extended to are the gap. The researchers record the same pattern in Chrome 148, released on 5 May 2026, which they say moved to ICU 78.2 and so stopped accepting two letters (U+048F and U+04FF). Unicode's 17.0.0 identifier-type file marks both as Uncommon_Use (read).

The 8,462 domains. The file holds 8,462 names, one per line, with a marker after the first 836. The header says it was generated from the Chrome User Experience Report table for September 2023, 37 months before the read (derived from the table name; the date of the file's last change could not be read because GitHub's history request failed). The fetch script in the same folder keeps hostnames with a popularity rank of 10,000 or better, treats rank 1,000 or better as the top group, adds three hosts by hand, and removes duplicates. That is a global popularity list. It has 3,777 names ending in .com (44.6 per cent), 392 in .net and 188 in .org (counted). Chromium's own documentation says the code restricts "domains that are similar to top 10k domains" in a document last updated on 25 June 2019, and its interstitial steps say "top 500 domain" while the file's top group has 836 entries. That mismatch is Chromium's, and this briefing does not resolve it.

UK names on the 8,462-entry list, counted by this briefing from the file in Chromium's main branch on 10 October 2026. Suffix counts are of entries ending in the suffix. Names are those in the file.

What was counted	Count	What it means
Entries ending in .uk	71 of 8,462 (0.84 per cent)	65 end in .co.uk, 4 in .gov.uk and 2 in .nhs.uk. The 4 are the Met Office, GOV.UK's service domain, Transport for London and www.gov.uk; the 2 are the NHS site and its jobs site.
Entries ending in .ac.uk, .org.uk, .police.uk or .sch.uk	0	None of these suffixes appears, so universities, police forces and schools that use them are not covered. Councils are not on the list either: the only .gov.uk names are the four above.
Bank and building-society names among the 71	4	barclays.co.uk, halifax-online.co.uk, lloydsbank.co.uk and nationwide.co.uk. Whether another is on the list under another suffix was not searched.
Of the 71, names under five characters before the suffix	12	These cannot be near-match targets, and near matches are built from the top group only in any case. An exact skeleton match still applies to all 71.
Entries in the top group (first 836)	9 UK names, 3 of them under five characters	Amazon, Argos, the BBC, the Daily Mail, eBay, Google, Rightmove, service.gov.uk and www.gov.uk, all under .uk suffixes. The three under five characters are the BBC, eBay and www.gov.uk, by the code's rule.

What a brand outside the list gets. The skeleton check at the second stage compares a name with this file only. A lookalike of a brand that is not on it is not turned into Punycode by that stage, and the near-match warning has no target for it. The navigation warning adds one more source, the sites an individual visitor uses often: for a visitor who uses the real site a lot, the write-up says an exact skeleton match shows a full-page warning, and a near match shows a Safety Tip. Chromium's own page says warnings are shown only on sites the user has not used frequently, and that only well-known sites or sites with an established relationship are recommended. A customer who is new to the brand, or a member of staff who does not use the real site, has neither. By this briefing's reading of the lookup code, the skeleton is compared in full, suffix included, so a lookalike of a name on the list under .co.uk would have to be under the same suffix to match. That is inference from reading the code, not a test, and a brand owner should not rely on it.

How a brand owner can check. The file is public in Chromium's source tree: search it for your registrable name, exactly as you write it, and for each suffix you use. If it is absent, assume the skeleton check does not cover you. How to ask for inclusion: no route was found. The folder's README says updates follow an internal process, and the fetch script takes the popularity ranking, so inclusion follows traffic and not a request. Chromium's lookalike page describes review requests for sites that are wrongly flagged, which is the opposite request.

The multiplication. Each extra letter that a browser accepts and that resembles a Latin one enlarges the set of brandable lookalikes, because the number of spellings of a name is the product, across its letters, of the number of look-alikes available for each. As an illustration only, with no domain in mind: a five-letter label in which every letter has two acceptable look-alikes has 2 x 2 x 2 x 2 x 2 = 32 spellings, and giving one letter a third raises it to 48. The researchers add the Latin side: a Cyrillic lookalike has to replace every letter, while a Latin one can change a single letter. In Unicode's confusables data (version 18.0.0, dated 6 August 2026) this briefing counted 1,656 non-ASCII characters whose prototype is made only of basic Latin letters, 1,447 of them single letters, and 234 whose prototype is a Latin letter followed by a combining mark, which is the class the two characters belong to. These are counts of what the data contains. They include symbols and scripts that browsers and registries exclude, and they are an upper bound, not a count of usable characters.

What is stated, by whom, and what is not

The Register's article of 10 October 2026 is a second reading of the researchers' write-up of 3 October, a week earlier, and adds no testing of its own and no statement from Google or Microsoft. This briefing treats the write-up as the primary source for the findings and read the Chromium files, Unicode's data and the registry tables as primaries for what the write-up claims about them. Four points where the article and the primaries read differently matter:

• Seven checks. The article repeats the researchers' count of seven. Chromium's documentation lists thirteen steps for the whole decision, and the source defines ten result codes.
• "Almost 8,500". The file holds 8,462 names, 836 of them in the top group.
• "Two characters". The write-up's table lists three Cyrillic letters that pass today and two that passed until Chrome 148, and the hooked-letter route is a class: the write-up says a hook or a stroke behaves the same way.
• The mail test. The article says Gmail displayed each of the 20 domains the researchers fed the clients and Outlook Web showed all 20 as Punycode. The write-up says the test used 20 internationalised senders, a mix of lookalikes, accented spellings of top names and ordinary IDNs, not the 20 registered names, with two ASCII controls. It also says Gmail's mailed-by field shows the encoded form, which is not the address a reader checks.

Claims about the research, with the source that makes each, read on 10 October 2026. Counts and day counts are derived from the sources and their dates.

Question	Stated, and by whom	Not stated
Were these characters used in attacks?	Neither the Register nor the write-up reports use. The researchers registered the 20 domains themselves, and say each lookalike pair they counted in .com is a potential imitation, not a confirmed typosquat.	Any use in the wild. Equally not stated: that there has been none.
Is it fixed?	Chrome 148 (5 May 2026) rejects two other letters (the write-up). Chromium added a 29th letter on 11 September 2026 (the commit). In the main-branch source as read on 10 October, and unchanged on a re-read at 20:30 BST, U+04E9, U+04AF and U+0457 are still off the list (read).	Any Google statement, tracker entry or fix for these characters or for hooked and stroked Latin letters. Four Chrome stable posts from 22 September to 6 October list Omnibox items but none names IDN, lookalike or homograph. The issue behind the 11 September commit is access-denied.
Does Edge share it?	The write-up says Chromium is the engine behind Chrome and Edge. Edge's security notes list Edge 155.0.4283.45 on 8 October 2026, and Edge 154 builds from 24 September.	Any Microsoft statement, any test of Edge, and whether Edge adds checks of its own. The notes read mention no IDN or lookalike change.
Do Firefox and Safari show these labels as Unicode?	The write-up examines Chromium most closely. Firefox's source (read) has its own hard-coded Cyrillic list of 28 letters without the three. WebKit's source (read) says Apple platforms load the script allow-list from a file.	Any test of either browser, and Apple's default script list. The compiled default in WebKit's shared code leaves Cyrillic out, but the Apple implementation is not in the source read.
Do other defences catch them?	The researchers did not measure spam filtering, sender reputation or link scanning. Chromium's documentation names Google Safe Browsing and password managers as other layers.	Whether Safe Browsing, Defender SmartScreen or a mail gateway blocks any of the 20.
Did the registry allow them?	Yes, by its published tables: U+04E9, U+04AF and U+0457 are in Verisign's Cyrillic table and U+0199 in its Latin table. The main demonstration name was registered on 26 September 2026 (registry record) and the write-up appeared 7 days later (derived).	Any other registry or registrar rule that screened them. Nominet's position on IDNs in .uk was not read: nominet.uk refused a plain request and was not pursued.
How many people are affected?	No count of people. The write-up counts names in the .com zone: 733,509 IDNs among 167,226,216 delegated names (0.44 per cent, derived), and 161,894 lookalike pairs.	Users, victims, or how many pairs are used for fraud. The write-up says some are defensive registrations or unrelated businesses.

Whose code, whose interest

Each party below has an interest, and the table states it in one sentence without treating it as a verdict on the facts.

What each party published or did, as read on 10 October 2026, and its interest in one sentence.

Party	What it published or did, as read	Its interest
Have I Been Squatted (the researchers)	Registered 20 demonstration domains, published a write-up on 3 October 2026 that carries a 33-minute reading time, ran the Chromium logic offline, and recommends registering variants, monitoring and passkeys.	It sells detection and takedown of lookalike domains, so a finding that makes lookalikes look common suits it.
Google (Chromium)	Documents a policy of 13 steps, says its lookalike checks aim "not to make spoofing impossible, but to force attackers to use less convincing lookalikes", and says IDN display is "a limitation of how URLs are displayed in browsers in general, not a specific bug in Chrome".	It must show non-Latin names to billions of people, and its own page says showing Punycode too widely would hurt usability.
Microsoft (Edge, Outlook Web)	Ships Edge on Chromium and Outlook Web, which printed all 20 test senders in encoded form in the researchers' test, including ordinary names such as a Swiss city. Its Edge notes for 154 and 155 do not mention the research.	It ships both a browser that inherits Chromium's lists and a mail client that avoids the problem by decoding nothing.
Mozilla (Firefox)	A wiki page last edited on 17 April 2017 says its system permits whole-script confusables and that "it is up to registries" to stop customers ripping each other off. Its source holds a 28-letter Cyrillic list.	It wants non-Latin scripts treated as equals, and prefers that registries do the policing.
Apple (Safari, WebKit)	No IDN display policy page was found. WebKit's source says Cocoa loads the allowed scripts from a file. A Safari Technology Preview 238 note dated 26 February 2026 fixes an IDN homograph displayed as a Latin domain.	It sets Safari's default and publishes the least of these vendors about it, so its position cannot be read from its pages.

Two further parties matter and are not in the table because they do not ship a browser. Verisign operates .com and publishes the tables that allowed these registrations, so its interest is in the registry it runs. The Unicode Consortium publishes the data the checks draw on, and its standard describes itself as an independent specification, so each implementer decides how to use it. Its text says confusability "cannot be an exact science", that the data "may be refined and extended over time", and that a skeleton is for internal testing only. It also warns that a whole-script test is "likely to flag a large number of legitimate strings" in Latin or Cyrillic, which is why Chromium's list is short and why it keeps 12 allowed Cyrillic words: a longer list would block honest names. ICANN's IDN guidelines (version 4.1, 22 September 2022) say all code points in a label should come from one script, with exceptions, but only "encouraged" registries to minimise whole-script confusables, so the registry layer is advisory. The design is a trade between false alarms and misses, and these two characters sit on the miss side.

A typosquat is a typing mistake. This is a display decision

"Typosquatting" names a technique in which a visitor mistypes or misreads a name. The Register's headline uses it, and so do the researchers. For these 20 names the label points to the wrong party. Nobody mistyped anything, and nobody misread: the browser chose to show the Unicode form, and the address bar then displayed, to the eye, the same name as the genuine one. The failure is in a decision the user cannot see being made. The researchers open with the advice this undermines: "Check the address bar" is the one piece of security advice everybody has heard. It assumes the name there can be read correctly, which was true while names could only use English letters, digits and a hyphen.

The history gives a sense of scale. The write-up says the whole-script check arrived in Chrome 58, and the Chrome Releases post promoting 58 to stable is dated 19 April 2017 and lists CVE-2017-5060, URL spoofing in the Omnibox, for the bug Chromium's own document cites as the all-Cyrillic report. From that date to the Register's article is 3,461 days, about 9.5 years (derived). The response the sources describe, in the Chrome 148 change and in the 11 September 2026 commit, is to adjust a list when a letter is found. Chromium's own page states the aim: "not to make spoofing impossible, but to force attackers to use less convincing lookalikes". It adds that Chrome cannot detect all lookalike domains. By that stated aim, a lookalike that reads the same as the genuine name is a miss, and the 20 are misses. The page does not promise otherwise, and that is the case against relying on the address bar.

The researchers' demonstration page is a single page that shows the genuine name and its lookalike side by side in the viewer's own font, a timeline of 15 earlier lookalike incidents from 2006 to 2026, and five habits: do not trust how an address looks, go to sites directly, let a password manager fill logins, use passkeys or security keys, and keep the browser up to date. It states that it is not affiliated with the brand it imitates and asks for no information. This briefing read its text and verified none of the incident descriptions on it.

The pattern has come up in earlier briefings: a label or an address is shown as the control, and it is not. A documentation placeholder nobody reserved served a lure where the request was the detection. A Google ad showed bing.com while four stops carried the click elsewhere. A browser-in-the-browser page drew its own address bar. In each, the thing a person reads was the part the attacker controlled.

Why the registry and the certificate authority did not stop it

These names could be registered because U+04E9 is a letter of Kazakh and other languages, and the hooked k is used in Hausa (the Register's wording), and the registry's tables are written to let each language's letters through. The tables are per script, a label is checked against the table for its declared script, and a label that mixes Latin and Cyrillic therefore usually fails at registration (the write-up's account; Verisign's page says registrations are checked against language tables and a policy of permissible and prohibited code points). The Latin table, version 2.6, lists 587 non-ASCII code points (the write-up's figure, confirmed from the file), and no variant rules appear in the file. The Cyrillic table is 12.0 years old (derived from its 25 October 2014 effective date) and is still the current one on the IANA list. The tables do what they say. They keep a label in one script, and they cannot leave out a letter that a language uses.

The main demonstration name was registered on 26 September 2026 by the registry's own record. Public certificate logs show six entries for it, with not-before dates on 26 and 27 September from three public authorities, and the live certificate came from Google Trust Services, valid from 27 September to 26 December (read). One oddity: the earliest logged entry carries a time earlier on 26 September than the registry's registration time, which this briefing cannot explain and does not rely on. The defender point, from one example: a lookalike had public certificate entries within a day or two of registration, so a search of certificate logs is one place a live lookalike appears early. The NCSC advises certificate monitoring for your own domain, and does not say whether it covers confusable names.

UK reading: what each source says, and where it does not reach

The exposed group is any UK organisation whose customers, staff or citizens could be sent to a lookalike of its name: a bank, a retailer, a council, a health body, a government service. The NCSC and Cyber Essentials each describe controls that could apply. The table says what each source says and whether the source claims it stops this. None does. Entries marked inference are this briefing's.

UK controls and what the sources read on 10 October 2026 say about them. NCSC page dates are those shown on each page. Cyber Essentials is v3.3, April 2026, read from the text extraction saved for briefing 283.

Control and source	What the source says	Reach for this problem
NCSC Takedown Service (page published and reviewed 20 November 2020)	Works with Netcraft and covers UK Government brands and services, focused on "the HMG brand". Central government needs no registration. It scans spam and phishing feeds and takes reports through the Suspicious Email Reporting Service, then notifies hosts and adds sites to safe-browsing lists.	A private-sector brand owner is outside its stated eligibility. It acts on live attack pages, not on a registered but unused lookalike (inference).
NCSC takedown and brand impersonation guidance (21 September 2022)	Anyone can ask the registrar and the host to act: find the registrar, search for its abuse route, find the IP owner, and keep a screenshot with the full address and time. Requests can take hours, days or weeks. A takedown provider is an alternative, and the NCSC advises planning before an incident.	A route for a live abuse. It does nothing about what the address bar shows. The page does not mention IDNs or confusable characters (searched).
NCSC guidance for registrars (27 March 2025)	Says it is "extremely common" for abusive registrations to imitate well-known organisations or brands, and that monitoring new registrations can find them before they are used. Names Nominet's Domain Watch.	Written for registrars, so a brand owner must do or buy the monitoring (inference). No mention of IDNs (searched).
NCSC guidance for high-risk individuals (29 May 2024), certificate monitoring	To monitor attempts to impersonate your website, use a service that notifies you when a new certificate is issued for your domain.	Worded for your own domain. Whether a service also matches confusable names is a product question. The demonstration name has certificate-log entries dated 26 and 27 September 2026.
NCSC Web Check and Mail Check	Retired on 31 March 2026, 193 days before the Register's article (derived). The NCSC recommends commercial external attack surface management products and its Check your cyber security service.	Neither was a lookalike monitor in the text read (inference). Anyone relying on them has no findings since 31 March.
NCSC phishing guidance (reviewed 13 February 2024)	DMARC, SPF and DKIM stop phishers spoofing your domain. Run a proxy to block sites identified as hosting phishing. Consider password managers, "some of which can recognise real websites and will not autofill on fake websites". No training can teach users to spot every phishing attempt.	The page does not use the words lookalike or typosquat (searched). The researchers say SPF, DKIM and DMARC all pass for a lookalike the attacker owns, so email authentication covers your exact domain only.
NCSC passkeys position (23 April 2026) and its FIDO2 paper	Recommends passkeys over passwords wherever available. In its comparison table, adversary-in-the-middle phishing is "Never vulnerable" for FIDO2 credentials and "Always vulnerable" for a password with a traditional second factor.	The paper is about credentials for personal use, and the NCSC says it has not formally assessed organisations. It needs the service to support passkeys. It does not help a customer who types a card number into a lookalike (inference).
NCSC Protective DNS	Prevents access to domains known to be malicious by not resolving them. Free. Mandated for central government and open to other organisations, with eligibility in its FAQ.	It acts on domains known to be malicious. A lookalike with no abuse recorded is not on that list (inference).
Cyber Essentials v3.3 (April 2026)	The text has no mention of lookalike, typosquat, homoglyph, impersonation, brand or spoof (searched). Its anti-malware option must "prevent connections to malicious websites over the internet". MFA is required for administrative accounts and accounts reachable from the internet, and passkeys and FIDO2 authenticators are "regarded as MFA".	It governs your own devices and accounts, so it does not reach a lookalike of your brand aimed at your customers. Its passwordless list also includes push notifications and one-time codes, which the NCSC paper treats as phishable second factors (inference).
Nominet, .uk	Not read: nominet.uk answered a plain request with 403 and was not pursued. Nominet's registrar page on IDNs, which was read, covers .cymru and .wales.	Whether .uk accepts IDN labels is not stated in anything read, so a UK brand's lookalikes may sit in .com or another suffix.

Two things follow for a UK organisation. For its own staff, a password manager that binds to the exact origin, and passkeys on the consoles that matter, are the controls whose result does not depend on what the address bar shows. Chromium's own page says password managers "won't automatically fill a password into a domain that is not the exactly correct one", and the researchers' demonstration page says the same of passkeys. The earlier briefings on GOV.UK One Login's passkeys and on Report Fraud's passkey campaign cover the limits of that route, and the Chrome 155 release became the stable build on 6 October, three days after the write-up. For its customers, the organisation cannot control the browser, so its levers are to register what is worth registering, to watch what others register, to publish how customers can check it, and to be ready to act when one goes live.

What to do, in the order worth doing

Steps 1 to 3 establish what you must defend and how exposed it is. Steps 4 to 7 reduce the chance and the harm of a lookalike. Steps 8 to 10 prepare the response. All are defender actions, and none needs a lookalike name.

What could not be verified

The question that exposes the gap

Every defence in the chain looks at the name: the registry's table, the browser's two lists, the warning, the person reading the bar. The thing that decides whether a login is stolen is none of those. It is whether anything checks the exact origin. So when a customer or a member of staff meets a name that looks like yours, what in your estate answers for the characters nobody put on a list?

Key facts