A critique of the fragility and impracticality of modern smartphones, urging a
shift toward more durable, repairable designs, and a call for manufacturers
and users alike to prioritize function over aesthetics.
While that’s a reasonable take, I think you could selectively render domains in non-latin scripts while blacklisting those greek/cyrillic letters that match latin ones, falling back to the “燋.com” formatting. Though I guess that would be a lot harder.
From the devs’ perspective, the relevant question will be this: How hard is it to map out all the lookalikes, and just how important is it to render foreign domains properly?"
To clarify, I meant that from the devs’ perspective: The effort of individually vetting every single character for possible confusion is immense, and the end result would still be just as western-centric. Imagine having a domain name in Greek where some characters are replaced because they might be confused for Latin characters. Or, conversely, having a few characters replaced by similar Latin ones for an attack, which your solution wouldn’t catch.
The result would also still be unreliable even for Westerners. If some other character set you didn’t vet also contains similar looking characters, there’s a new surface for attack.
To properly close that security gap would be an immense arms race… or you could simply shut down the entire attack vector.
So when you consider the importance of protecting gullible people from insidious attacks and the complexity of trying to allow non-Latin characters without creating openings, the question “How widespread are non-Latin URLs in my target audience and is it critical that they be rendered in their native script?” becomes a calculation of cost and benefit.
It’s a shit compromise to deal with the shit fact that some people being assholes ruins good things for the rest of us who aren’t.
I assume it’s done that way to prevent an IDN homograph attack.
For example if I sent you a link to “gооgle.com” you’d be like, sure. Except that isn’t a link to “google” it’s a link to “gооgle.com”.
While that’s a reasonable take, I think you could selectively render domains in non-latin scripts while blacklisting those greek/cyrillic letters that match latin ones, falling back to the “燋.com” formatting. Though I guess that would be a lot harder.
From the devs’ perspective, the relevant question will be this: How hard is it to map out all the lookalikes, and just how important is it to render foreign domains properly?"
This is such a western-centric take, and it makes me quite sad…
To clarify, I meant that from the devs’ perspective: The effort of individually vetting every single character for possible confusion is immense, and the end result would still be just as western-centric. Imagine having a domain name in Greek where some characters are replaced because they might be confused for Latin characters. Or, conversely, having a few characters replaced by similar Latin ones for an attack, which your solution wouldn’t catch.
The result would also still be unreliable even for Westerners. If some other character set you didn’t vet also contains similar looking characters, there’s a new surface for attack.
To properly close that security gap would be an immense arms race… or you could simply shut down the entire attack vector.
So when you consider the importance of protecting gullible people from insidious attacks and the complexity of trying to allow non-Latin characters without creating openings, the question “How widespread are non-Latin URLs in my target audience and is it critical that they be rendered in their native script?” becomes a calculation of cost and benefit.
It’s a shit compromise to deal with the shit fact that some people being assholes ruins good things for the rest of us who aren’t.
All of your points are quite valid. Personally, I would go for a whitelist over a blacklist.