3 ms·
Browsers use heuristics here and display the punycode when it conflicts with a more "likely" domain: e.g. in the cross-script spoofing here: http://unicode.org/
by fiddlerwoaroof 6y ago
Browsers use heuristics here and display the punycode when it conflicts with a more "likely" domain: e.g. in the cross-script spoofing here: http://unicode.org/L2/L2004/04305-spoofing.html http://unicode.org/L2/L2004/04305-spoofing.html , Safari on macOS displays http://xn--tp-jbc.com http://xn--tp-jbc.com as "xn--tp-jbc.com" but http://xn--t-zfa.com http://xn--t-zfa.com as "ät.com"
- bluejekyll 6y agoSure, disambiguation is important, but do we need to do that at the serialization level? We increase the parsing and transformation costs in DNS, when it seems like what we really need is clear rules about what unicode values are legal and which are not. The example of umlaut is really good one though, as the umlaut can be an extra code point, or part of the actual character. I can see why we'd want to be explicit that both are not allowed in DNS... It still feels like we're solving this issue at the wrong layer, i.e. the protocol layer, as opposed to the application layer. I'm 100% in agreement on needing solutions here, but I think your example illustrates that it's a higher-order issue for applications, and not the protocol.