IDN-homografkontrol

Navne var kun ASCII i de første to årtier af DNS, og derfor måles alt om dem i bytes og bogstaver: labels af bogstaver, cifre og bindestreger, højst 63 bytes hver, højst 255 bytes i alt. Et internationaliseret domænenavn (IDN) er det, der sker, når reglerne åbnes for resten af Unicode, og punycode (RFC 3492) er stavereglen, der holder det gamle maskineri i gang: en label, der indeholder noget uden for ASCII, skrives som en xn---label, en ASCII-streng der bærer de samme tegn i foldet form. 中文.com rejser som xn--fiq228c.com, og begge stavemåder navngiver den samme vært.

Det, der betyder noget her, er, hvad punycode ikke gør. Det konverterer stavemåde og intet andet. Det har ingen mening om, hvorvidt аpple.com bør tillades at stå ved siden af apple.com, og det kunne ikke spørges om det, for spørgsmålet handler om øjne og skrifttyper og ikke om bytes. Registret bestemmer hvilke tegn, det vil sælge, browseren bestemmer, hvordan den viser et navn, den anser for sikkert, og læseren bestemmer, om der skal klikkes. Denne side besvarer spørgsmålet under alle tre: hvilke tegn består dette navn faktisk af, og hvad gør det, at det staver?

Hver række nedenfor køres af denne side, når den indlæses, og igen af knappen Selvtest, og siden skal rapportere præcis det, rækken siger — de samme fund, det samme niveau, den samme DNS-form, det samme bytetal, hverken mere eller mindre. Det er det, der gør et rent svar her værd noget: kodestien, der lader et almindeligt navn igennem, er den samme, der fanger tricksene nedenfor.

1. Tag navnet ud af det, der er indsat. Et nøgent navn bruges som det står; en URL får sin vært taget ud, og skema, port, sti og forespørgsel droppes, og siden oplyser, hvilket af de to den gjorde, i stedet for stille at analysere en skråstreg, som om den var en del af et navn.
2. Rens det, som en klient ville. Kontroltegn, tegn med nul bredde og byte-order-markeringen fjernes; et fuldbreddes- eller ideografisk punktum tæller som et punktum; og et afsluttende punktum er roden og ikke en fejl. Hvert tegn der fjernes eller fortolkes om på denne måde, rapporteres, for et nul-bredde-mellemrum der stille blev fjernet er præcis det, man skal have besked om.
3. Del det i labels og mål hver enkelt. En label må ikke være tom, må ikke begynde eller slutte med en bindestreg, og må ikke have to bindestreger på positionerne tre og fire, medmindre den er en xn---label. Hver label måles i UTF-8-bytes mod loftet på 63 bytes, og hele navnet mod 255.
4. Afkod hver xn---label tilbage til dens tegn. Den afkodede label kodes derefter igen og sammenlignes med det, der blev skrevet. En label, der ikke overlever den rundtur, er ikke den label, den påstår at være, og en label, der afkodes til et kontroltegn eller til ingenting, rapporteres som sådan i stedet for at blive droppet i stilhed.
5. Spørg, hvad hvert tegn er. Dets kodepunkt, dets UTF-8-bytes, det skrift det hører til, om det står i en gruppe af tegn, der tegnes ens, og hvad de andre medlemmer af gruppen er. Her holder et kyrillisk a op med at være „et bogstav“ og bliver til „et bogstav, der har form som et latinsk“.
6. Fold navnet tilbage til den form, det efterligner. Hvert lookalike-tegn erstattes med det tegn, det ligner, hvilket gør аpple.com til apple.com. Den foldede læsning er den enkeltstående mest nyttige linje på siden, fordi apple.com er noget, man kan handle på, hvor „et kyrillisk a“ ikke er det.
7. Saml fund og rapportér det værste. Fund rapporteres én gang hver, med de labels, de optræder i. Et navn, der bare ser usædvanligt ud, giver noter frem for fund: blanding af Han og Kana eller et afsluttende rodpunktum er almindelig skrivning og ikke en grund til bekymring.

ingen intet her var værd at nævne — lav det samme navn skrevet på en anden måde — middel et tegn, som DNS ikke bærer, eller et, der foldes til et almindeligt bogstav — høj et navn bygget til at blive læst som et andet navn, eller et, der slet ikke kan sendes.

Et niveau er det værste, fundene kan betyde, ikke en sandsynlighed og ikke en vurdering af siden. Et helt ærligt navn kan være middel, fordi det indeholder ét tegn uden for værtsnavn-alfabetet, og et fjendtligt navn kan være højt med ikke mere sofistikeret end et kyrillisk bogstav. Listen under niveauet siger hvorfor, én linje pr. fund, og den liste er den del, der er værd at læse.

