20 ms·

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

222 points by helstegt 6y ago

diggan 6y ago
As a funny side note, I cannot load https://coronaprøver.dk/ 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 by this. My comment now says "xn-coronoprver-ngb" when viewed from the outside, but my comment field correctly says "coronaprøver" when editing the comment...
- teddyh 6y ago
  What’s the problem? That certificate is only valid for coronaprover.dk, not coronaprøver.dk or xn--coronaprver-ngb.dk.
  - diggan 6y ago
    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.
    - Svip 6y ago
      That's not my experience. Going to https://coronaprøver.dk/ https://xn--coronaprver-ngb.dk/ in Firefox presents the invalid certificate, but going to http://coronaprøver.dk/ http://xn--coronaprver-ngb.dk/ redirects me to https://www.coronaprover.dk/ https://www.coronaprover.dk/. It seems Brave always tries with https, and thus it fails. Not that it is confused by IDN.
      - kevincox 6y ago
        The link provided was https:// https:// so it would be a serious security issue if it downgraded to http. It is the website that is broken (or at least does not support that link).
        helstegt 6y ago
        I used coronaprøver.dk to illustrate the point. The more authoritative URL is coronaprover.dk and coronaprøver.dk is registered to prevent domain squatting/phishing attempts. Although they probably should have made a solution without certificate errors.
        deleted 6y ago
        [deleted]
    - robjan 6y ago
      I just successfully navigated to that site in Brave. The only problem was that I had to accept the invalid certificate.
- nottorp 6y ago
  My Firefox complains about the certificate too.
  - tsimionescu 6y ago
    Yes, because the certificate is not valid for the site they linked to - it's only valid for the ASCII-named site. Everything seems to be working as intended here on the browser side.
- lqet 6y ago
  Same in Chromium.
jansommer 6y ago
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 entire country is unable to pay in the web app using their de facto credit card.
- smt88 6y ago
  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, which seems like it would bypass the issue you're describing), the affected population is probably really small. Then you also have to consider that most of Tinder's paying users are heterosexual men, and they know that they can screw those men over without losing their business because Tinder is an irreplaceable marketplace to find women. With all those assumptions, Tinder isn't being as stupid as they sound, but rather coldly rational.
  - johannes1234321 6y ago
    The question is what the cost of that fix would be. Once the ticket reaches the developer it's probably quickly done and pays for itself with a handful registrations. However getting from support to a developer is the complex part. (Support has to understand the issue and then it has to be routed to the correct team ...)
    - smt88 6y ago
      I completely understand why you see this as a 30-min fix, and therefore they should just knock it out. That's not how they would likely see it. If their devs are 100% utilized (which I'm sure they are), then fixing any issue -- even a 30-min one -- is going to mean that a different issue is delayed. The question becomes this: at what point is fixing this issue more valuable to the company than any other issue the same dev could work on? And the answer is possibly "never", depending on what high-impact bugs, features, or technical debt they have on their priority list.
zeepzeep 6y ago
> tried e-mailing their security e-mail (no reply) No wonder, it's not a security issue. At least not yet, have you tried injecting new-lines?
- helstegt 6y ago
  Totally agree. It was just the only e-mail I could find and I was pessimistic about having the issue escalated through customer support. I think Vegard tried his best to help me, though. Once I got the problem escalated, I naively thought they were actually going to fix it.
  - deleted 6y ago
    [deleted]
dandare 6y ago
+1 for leading me to https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode, I had no idea this monstrosity exists :)
- josteink 6y ago
  I have a few such domains registered for (valid!) vanity domains and emails. Amount of people using them? Slim. Amount of email-clients confused? Depressing.
SahAssar 6y ago
This is actually one of the lazy ways to deal with https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack The better way would probably be to use chromes list of when to allow IDN and when to convert to punycode: https://chromium.googlesource.com/chromium/src/+/master/docs/idn.md https://chromium.googlesource.com/chromium/src/+/master/docs...
halite 6y ago
This is the problem I had in mind when building https://chota.link https://chota.link. I have seen too many broken previews. This little app lets you create short link and specify metatags. Try this short link on LinkedIn: https://chota.link/jVZ2Hd https://chota.link/jVZ2Hd. I tested it and seems to be working.
- 101008 6y ago
  Any reason on the name? Chota is a despective way to say "Penis" in South America.
  - kroltan 6y ago
    Interesting, in (southern?) Brazil it refers to the female genital.
    - halite 6y ago
      In Hindi, Chota means short...
  - halite 6y ago
    In Hindi, Chota means short. Apologies to South Americans.
