Kontroll for IDN-homografer

Navn var bare ASCII de første to tiårene av DNS, og det er grunnen til at alt om dem måles i byte og bokstaver: etiketter av bokstaver, siffer og bindestreker, høyst 63 byte hver, høyst 255 byte totalt. Et internasjonalisert domenenavn (IDN) er det som skjer når reglene åpnes for resten av Unicode, og punycode (RFC 3492) er skrivereglen som holder den gamle maskinerien i gang: en etikett som inneholder noe utenfor ASCII, skrives som en xn---etikett, en ASCII-streng som bærer de samme tegnene i foldet form. 中文.com sendes som xn--fiq228c.com, og begge skrivemåter navngir samme vert.

Det som betyr noe her, er hva punycode ikke gjør. Den konverterer skrivemåte og ikke noe annet. Den har ingen mening om hvorvidt аpple.com bør få lov til å ligge ved siden av apple.com, og den kunne ikke spørres om det, for spørsmålet gjelder øyne og skrifter og ikke byte. Registeret bestemmer hvilke tegn det vil selge, nettleseren bestemmer hvordan den viser et navn den anser som trygt, og leseren bestemmer om man skal klikke. Denne siden svarer på spørsmålet under alle tre: hvilke tegn er dette navnet faktisk laget av, og hva gjør det at det staver?

Hver rad under kjøres av denne siden når den lastes, og igjen av knappen Selvtest, og siden må rapportere nøyaktig det raden sier den rapporterer — de samme funnene, det samme nivået, den samme DNS-formen, det samme antallet byte, ikke mer og ikke mindre. Det er det som gjør et rent svar her verdifullt: kodeveien som slipper gjennom et vanlig navn, er den samme som fanger triksene nedenfor.

1. Ta navnet ut av det som ble limt inn. Et rent navn brukes slik det står; en URL får vertsdelen tatt ut, og skjema, port, sti og spørring fjernes. Siden sier hvilken av de to den gjorde, i stedet for å analysere en skråstrek stille som om den var en del av et navn.
2. Rens det slik en klient ville gjort. Kontrolltegn, nulbreddetegn og byte order mark fjernes, et fullbreddes- eller ideografisk punktum regnes som punktum, og et etterfølgende punktum er roten og ikke en feil. Hvert tegn som fjernes eller tolkes på nytt på denne måten, blir rapportert, for et nulbreddemellomrom som ble fjernet i stillhet, er nøyaktig det man må få vite om.
3. Del det i etiketter og mål hver av dem. En etikett har ikke lov til å være tom, til å begynne eller slutte med bindestrek, eller til å ha to bindestreker på plassene tre og fire med mindre den er en xn---etikett. Hver etikett måles i UTF-8-byte mot grensen på 63 byte, og hele navnet mot 255.
4. Dekod hver xn---etikett tilbake til tegnene den bærer. Den dekodede etiketten kodes så en gang til og sammenlignes med det som ble skrevet. En etikett som ikke overlever denne rundturen, er ikke den etiketten den utgir seg for, og en som dekodes til et kontrolltegn eller til ingenting, blir rapportert som det i stedet for å bli droppet stille.
5. Spør hva hvert tegn er. Kodepunktet, UTF-8-bytene, skriften det hører til, om det ligger i en gruppe tegn som tegnes likt, og hva de andre medlemmene av gruppen er. Her slutter en kyrillisk a å være "en bokstav" og blir "en bokstav som har samme form som en latinsk".
6. Fold navnet ned til formen det etterligner. Hvert look-alike-tegn erstattes med tegnet det ligner på, noe som gjør аpple.com til apple.com. Den foldede lesningen er den mest nyttige linjen på siden, fordi apple.com er noe man kan handle etter, mens "en kyrillisk a" ikke er det.
7. Samle funnene og rapporter det verste. Funn rapporteres én gang hver, med etikettene de forekommer i. Et navn som bare ser uvanlig ut, gir notater i stedet for funn: å blande Han og Kana, eller å slutte med rotpunktum, er vanlig skrift og ikke en grunn til bekymring.

ingen ingenting her var verdt å nevne — lav det samme navnet skrevet en andre måte — medium et tegn DNS ikke vil bære, eller et som folder ned til en vanlig bokstav — høy et navn bygget for å leses som et annet navn, eller et som ikke kan sendes i det hele tatt.

Et nivå er det verste funnene kan bety, ikke en sannsynlighet og ikke en vurdering av nettstedet. Et helt ærlig navn kan være medium fordi det inneholder ett tegn utenfor alfabetet for vertsnavn, og et fiendtlig navn kan være høyt med ikke mer sofistikert enn én kyrillisk bokstav. Listen under nivået sier hvorfor, én linje per funn, og det er den listen som er verdt å lese.

