3 ms·

HN shows it before de-punycoding (punydecoding?), which if you're not familiar with Punycode, does indeed look a bit "spooky."

Aeolun 5y ago
Even after accessing the link from HN the domain looks exactly the same in my browser. Even if it is punycoding, I’m not sure how one would distinguish the actual domain from the coded one (unless you know the specific format convention that punycode follows).
DarylZero 5y ago
Because HN sucks as a web site.
tjpnz 5y ago
Had to look up punydecoding (おもしろいですね!). Any reason why it's applied to kana when HN displays it just fine in comments?
- csnover 5y ago
  The punycode representation of the domain name is the “true” representation, HN just doesn’t detect that and convert it from punycode to Unicode. This may be unintentional, or it may be to avoid homoglyph attacks.
- spijdar 5y ago
  DNS is generally restricted to a subset of the ASCII character set. While this isn't a strict limitation of DNS, there are enough DNS servers, clients, and applications using DNS that break on non-ASCII sequences that it's a de-facto standard. In place of storing Unicode inside DNS, Unicode sequences outside RFC 952 (ASCII alphanumerics, case-insensitive, along with '-' and '.' characters) are encoded into RFC 952 compatible hostnames using Punycode, and stored thus in DNS. Here in HN comments, Unicode is just embedded as actual UTF-8, no strange DNS encoding needed. The hostname, however, is actually xn--gckvb8fzb.com, hence why it's displayed as such. (your browser will automatically convert from whatever encoding to Punycode where appropriate, so a link like https://マリウス.com https://xn--gckvb8fzb.com (should) work correctly, but the actual hostname lookup performed on the wire is for xn--gckvb8fzb.com) Edit: well, HN also converts my Unicode hyperlink into the punycode equivalent. Interesting. It preserves the original encoding when I go back to edit the comment, but displays the Punycode form everywhere else. This gives credence to the idea this is intentional to avoid homoglyph attacks, as csnover states.

Aeolun 5y ago

Even after accessing the link from HN the domain looks exactly the same in my browser. Even if it is punycoding, I’m not sure how one would distinguish the actual domain from the coded one (unless you know the specific format convention that punycode follows).

DarylZero 5y ago

Because HN sucks as a web site.

tjpnz 5y ago

Had to look up punydecoding (おもしろいですね!). Any reason why it's applied to kana when HN displays it just fine in comments?

csnover 5y ago
The punycode representation of the domain name is the “true” representation, HN just doesn’t detect that and convert it from punycode to Unicode. This may be unintentional, or it may be to avoid homoglyph attacks.
spijdar 5y ago
DNS is generally restricted to a subset of the ASCII character set. While this isn't a strict limitation of DNS, there are enough DNS servers, clients, and applications using DNS that break on non-ASCII sequences that it's a de-facto standard. In place of storing Unicode inside DNS, Unicode sequences outside RFC 952 (ASCII alphanumerics, case-insensitive, along with '-' and '.' characters) are encoded into RFC 952 compatible hostnames using Punycode, and stored thus in DNS. Here in HN comments, Unicode is just embedded as actual UTF-8, no strange DNS encoding needed. The hostname, however, is actually xn--gckvb8fzb.com, hence why it's displayed as such. (your browser will automatically convert from whatever encoding to Punycode where appropriate, so a link like https://マリウス.com https://xn--gckvb8fzb.com (should) work correctly, but the actual hostname lookup performed on the wire is for xn--gckvb8fzb.com) Edit: well, HN also converts my Unicode hyperlink into the punycode equivalent. Interesting. It preserves the original encoding when I go back to edit the comment, but displays the Punycode form everywhere else. This gives credence to the idea this is intentional to avoid homoglyph attacks, as csnover states.