realusername 6y ago
There are also issues with their preview image cache, it's been broken for at least three years already but they still haven't fixed it... Once your url has the wrong image, good luck updating it, you might as well redirect everybody to a new url.
ricardo81 6y ago
"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 understand it, the solution is on a per TLD basis, as in different dictionaries and rules per TLD. For 3rd parties like LinkedIn, I could understand why they may be averse to embracing IDN domains but for a company of their size and reach, they really should be looking after their wider user base. For working with IDN domains, I've felt the easiest way to store/process them is to store them as their ASCII value and convert for human consumption. Tried hunting for a C library that deals with the dictionary issues and was left not entirely sure whether libidn supports them.
- buckminster 6y ago
  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.
  - ricardo81 6y ago
    Yeah, perhaps less important for LinkedIn but more pertinent for other parties like domain registrars and TLS cert issuers- apparently the 'rules' ala the registry's DNS is an evolving thing. https://www.theregister.com/2020/03/04/homograph_attacks_still_happening/ https://www.theregister.com/2020/03/04/homograph_attacks_sti... Ignoring the specific characters without a local frame of reference would require at least a DNS lookup.
  - tinus_hn 6y ago
    This kind of tricks is used by sending mail to users with legitimate looking links, which can be used for phishing.
- BlueTemplar 6y ago
  Am I misunderstanding or are you looking for Unicode normalization? http://site.icu-project.org/design/normalization/custom http://site.icu-project.org/design/normalization/custom
lordnacho 6y ago
Well it would be nice it it were fixed, but aren't people in Denmark wary of using the three special characters æ, ø and å for this reason? IIRC it's normal to have borsen.dk instead of børsen.dk, Denmark's equivalent of the FT. And probably a few others as well, I'd expect any website connected to Århus to use some other similar spelling. Also LinkedIn doesn't seem very easy to deal with in general. I've been trying to find a way to categorize my contacts since forever (personal/business/school), but there doesn't seem to be a way. All the boards where people write have some rep pasting in a standard non-answer.
- Cthulhu_ 6y ago
  They shouldn't have to be though; internationalized domain names have been a standard for a decade now. Browsers, DNS servers and web servers should be on top of that. I mean sure, 10+ years ago they would have used plain ascii domain names, but nowadays they should be free to user their own language and script. At least two thirds of the world population and internet users does not use latin script.
  - lopmotr 6y ago
    Everyone uses Latin script because too much depends on it. Even "https" and ".dk". Localized scripts are exclusionary to everyone else who has no hope of typing them or even identifying them in a unicode table to copy and paste. A funny situation happens in China where even the most computer illiterate old person can type latin letters on a PC with enough patience just by matching appearance to their keyboard, but many old people are utterly blocked from typing Chinese characters because that requires learning a special input method which is almost a whole nother language itself. Before smartphones, they had to write them with a stylus on a writing tablet to get around this problem. Half the English alphabet is excluded from domain names too. When are we getting capital letters? Let's just tolerate never having them and not worry, same as those other languages' odd letters. ExpertSexChange.com and PenisLand.net could use them.
    - jobigoud 6y ago
      > Localized scripts are exclusionary to everyone else It's the other way around, not supporting other letters is excluding everyone else because essentially only English doesn't have diacritics. "Año" and "ano" are not the same word, degrading to ascii only is not an acceptable solution. Imagine for example that the letters 'd', 'q' and 'w', weren't availabe in domain names for some reason and you had to use alternatives. That's how it feels.