Tabellen under er bygget av samme liste som siden rapporterer fra, så en rad her og et funn i et resultat kan ikke være uenige. En sjekk som ikke fant noe, er oppført som nei: poenget med tabellen er at man kan se at spørsmålet ble stilt og besvart, i stedet for å lure på om det i det hele tatt ble stilt.

Den samme listen styrer notatene, som ikke har noe nivå i det hele tatt: én etikett uten punktum i seg, et etterfølgende rotpunktum, et toppdomene som ikke er ASCII, et skilletegn som ikke er punktum, et navn med store bokstaver, tegn som ble fjernet under rensingen, og en URL som ble redusert til vertsdelen.

Et navn er en liste med etiketter, og hver av dem telles i byte, ikke i tegn. Det skillet er hele grunnen til at punycode finnes: 中文 er to tegn og seks byte, og dens xn---form er femten tegn, så det er den kodede skrivemåten som må få plass. Siden bruker begge grensene og rapporterer hvilken som ble truffet.

Man har kanskje lagt merke til at et navn skrevet på kinesisk eller kyrillisk noen ganger vises i adressefeltet som xn---tøys i stedet for tegnene man forventer. Det er nettleseren som avstår fra å vise den pene formen, ikke nettstedet som ikke klarer å registrere den. En nettleser bruker en egen regel på et navn den aldri har sett før, og regelen finnes av grunnen denne hele siden finnes for: å vise аpple.com som аpple.com er nettopp det en angriper ønsker, så et ukjent blandet skriftnavn vises i sin kodede skrivemåte til det har blitt sett ofte nok til å stoles på.

Punycode er RFC 3492, og selvtesten på denne siden kjører de elleve eksempeletikettene som står i dokumentet, som sin første sjekk, slik at koderen her holdes til eksemplene i standarden og ikke til seg selv. Prosessreglene et IDN går gjennom, er RFC 5891 med tegntabellene i RFC 5892, og kompatibilitetslaget nettlesere faktisk bruker, er UTS #46 med det ikke-transisjonelle flagget; denne siden forteller hva disse reglene gjør i stedet for å late som den implementerer dem, og foldingen den faktisk bruker — NFC, deretter små bokstaver, deretter RFC 3492 — er den samme korte sekvensen en klient utfører før et navn sendes. Formgruppene, skriftområdene og tabellene for usynlige tegn i denne familien av sider er skrevet for hånd for familien: standardene er nevnt slik at man kan lese dem selv, og ingen tekst fra dem er gjengitt her.

Er et blandet skriftnavn alltid et angrep?

Nei, og å behandle det slik ville vært feil på en måte som betyr noe. Japansk skriver Han-tegn og Kana i samme ord, og koreansk skriver Han-tegn inne i Hangul-tegn. Det som ikke har noen vanlig forklaring, er latinsk blandet med kyrillisk eller gresk i én etikett, fordi disse skriftene ikke brukes sammen i noe språk, og siden trekker linjen der i stedet for å flagge alle blandinger. Derfor kommer de japanske og koreanske radene i tilfelletabellen ovenfor tilbake rene.

Hvorfor kommer mitt eget navn tilbake som medium, da?

Mest sannsynlig fordi det inneholder ett tegn som alfabetet for vertsnavn ikke har med — et understrek, et mellomrom, en aksent skrevet som et kompatibilitetstegn — og det er medium fordi navnet ikke kan sendes slik det står. Medium betyr "dette bør sjekkes", ikke "dette er en forfalskning". Funnet under nivået nevner det nøyaktige tegnet og posisjonen.

Forteller siden meg om et navn er farlig, registrert eller tilgjengelig?

Nei, på alle tre. Den rører aldri nettverket og slår ikke opp noe, så den kan ikke vite om et navn finnes eller hvem som eier det, og den sier bevisst ingenting om hva et nettsted gjør. Den svarer på et smalere spørsmål som kan sjekkes selv: hvilke tegn er dette navnet laget av, og hvis jeg folder look-alike-tegnene ned til bokstavene de etterligner, hva staver det?

Navnet mitt er på kinesisk, og siden sier at toppdomenet ikke er ASCII. Er noe galt?

Ingenting er galt. Et kinesisk toppdomene sendes som en egen xn---etikett, så den siste etiketten i navnet er skrevet i kodet form, og siden noterer det. Notater får ikke noe nivå fordi de beskriver et faktum, ikke et problem.

Hvorfor viser linjen leses som noen ganger det samme navnet jeg skrev?

Siden viser bare en foldet lesning når folding faktisk endrer noe. Hvis hvert tegn i navnet allerede har formen det etterligner, er den foldede lesningen og navnet den samme strengen, og det er ingenting å fortelle.

Hva er en A-etikett og en U-etikett?

En A-etikett er ASCII-skrivemåten som sendes: xn--fiq228c. En U-etikett er den samme etiketten skrevet i skriften den tilhører: 中文. De er to skrivemåter av én etikett, og siden viser begge for hver etikett den dekoder, slik at man kan se hva en kodet etikett skjuler.