Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Watch out: ɢoogle.com isn’t the same as Google.com

thenextweb.com

Post reply on HN
Print view View original

101–110 of 136 posts

Re: Watch out: ɢoogle.com isn’t the same as Google.com

#101

Post by elihu »

mcv wrote: post #11
Entangled wrote: post #3

Web browsers should have an option to show non-ascii chars in urls in red.

This would be a great solution. Allowing unicode characters in domain names is just inviting trouble. I understand that people with non-Latin scripts want domain names in their own language and alphabet, but there are way too many unicode characters that will confuse people about legitimate-looking domain names. Showing non-ascii in red would be an easy solution for everybody.

It seems like a reasonable compromise would be to allow domain names in non-Latin languages as long as the entire name is in the character set of a specific language. So, if your name is in English, that's fine. If it's in, say, Cyrillic, that's fine too. But if you mix English and Cyrillic characters, that's not allowed. It wouldn't necessarily eliminate all name look-alikes, but it would get rid of most of them.

Re: Watch out: ɢoogle.com isn’t the same as Google.com

#102

Post by spullara »

stevenbedrick wrote: post #96
a3n wrote: post #91

This is strange to me. This is clearly meant, in unicode, to be 'G' that we all know and love. It has uselessly expanded "the alphabet" (to be western-centric) in a confusable way. Unicode maybe should have been three dimensional, with "concept of G" in the 2D space, and "ways of representing G" behind G, along the third axis. All ways of representing G, whether little capital, capital, lower case, would or at least…

It actually does do something along those lines, with the "canonical" and "compatible" equivalence rules: https://en.wikipedia.org/wiki/Unicode_equivalence As mentioned by others on this thread, the real issue is not with Unicode per se, but rather with the ways that web browsers handle it (or fail to handle it, as the case may be).

The web browser or DNS?

Re: Watch out: ɢoogle.com isn’t the same as Google.com

#103

Post by pvdebbe »

underyx wrote: post #25
Fiahil wrote: post #15

Earlier quoted context omitted.

Slack is not doing anything. It's Google chrome filling up your clipboard with the "extended" version of the url.

But when I paste it in the Slack message box it shows the ɢoogle.com version.

I haven't used slack, but I think both are doing the best practices around there: Chrome copies the punycoded URL to clipboard, Slack will decode pasted punycode-URLs into a nicer presentation.

Re: Watch out: ɢoogle.com isn’t the same as Google.com

#104

Post by bazzargh »

2T1Qka0rEiPr wrote: post #78
bazzargh wrote: post #45

Earlier quoted context omitted.

Nope. The browser is behaving sensibly, since you can't register that domain. It's applying the same rules that the registrars do. ICANN require that registries follow RFC3491 and related RFCs for name prep before allowing a name to be registered https://www.icann.org/resources/unthemed-pages/idn-guideline... . What that one does is (among other things) NFKC normalization and case-folding: irb(main):016:0> "\ufeff\uf…

Interesting. So, out of interest, why is the same not being applied for ɢ? (When I ran it through Python's unidecode I got the roman symbol all the same).

Because 'small capital g' doesn't have a compatibility decomposition to G, but wide letter P does have a compatibility decomposition to 'normal' P. Unicode normalization kills large classes of homograph attacks but by no means all. conventions over mixing scripts from different languages stop some more, but there's no single answer.

Re: Watch out: ɢoogle.com isn’t the same as Google.com

#105

Post by witty_username »

a3n wrote: post #89
mcv wrote: post #11

Earlier quoted context omitted.

This would be a great solution. Allowing unicode characters in domain names is just inviting trouble. I understand that people with non-Latin scripts want domain names in their own language and alphabet, but there are way too many unicode characters that will confuse people about legitimate-looking domain names. Showing non-ascii in red would be an easy solution for everybody.

Don't even show the suspect URL, show "THIS MIGHT BE A SCAM", with some kind of hover over showing the URL, and some way to click to more information.

Why?

Non-latin alphabet domain names do have legitimate uses, although they are very rarely used.

Re: Watch out: ɢoogle.com isn’t the same as Google.com

#107

Post by [deleted] »

hatsunearu wrote: post #71
koliber wrote: post #21

Earlier quoted context omitted.

Chinese character domains would be shown in red letters. I think it's a good choice of color. :)

What about websites without Chinese characters? I know in Asia, having red colored names is kind of offensive (evokes of the Reaper's 'hit list'). Would be annoying if [name].me or whatever is red!

[deleted]

Re: Watch out: ɢoogle.com isn’t the same as Google.com

#108

Post by zokier »

stevenbedrick wrote: post #96
a3n wrote: post #91

This is strange to me. This is clearly meant, in unicode, to be 'G' that we all know and love. It has uselessly expanded "the alphabet" (to be western-centric) in a confusable way. Unicode maybe should have been three dimensional, with "concept of G" in the 2D space, and "ways of representing G" behind G, along the third axis. All ways of representing G, whether little capital, capital, lower case, would or at least…

It actually does do something along those lines, with the "canonical" and "compatible" equivalence rules: https://en.wikipedia.org/wiki/Unicode_equivalence As mentioned by others on this thread, the real issue is not with Unicode per se, but rather with the ways that web browsers handle it (or fail to handle it, as the case may be).

I think it is very much an issue in Unicode that they did not define the NFKD of ɢ to be G. As far as I can tell, the rationale is that ɢ is semantically different because it is used in IPA. I find that pretty weak, considering the ubiquity of smallcaps. Asking browsers to diverge (as far as equivalence goes) from Unicode standards sounds a lot like a failure of Unicode.

Re: Watch out: ɢoogle.com isn’t the same as Google.com

#109

Post by deegles »

mcv wrote: post #11
Entangled wrote: post #3

Web browsers should have an option to show non-ascii chars in urls in red.

This would be a great solution. Allowing unicode characters in domain names is just inviting trouble. I understand that people with non-Latin scripts want domain names in their own language and alphabet, but there are way too many unicode characters that will confuse people about legitimate-looking domain names. Showing non-ascii in red would be an easy solution for everybody.

It's not a great solution since it requires knowing the difference between ASCII and Unicode... I would argue that a user who is vulnerable to falling for unicode characters in domain names won't have that knowledge.

Re: Watch out: ɢoogle.com isn’t the same as Google.com

#110

Post by a3n »

witty_username wrote: post #105
a3n wrote: post #89

Earlier quoted context omitted.

Don't even show the suspect URL, show "THIS MIGHT BE A SCAM", with some kind of hover over showing the URL, and some way to click to more information.

Why? Non-latin alphabet domain names do have legitimate uses, although they are very rarely used.

For the same reason that my email client occasionally tells me "this may be a scam," even though sometimes it's not and I act accordingly. Based on whatever criteria it's using, the data received has a somewhat higher chance of being illegitimate.

We as (technical) humans can recognize (hence this discussion) that the use of this uncommon G is meant to mislead you into thinking you're going to Google, when in fact you're going to Hell. I'd like to be warned of that possibility.

In this case, the extremely oversimplified algorithm might be "does the domain, as filtered down to canonical characters, represent one of the top five destination domains, yet go somewhere else if not canonicalized?"

Post reply on HN