an_opabinia 6y ago
The problem is, LinkedIn thinks they don’t have customer support or bug reporting, when really they just delegated it to social media.
nottorp 6y ago
At some point Linkedin changed their site from something that at least worked to some javascript that i can actually watch loading and assembling the page because it's so slow. And you expect ... support for internationalized domain names?
- mhh__ 6y ago
  When this happens is it literally just companies trying to save money so they only need to hire JS developers? Or are static sites not webscale anymore? The web framework I use for my personal stuff just takes templates in and fills it with whatever a request requires, and it's definitely easier than dealing with JS wat-isms.
  - IggleSniggle 6y ago
    I think it’s more related to “tribes” than anything else. A great designer that can do passable js is going to be more valuable to a company on the front end, and a great dev that does quality work that will last for 5 years without refactoring is more valuable to a company on the backend, while a great “full stack” engineer is more valuable to the company helping multiple teams in a DevOps role. Not to mention that those folks will naturally gravitate towards those distinct roles. Over time, the frontend design types will want more control over what they can and can’t do userland, and nobody else gives a damn because it doesn’t affect their day-to-day and in many cases makes their codebase cleaner / more “pure” because UI concerns get really messy for a variety of reasons. It also generally feels safest to a company to put junior programmers on the frontend where even if they mess something up, at least the whole underlying system won’t be hosed. That allows juniors and mids to build chops more rapidly. Anyway that’s all just my anecdata / speculation.
  - matttb 6y ago
    Pretty sure it's just to combat scraping
    - nottorp 6y ago
      ... or combat people, you know, actually checking their linkedin accounts once in a while? I'm not actively looking for a job. I used to check linkedin randomly like twice per week to see what happens. After their new slow motion interface, that changed to once every 3 months. Sorry, recruiters with incredible opportunities.
klodolph 6y ago
Working with internationalized URLs (IRIs) is a Cursed Problem. Here is the IRI for the Wikipedia page on semiconductors. When you click on it, it should show you a page with a picture of a silicon wafer on the left. https://ar.wikipedia.org/wiki/شبه_موصل https://ar.wikipedia.org/wiki/شبه_موصل Now try copy/pasting that link text into different web apps and see how they respond. HN seems to handle it correctly. Twitter doesn’t, it considers شبه_موصل to be just some extra text after the URL.
- toast0 6y ago
  That's really a problem of picking up a url/uri/iri in text without delimeters. You see the same thing when there's 'uncommon' ascii characters in urls, like a trailing period, or commas or exclamation points. The proper thing to do is to enclose links in <>, as was done in well-formed email, but that wasn't super consistent either, and it hasn't transitioned to the world conciousness.
  - klodolph 6y ago
    I don’t want to rely on users figuring out how to use delimiters. If the URIs with trailing periods break, so be it, people can use <>, but don’t make people use <> just because the URL isn’t English.
- kevsim 6y ago
  So I just tried pasting this into the editor for the issue tracker I work on [0]. When I traverse the URL from left to right with the keyboard cursor it goes as "normal" up to the the last / then jumps to the end, then traverses "backwards" then jumps back to the end. Is this right or do we have a bug? Mixing LTR and RTL is super confusing. Does recognize it as a link just fine though. 0: https://kitemaker.co https://kitemaker.co
  - sangnoir 6y ago
    That sounds correct to me, but there's no canonical answer. The question is, do you want to change keyboard cursor context from "next character" mid-sentence from LTR to RTL? If you do that, the cursor will get "stuck" at the word boundary where next and previous mean the same thing (left is both "prev" for LTR and "next" for RTL - how should the computer interpret that?)
ajb413 6y ago
I had a similar problem on LinkedIn when I tried to share an SDK I was working on. It's called Compound.js. The post editor thought that "Compound.js" is a URL, which 404ed, breaking the post preview, which was supposed to link to the actual URL which was later in the post body.
misanthropic 6y ago
I remember when I tried to buy a DNA test at 23andme, and they failed to parse my email that was in a form xxx@yyy.zzz.org . They couldn't, and their support suggested using a hotmail address. That's where I got really suspicious of their overall competence, not only IT, and found another DNA test provider.
Tainnor 6y ago
Some people here are claiming that it's just not worth for big companies to invest in such "niche" bugs for "small markets". But I think it's more than that. I think many US-based companies seriously underestimate difficult issues such as localisation or fail to understand phenomena such as multilingualism. I think this creates a lot of problems for international markets, but somehow these problems are probably not very visible. For example, why is it that I can't see reviews in multiple languages on the Play Store? This would be valuable information both for customers as well as for developers who speak multiple languages.
fortunajs 6y ago
I found this kind of intervention positive - this seems an effective way to prevent multiple phishing attempts & misinformation.
tester756 6y ago
I too would try hard to not having to rewrite url parser I bet things can get batshit crazy and introduce some vulns

