I failed to make LinkedIn fix their broken international domain URL parser

Post by YawningAngel » Mon, Nov 16, 2020, 3:46 PM UTC

jansommer wrote: post #3

I'm not surprised the author can't convince LinkedIn to change anything. Had a similar experience with Tinder where Paying in their web application using a danish credit card failed because their cc service returned "visadankort", which had to be changed to "visa" through the developer console for the payment to go through. Got tired of that and filed a bug. Oh the battle it took to actually convince them that an ent…

Post by nottorp » Mon, Nov 16, 2020, 3:49 PM UTC

diggan wrote: post #2

As a funny side note, I cannot load https://xn--coronaprver-ngb.dk/ in Brave, which also seems to be confused by Internationalised domain names. This is what I see: > This server could not prove that it is xn--coronaprver-ngb.dk; its security certificate is from *.coronaprover.dk. This may be caused by a misconfiguration or an attacker intercepting your connection. Edit: Hah! And HN is also guilty of being confused b…

Post by johannes1234321 » Mon, Nov 16, 2020, 3:55 PM UTC

smt88 wrote: post #18

jansommer wrote: post #3

I'm not surprised the author can't convince LinkedIn to change anything. Had a similar experience with Tinder where Paying in their web application using a danish credit card failed because their cc service returned "visadankort", which had to be changed to "visa" through the developer console for the payment to go through. Got tired of that and filed a bug. Oh the battle it took to actually convince them that an ent…

I'd have to assume "supporting Danish credit cards" is lower on their list of revenue-impacting issues than you expect. If Denmark were a US state, it wouldn't even be in the top 20 in terms of population. If you assume that Denmark has lower usage of Tinder than US, CA, or UK, and then you assume that not all Danish people are paying with Danish credit cards (many of them would be using Play Store subscriptions, whi…

Post by kevincox » Mon, Nov 16, 2020, 4:07 PM UTC

Svip wrote: post #11

diggan wrote: post #10

Earlier quoted context omitted.

The problem is that Brave fails when you navigate to "coronaprøver.dk" while both Chrome and Firefox works when you go there. Although Firefox and Chrome redirects to two different sites, they don't present a certificate error, while Brave does.

That's not my experience. Going to https://xn--coronaprver-ngb.dk/ in Firefox presents the invalid certificate, but going to http://xn--coronaprver-ngb.dk/ redirects me to https://www.coronaprover.dk/ . It seems Brave always tries with https, and thus it fails. Not that it is confused by IDN.

Post by ricardo81 » Mon, Nov 16, 2020, 4:23 PM UTC

buckminster wrote: post #24

ricardo81 wrote: post #13

"punycode" does seem to break a few things in userland, but obviously should exist for the web to be more useable in more languages. I've delved into the subject a bit and as someone else has mentioned, "homograph attacks" are a thing. Looking deeper, it seems each TLD has a set of dictionaries and rules for what is an acceptable combination of characters, and what isn't (to avoid homograph attacks)- and as I underst…

Why worry about the dictionaries? No legitimate user will accidentally enter a Greek Alpha rather than an A, for example. If a malicious user does this it won't resolve anyway because the domain is banned by the rules and can't be registered.