Tabellen nedenfor er bygget af den samme liste, som siden rapporterer fra, så en række her og et fund i et resultat ikke kan være uenige. En kontrol, der ikke fandt noget, står som nej: pointen med tabellen er, at man kan se, at spørgsmålet blev stillet og besvaret, i stedet for at undre sig over, om det overhovedet blev stillet.

Den samme liste driver noterne, som slet ingen niveau har: en label uden punktum, et afsluttende rodpunktum, et topdomæne der ikke er ASCII, en separator der ikke er et punktum, et navn med store bogstaver, tegn der blev fjernet under rensningen, og en URL der blev reduceret til sin vært.

Et navn er en liste af labels, og hver af dem tælles i bytes, ikke i tegn. Den forskel er hele grunden til, at punycode findes: 中文 er to tegn og seks bytes, og dets xn---form er femten tegn, så den kodede stavemåde er det, der skal passe. Siden anvender begge lofter og rapporterer, hvilket af dem der blev ramt.

Man har måske bemærket, at et navn skrevet på kinesisk eller kyrillisk nogle gange vises i adresselinjen som xn---vrøvl i stedet for de tegn, man forventer. Det er browseren, der nægter at vise den pæne form, og ikke at webstedet ikke har registreret det. En browser anvender en egen regel på et navn, den aldrig har set før, og reglen findes af den grund, hele denne side findes for: at vise аpple.com som аpple.com er netop det, en angriber ønsker, så et ukendt navn med blandet skrift vises i sin kodede stavemåde, indtil det er set tilstrækkeligt ofte til at blive betragtet som troværdigt.

Punycode er RFC 3492, og selvtesten på denne side kører de elleve eksempel-labels, der står trykt i dokumentet, som sin første kontrol, så kodningen her holdes op mod eksemplerne i standarden og ikke mod sig selv. De behandlingsregler, et IDN gennemgår, er RFC 5891 med tegntabellerne fra RFC 5892, og kompatibilitetslaget, som browsere faktisk anvender, er UTS #46 med det ikke-transitionelle flag; siden fortæller, hvad disse regler gør, i stedet for at lade som om den implementerer dem, og den foldning den anvender — NFC, derefter små bogstaver, derefter RFC 3492 — er den samme korte sekvens, en klient udfører, før et navn sendes. Formgrupperne, skriftintervallerne og de usynlige tegntabeller i denne familie af sider er skrevet i hånden til familien: standarderne nævnes, så man selv kan læse dem, og ingen tekst fra dem gengives her.

Er et navn med blandet skrift altid et angreb?

Nej, og at behandle det sådan ville være forkert på en måde, der betyder noget. Japansk skriver Han-tegn og Kana i samme ord, og koreansk skriver Han-tegn inden i Hangul. Det, der ikke har nogen almindelig forklaring, er latinsk blandet med kyrillisk eller græsk i én label, fordi de skrifter ikke bruges sammen i noget sprog, og siden trækker den linje i stedet for at markere enhver blanding. Derfor kommer de japanske og koreanske rækker i casetabellen ovenfor tilbage rene.

Hvorfor kommer mit eget navn så tilbage som middel?

Mest sandsynligt, fordi det indeholder ét tegn, som værtsnavn-alfabetet ikke omfatter — en understregning, et mellemrum, en accent skrevet som et kompatibilitetstegn — og det er middel, fordi navnet ikke kan sendes, som det står. Middel betyder „dette bør kigges på“, ikke „dette er en forfalskning“. Fundet under niveauet navngiver det præcise tegn og dets position.

Fortæller siden mig, om et navn er farligt, registreret eller nåbart?

Nej, på alle tre punkter. Den rører aldrig netværket og opløser aldrig noget, så den kan ikke vide, om et navn findes, eller hvem der ejer det, og den siger bevidst intet om, hvad et websted gør. Den besvarer et snævrere spørgsmål, som man selv kan kontrollere: hvilke tegn består dette navn af, og hvis lookalike-tegnene foldes tilbage til de bogstaver, de efterligner, hvad staver det så?

Mit navn er på kinesisk, og siden siger, at topdomænet ikke er ASCII. Er der noget galt?

Intet er galt. Et kinesisk topdomæne rejser som en xn---label for sig selv, så den sidste label i navnet skrives i sin kodede form, og siden noterer det. Noter har ikke et niveau, fordi de beskriver et faktum frem for et problem.

Hvorfor viser linjen læses som nogle gange det samme navn, jeg skrev?

Fordi siden kun viser en foldet læsning, når foldningen faktisk ændrer noget. Hvis hvert tegn i navnet allerede har den form, det efterligner, er den foldede læsning og navnet den samme streng, og der er intet at fortælle.

Hvad er en A-label og en U-label?

En A-label er den ASCII-stavemåde, der rejser: xn--fiq228c. En U-label er den samme label skrevet i det skrift, den tilhører: 中文. De er to stavemåder af én label, og siden viser begge for hver label, den afkoder, så man kan se, hvad en kodet label skjuler.