222 points by helstegt 6y ago

As a funny side note, I cannot load https://coronaprøver.dk/ 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 by this. My comment now says "xn-coronoprver-ngb" when viewed from the outside, but my comment field correctly says "coronaprøver" when editing the comment...

teddyh 6y ago
What’s the problem? That certificate is only valid for coronaprover.dk, not coronaprøver.dk or xn--coronaprver-ngb.dk.
- diggan 6y ago
  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.
  - Svip 6y ago
    That's not my experience. Going to https://coronaprøver.dk/ https://xn--coronaprver-ngb.dk/ in Firefox presents the invalid certificate, but going to http://coronaprøver.dk/ http://xn--coronaprver-ngb.dk/ redirects me to https://www.coronaprover.dk/ https://www.coronaprover.dk/. It seems Brave always tries with https, and thus it fails. Not that it is confused by IDN.
    - kevincox 6y ago
      The link provided was https:// https:// so it would be a serious security issue if it downgraded to http. It is the website that is broken (or at least does not support that link).
      - helstegt 6y ago
        I used coronaprøver.dk to illustrate the point. The more authoritative URL is coronaprover.dk and coronaprøver.dk is registered to prevent domain squatting/phishing attempts. Although they probably should have made a solution without certificate errors.
        deleted 6y ago
        [deleted]
  - robjan 6y ago
    I just successfully navigated to that site in Brave. The only problem was that I had to accept the invalid certificate.
nottorp 6y ago
My Firefox complains about the certificate too.
- tsimionescu 6y ago
  Yes, because the certificate is not valid for the site they linked to - it's only valid for the ASCII-named site. Everything seems to be working as intended here on the browser side.
lqet 6y ago
Same in Chromium.

jansommer 6y ago

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 entire country is unable to pay in the web app using their de facto credit card.

smt88 6y ago
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, which seems like it would bypass the issue you're describing), the affected population is probably really small. Then you also have to consider that most of Tinder's paying users are heterosexual men, and they know that they can screw those men over without losing their business because Tinder is an irreplaceable marketplace to find women. With all those assumptions, Tinder isn't being as stupid as they sound, but rather coldly rational.
- johannes1234321 6y ago
  The question is what the cost of that fix would be. Once the ticket reaches the developer it's probably quickly done and pays for itself with a handful registrations. However getting from support to a developer is the complex part. (Support has to understand the issue and then it has to be routed to the correct team ...)
  - smt88 6y ago
    I completely understand why you see this as a 30-min fix, and therefore they should just knock it out. That's not how they would likely see it. If their devs are 100% utilized (which I'm sure they are), then fixing any issue -- even a 30-min one -- is going to mean that a different issue is delayed. The question becomes this: at what point is fixing this issue more valuable to the company than any other issue the same dev could work on? And the answer is possibly "never", depending on what high-impact bugs, features, or technical debt they have on their priority list.

zeepzeep 6y ago

> tried e-mailing their security e-mail (no reply) No wonder, it's not a security issue. At least not yet, have you tried injecting new-lines?

helstegt 6y ago
Totally agree. It was just the only e-mail I could find and I was pessimistic about having the issue escalated through customer support. I think Vegard tried his best to help me, though. Once I got the problem escalated, I naively thought they were actually going to fix it.
- deleted 6y ago
  [deleted]

dandare 6y ago

+1 for leading me to https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode, I had no idea this monstrosity exists :)

josteink 6y ago
I have a few such domains registered for (valid!) vanity domains and emails. Amount of people using them? Slim. Amount of email-clients confused? Depressing.

SahAssar 6y ago

This is actually one of the lazy ways to deal with https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack The better way would probably be to use chromes list of when to allow IDN and when to convert to punycode: https://chromium.googlesource.com/chromium/src/+/master/docs/idn.md https://chromium.googlesource.com/chromium/src/+/master/docs...

halite 6y ago

This is the problem I had in mind when building https://chota.link https://chota.link. I have seen too many broken previews. This little app lets you create short link and specify metatags. Try this short link on LinkedIn: https://chota.link/jVZ2Hd https://chota.link/jVZ2Hd. I tested it and seems to be working.

