I hadn't seen one of the new unicode domains outside of Asian script before, and thus didn't have any mental correlation between the written version and the domain name. But that domain has a lot more letters than does the HN summary text next to the link.
Bizarrely enough, my Chrome 41 doesn't render the address bar with the unicode flavor, either. Firefox 36 renders it correctly in the status bar (link hover) as well as the address bar.
Yes, I but I knew that the coding scheme existed but hadn't until today found one that was encoded from a latin script. I also found the different browser implementations striking.
> To make the encoding and decoding algorithms simple, ...
Bahahah, thanks I needed some laughs today.
> the domain name string is assumed to have been normalized using Nameprep and (for top-level domains) filtered against an officially registered language table
I had no idea there was such a thing as a language table for domains, but interestingly enough the IDN repository[0] doesn't include ".fr" nor does ".com" include French (".ca" does[1]).
All the browser vendors handle IDNs a little differently to combat visual spoofing issues.
Chrome only shows the Unicode version of an IDN if all the letters appear in one of the languages you've told Chrome you read. So, if you add French to your list of languages, Chrome will show the "real" Unicode domain name instead of the Punycode.
Interestingly enough, Chrome is the odd-browser-out on this one (err, I didn't check IE cause I don't have one handy, so let's just assume they do things wrong and move on). Safari 7.1 also behaves like Firefox and (IMHO) does the correct thing. It is just silly that Chrome thinks I can't handle méric in my address bar because I don't browse in French.
As another interesting observation, Chrome on Android does as Chrome desktop does (Firefox Android similarly to its desktop companion), but the "Internet", which I presume is just fancy trimmings around the Web View component in Android, behaves like all the non-Chrome engines and renders the e-acute on 4.4.4. I just got my Android 5 update this weekend on my tablet, which brought with it a revamped Web View component so it's likely going to behave like Chrome does. I'll try to remember to check it.
> It is just silly that Chrome thinks I can't handle méric in my address bar
To rephrase GP post, it's because they think you can't handle: https://www.bankofamérica.com. Well, you probably can, mostly. On a retina screen, my eyes aren't good enough to spot the difference when the "i" is accented.
The Chrome team's decision seems a reasonable compromise to me.
I thought that too initially, but this appears to be a much faster method. For comparision, the "blackjack" attack uses 18 packets vs. 11000 for brute-force. I think we can say WPS is fairly unsafe at this point.
The writing style on this post is so bad I almost didn't make it to the end. Random distracting comments and grammar that looks like Google translate... Fortunately I was so curious about the attack I plowed through.
18 comments
[ 4.9 ms ] story [ 56.2 ms ] threadI hadn't seen one of the new unicode domains outside of Asian script before, and thus didn't have any mental correlation between the written version and the domain name. But that domain has a lot more letters than does the HN summary text next to the link.
Bizarrely enough, my Chrome 41 doesn't render the address bar with the unicode flavor, either. Firefox 36 renders it correctly in the status bar (link hover) as well as the address bar.
http://en.wikipedia.org/wiki/Punycode
> To make the encoding and decoding algorithms simple, ...
Bahahah, thanks I needed some laughs today.
> the domain name string is assumed to have been normalized using Nameprep and (for top-level domains) filtered against an officially registered language table
I had no idea there was such a thing as a language table for domains, but interestingly enough the IDN repository[0] doesn't include ".fr" nor does ".com" include French (".ca" does[1]).
0 = http://www.iana.org/domains/idn-tables
1 = http://www.iana.org/domains/idn-tables/tables/ca_fr_1.0.html
Chrome only shows the Unicode version of an IDN if all the letters appear in one of the languages you've told Chrome you read. So, if you add French to your list of languages, Chrome will show the "real" Unicode domain name instead of the Punycode.
As another interesting observation, Chrome on Android does as Chrome desktop does (Firefox Android similarly to its desktop companion), but the "Internet", which I presume is just fancy trimmings around the Web View component in Android, behaves like all the non-Chrome engines and renders the e-acute on 4.4.4. I just got my Android 5 update this weekend on my tablet, which brought with it a revamped Web View component so it's likely going to behave like Chrome does. I'll try to remember to check it.
To rephrase GP post, it's because they think you can't handle: https://www.bankofamérica.com. Well, you probably can, mostly. On a retina screen, my eyes aren't good enough to spot the difference when the "i" is accented.
The Chrome team's decision seems a reasonable compromise to me.
Edit: Just saw the authors notes that this may have been found before... If anyone is curious, I found the one of the original reports on this:
https://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf
1. A .fr domain
2. The rest of the site is in French
I guess we're getting so used to English dominance now.