Vlákno názorů k článku Mozilla vypíná podporu národních znaků v doménách od Daniel.Peder@infoset.cz - ... proč vypínat převod úplně? Stačí zakázat převod...
-
Článek je starý, nové názory již nelze přidávat.
- Podle hodnocení
- Podle vláken
- Nejnovější
-
Daniel.Peder@infoset.cz (neregistrovaný)... proč vypínat převod úplně? Stačí zakázat převod UNICODE na ASCII.
Polopatě: když bude URL obsahovat běžné ASCII znaky [0-9A-Z.] zapsané v rozšířeném tvaru, tak eprve potom se zakáže převod celého URL nebo bude uživatel nějak jinak upozorněn. Ne?
Má to nějakou chybu? -
Horst Fuchs (neregistrovaný)Prosimvas, ten vas navrh "polopate" zcela popira smysl existence IDN (ne ze bych snad nejaky hlubsi smysl v tehle kravine videl). Neboli, pokud budu videt misto skutecneho URL paskvily typu http://www.xn--bhm-sna.de/ tak to rovnou muzu cele slavne IDN zrusit, coz by ostatne bylo vubec to nejlepsi, co by se mohlo stat.
-
Daniel.Peder@infoset.cz (neregistrovaný)Horst určitě ví o čem mluví, článek je napsán špatně, ale jsem to domyslel ještě dál. Přestože se v rámci standardu ASCII nekóduje, mohl by být problém při využití nestandardního kódování - tj. zakódovat některé ASCII znaky do punnykodu. Něměl jsem čas to testnout v reálu takže netuším co na to mizllovský dekodér a jak by se k tomu stavěli registrátoři.
-
Daniel.Peder@infoset.cz (neregistrovaný)"... Proboha proc? ..."
ale nechci, jen jsem domyslel, jak by se dalo ještě více podvrhovat: nemusíte hledat nějaká podobná písmenka v azbuce, proste do punnycodu zahrnete (coby onen podvrhovatel) i par ascii znaku a domenu zaregistrujete. Získáte doménu example.com ale zapsanou např. jako xn--exmple-qwe.com (ten punny code jsem hodil od ruky, tj. neni spravny)
Teoreticky - podle RFC - by to jit nemelo. otazka je, jak by se to tvarilo v praxi.
--
No a v tomhle smyslu jsem na prvni přečtení pochopil ten článek. Až pak jsem si všiml v diskuzi, že článek pojednává "JEN" o podvrhu podobně vypadajích písmenek. -
J.Kastl (neregistrovaný)H.Fuchs má přece pravdu. Autor článku vůbec nepochopil podstatu problému. (Asi proto, že nikdy nepracoval na ruských terminálech EC-1045, tam také člověk netušil, zda napsal velké ruské r nebo velké české p .)
Hrubou autorovou chybou je, že neřekl, že v příkladu je podstrčeno ruské malé a ( а = а ) místo obyčejného a ( a = a )
Ale řešení je snadné - jako jsme si kdysi říkali, jací jsou ti Rusové blbci, proč jim písmena azbuky nesvítí jinou barvou. - No protože uměli udělat jenom jednobarevné terminály).
A přesně tak by písmena z jiného kodu, než jaký má prohlížeč implicitně nastaven, svítila v URL barevně. (A vlastní volbou kodu, by se i neznalý autor mohl - při nebarevném URL - dopracovat k tomu, co tam tak může mít doopravdy za znak - a je-li to opravdu z jazyka, jaký chce!) -
rg (neregistrovaný)ta farba by samozrejme nepomohla
"раураӀ" (ak to lupa dobre zobrazi, je to cele v azbuke) vyzera takmer rovnako ako "paypal" v latinke, len je cely zlozeny zo znakov jedneho scriptu, takze url by zrejme bolo pekne jednofarebne (to .com sa sice neda rozumne zapisat iba v azbuke, ale plno dalsich znakov ano) -
J.Kastl (neregistrovaný)To by musel být třeba ve Windows-1251 znak omikron, ale ten tam podle mě nikde není. (Obdobně v jiném příkladě ono Ӏ , které má vypadat jako l .) Ovšem mohl by někdo celou stránku podstrčit latinkou (pro kod 1251), jen odkaz by byl v azbuce. Proto jsem posléze ještě přidal tu modrou. Tedy (pro jméno serveru v URL):
Znaky ASCII-1 - černě
Znaky jiné (t.j. transformované) - barevněJe-li transformovaný znak v tabulce kodu nastavené jako "Default Character Coding" - modře ,
není-li z oné tabulky - červeně (tedy tak by dopadl omikron při defaultně nastaveném Windows-1251).
P.S.
Jedině by se (vždy) modré ne-ASCII znaky objevily při defaultně nastaveném UTF-8. (Méně barevně zdatní jedinci by si tedy UTF-8 neměli nikdy nastavovat.) -
Zerryk (neregistrovaný)Aha, takhle jste to myslel. Něco na tom bude, avšak:
- osmibitové kódové tabulky jsou s příchodem Unicode a utf8 poněkud zastaralá záležitost, a měly by se podle mě co nejdříve vymýtit
- i tak se v rámci jedné osmibitové kódové tabulky se vyskytnou znaky vizuálně podobné, anebo některé exotičtější jazyky si zas s jednou kódovou tabulkou nevystačí. Vyřeší se sice případy typu o - omikron, ale ne třeba I1l popř nějaká analogie v rozsypaném čaji. -
Honza (neregistrovaný)To je prece problem na opacnou stranu, nez ktery se resil.
Konec koncu my jsme prece take za Cyrila a Metodeje zacali psat azbukou. Ale dost brzy jsme pochopili, ze tudy cesta do sveta (a do internetu) nepovede!
Rusove to jak znamo tusi od Petra 1., Cinane od Maa (nebot se nemohli vsichni tak rychle naucit "rude" cist) a pro hebrejstinu se o tom nejspise nikdo dosud neodvazil ani premyslet. -
Marian Petras (neregistrovaný)Já vidím dva problémy:
- Jak určit, které doménové jméno je podezřelé a které nikoliv.
- Jak informaci o podezření prezentovat uživateli.
Soustředím se na ten první a druhý nechám stranou.
Myšlenka:
Podezřelé jméno je takové, které používá podezřelý mix znaků z různých skupin.Podrobněji:
Unicode je rozdělen do několika přesně daných skupin znaků – Basic Latin, Latin-1 Supplement, Latin Extended-A, ..., Cyrillic, ..., General Punctuation atd. Podezřelé je např. to, když se ve jméně domény vyskytují znaky ze skupin Basic Latin i Cyrillic. Ještě podezřelejší je, když se znaky z obou těchto skupin vyskytují v jednom slově.Samozřejmě není nutné, aby byly znaky rozdělené do skupin stejně jako v Unicode, může se vymyslet či využít jiné rozdělení.
-
Dan Lukes (neregistrovaný)Heuristika, heuristika. Trochu malo na to, ze problemem je realne pouzitelnost ci nepouzitelnost digitalnich certifikatu ...
Mimochodem - kdyz mluvite o slovech (znaky z vice skupin v jednom slove) - mel jsme dojem, ze "slovo" je termin majici vyznam v kontextu konkretniho jazyka - pokod zname "jen" kodovani, ale nikoliv jazyk, nelze o slovech nijak jednoznacne mluvit. Nebo se mi snad lingviste budou za ten dojem smat ?
Nicmene, na vine neni IDN. Problem se zamenou domen "lide" a "l1de" pripadne "NOS" a "N0S" je, vcetne moznosti zameny jejich certifikatu vydanych tou nejduveryhodnejsi CA, je na existenci IDN nezavisly. IDN pouze zvysila riziko "vyuzitelnosti" tohoto jevu - ale problem sam je rozhodne starsi nez IDN - a je to problem obtizne resitelny. Pokousime se totiz program (browser) donutit, aby nam algoritmicky urcil, zda je konkretni spojeni pro nas bezpecne nebo nikoliv - a poskytujeme mu k tomu neuplne informace a nechceme se na jeho rozhodovani aktivne podilet. Pritom rizika, o kterych je rec, by vyrazne omezila uz takova drobnost, kdyby bez ohledu na vystavujici CA browser upozornil na prvni setkani s novym certifikatem a kdyby upozornil na to, ze "dnes" se konkretni cilovy server predstavil jinym certifikatem nez minule (znovu bez ohledu na to, kdo certifikaty podepsal). To by problem, samozrejme, neresilo bezezbytku, ale alespon by to umoznilo cloveku, aby odpovednost prevzal. Soucasne implementace browseru jsou, bohuzel, nejen nevhodne, ale ani neumozni cloveku, aby odpovednost za posuzovani prevzal.
IDN je v celem problemu jen "dalsi kapka" ...