101008 6y ago
Any reason on the name? Chota is a despective way to say "Penis" in South America.
- kroltan 6y ago
  Interesting, in (southern?) Brazil it refers to the female genital.
  - halite 6y ago
    In Hindi, Chota means short...
- halite 6y ago
  In Hindi, Chota means short. Apologies to South Americans.

realusername 6y ago

There are also issues with their preview image cache, it's been broken for at least three years already but they still haven't fixed it... Once your url has the wrong image, good luck updating it, you might as well redirect everybody to a new url.

ricardo81 6y ago

"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 understand it, the solution is on a per TLD basis, as in different dictionaries and rules per TLD. For 3rd parties like LinkedIn, I could understand why they may be averse to embracing IDN domains but for a company of their size and reach, they really should be looking after their wider user base. For working with IDN domains, I've felt the easiest way to store/process them is to store them as their ASCII value and convert for human consumption. Tried hunting for a C library that deals with the dictionary issues and was left not entirely sure whether libidn supports them.

buckminster 6y ago
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.
- ricardo81 6y ago
  Yeah, perhaps less important for LinkedIn but more pertinent for other parties like domain registrars and TLS cert issuers- apparently the 'rules' ala the registry's DNS is an evolving thing. https://www.theregister.com/2020/03/04/homograph_attacks_still_happening/ https://www.theregister.com/2020/03/04/homograph_attacks_sti... Ignoring the specific characters without a local frame of reference would require at least a DNS lookup.
- tinus_hn 6y ago
  This kind of tricks is used by sending mail to users with legitimate looking links, which can be used for phishing.
BlueTemplar 6y ago
Am I misunderstanding or are you looking for Unicode normalization? http://site.icu-project.org/design/normalization/custom http://site.icu-project.org/design/normalization/custom

lordnacho 6y ago

Well it would be nice it it were fixed, but aren't people in Denmark wary of using the three special characters æ, ø and å for this reason? IIRC it's normal to have borsen.dk instead of børsen.dk, Denmark's equivalent of the FT. And probably a few others as well, I'd expect any website connected to Århus to use some other similar spelling. Also LinkedIn doesn't seem very easy to deal with in general. I've been trying to find a way to categorize my contacts since forever (personal/business/school), but there doesn't seem to be a way. All the boards where people write have some rep pasting in a standard non-answer.

Cthulhu_ 6y ago
They shouldn't have to be though; internationalized domain names have been a standard for a decade now. Browsers, DNS servers and web servers should be on top of that. I mean sure, 10+ years ago they would have used plain ascii domain names, but nowadays they should be free to user their own language and script. At least two thirds of the world population and internet users does not use latin script.
- lopmotr 6y ago
  Everyone uses Latin script because too much depends on it. Even "https" and ".dk". Localized scripts are exclusionary to everyone else who has no hope of typing them or even identifying them in a unicode table to copy and paste. A funny situation happens in China where even the most computer illiterate old person can type latin letters on a PC with enough patience just by matching appearance to their keyboard, but many old people are utterly blocked from typing Chinese characters because that requires learning a special input method which is almost a whole nother language itself. Before smartphones, they had to write them with a stylus on a writing tablet to get around this problem. Half the English alphabet is excluded from domain names too. When are we getting capital letters? Let's just tolerate never having them and not worry, same as those other languages' odd letters. ExpertSexChange.com and PenisLand.net could use them.
  - jobigoud 6y ago
    > Localized scripts are exclusionary to everyone else It's the other way around, not supporting other letters is excluding everyone else because essentially only English doesn't have diacritics. "Año" and "ano" are not the same word, degrading to ascii only is not an acceptable solution. Imagine for example that the letters 'd', 'q' and 'w', weren't availabe in domain names for some reason and you had to use alternatives. That's how it feels.

an_opabinia 6y ago

The problem is, LinkedIn thinks they don’t have customer support or bug reporting, when really they just delegated it to social media.

nottorp 6y ago

At some point Linkedin changed their site from something that at least worked to some javascript that i can actually watch loading and assembling the page because it's so slow. And you expect ... support for internationalized domain names?

mhh__ 6y ago
When this happens is it literally just companies trying to save money so they only need to hire JS developers? Or are static sites not webscale anymore? The web framework I use for my personal stuff just takes templates in and fills it with whatever a request requires, and it's definitely easier than dealing with JS wat-isms.
- IggleSniggle 6y ago
  I think it’s more related to “tribes” than anything else. A great designer that can do passable js is going to be more valuable to a company on the front end, and a great dev that does quality work that will last for 5 years without refactoring is more valuable to a company on the backend, while a great “full stack” engineer is more valuable to the company helping multiple teams in a DevOps role. Not to mention that those folks will naturally gravitate towards those distinct roles. Over time, the frontend design types will want more control over what they can and can’t do userland, and nobody else gives a damn because it doesn’t affect their day-to-day and in many cases makes their codebase cleaner / more “pure” because UI concerns get really messy for a variety of reasons. It also generally feels safest to a company to put junior programmers on the frontend where even if they mess something up, at least the whole underlying system won’t be hosed. That allows juniors and mids to build chops more rapidly. Anyway that’s all just my anecdata / speculation.
- matttb 6y ago
  Pretty sure it's just to combat scraping
  - nottorp 6y ago
    ... or combat people, you know, actually checking their linkedin accounts once in a while? I'm not actively looking for a job. I used to check linkedin randomly like twice per week to see what happens. After their new slow motion interface, that changed to once every 3 months. Sorry, recruiters with incredible opportunities.

klodolph 6y ago

Working with internationalized URLs (IRIs) is a Cursed Problem. Here is the IRI for the Wikipedia page on semiconductors. When you click on it, it should show you a page with a picture of a silicon wafer on the left. https://ar.wikipedia.org/wiki/شبه_موصل https://ar.wikipedia.org/wiki/شبه_موصل Now try copy/pasting that link text into different web apps and see how they respond. HN seems to handle it correctly. Twitter doesn’t, it considers شبه_موصل to be just some extra text after the URL.

toast0 6y ago
That's really a problem of picking up a url/uri/iri in text without delimeters. You see the same thing when there's 'uncommon' ascii characters in urls, like a trailing period, or commas or exclamation points. The proper thing to do is to enclose links in <>, as was done in well-formed email, but that wasn't super consistent either, and it hasn't transitioned to the world conciousness.
- klodolph 6y ago
  I don’t want to rely on users figuring out how to use delimiters. If the URIs with trailing periods break, so be it, people can use <>, but don’t make people use <> just because the URL isn’t English.
kevsim 6y ago
So I just tried pasting this into the editor for the issue tracker I work on [0]. When I traverse the URL from left to right with the keyboard cursor it goes as "normal" up to the the last / then jumps to the end, then traverses "backwards" then jumps back to the end. Is this right or do we have a bug? Mixing LTR and RTL is super confusing. Does recognize it as a link just fine though. 0: https://kitemaker.co https://kitemaker.co
- sangnoir 6y ago
  That sounds correct to me, but there's no canonical answer. The question is, do you want to change keyboard cursor context from "next character" mid-sentence from LTR to RTL? If you do that, the cursor will get "stuck" at the word boundary where next and previous mean the same thing (left is both "prev" for LTR and "next" for RTL - how should the computer interpret that?)

ajb413 6y ago

I had a similar problem on LinkedIn when I tried to share an SDK I was working on. It's called Compound.js. The post editor thought that "Compound.js" is a URL, which 404ed, breaking the post preview, which was supposed to link to the actual URL which was later in the post body.

misanthropic 6y ago

I remember when I tried to buy a DNA test at 23andme, and they failed to parse my email that was in a form xxx@yyy.zzz.org . They couldn't, and their support suggested using a hotmail address. That's where I got really suspicious of their overall competence, not only IT, and found another DNA test provider.

Tainnor 6y ago

Some people here are claiming that it's just not worth for big companies to invest in such "niche" bugs for "small markets". But I think it's more than that. I think many US-based companies seriously underestimate difficult issues such as localisation or fail to understand phenomena such as multilingualism. I think this creates a lot of problems for international markets, but somehow these problems are probably not very visible. For example, why is it that I can't see reviews in multiple languages on the Play Store? This would be valuable information both for customers as well as for developers who speak multiple languages.

fortunajs 6y ago

I found this kind of intervention positive - this seems an effective way to prevent multiple phishing attempts & misinformation.

tester756 6y ago

I too would try hard to not having to rewrite url parser I bet things can get batshit crazy and introduce some vulns