▲ 252 ▼ Smartphones are Designed to Fail Us (and We Have to Change That) (マリウス.com) submitted 1 year ago by mesamunefire@piefed.social to c/technology@lemmy.world 78 comments fedilink hide all child comments
[–] princessnorah@lemmy.blahaj.zone 23 points 1 year ago (7 children) This is how it's supposed to look, wish Lemmy/Voyager did a better job here: permalink fedilink source parent hideshow 7 child comments replies: [–] MimicJar@lemmy.world 4 points 1 year ago (6 children) 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 "xn--ggle-55da.com". permalink fedilink source parent hideshow 6 child comments replies: [–] princessnorah@lemmy.blahaj.zone 1 point 1 year ago (5 children) 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 "xn--xxx.com" formatting. Though I guess that would be a lot harder. permalink fedilink source parent hideshow 5 child comments replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago (4 children) 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?" permalink fedilink source parent hideshow 4 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (3 children) ...and just how important is it to render foreign domains properly? This is such a western-centric take, and it makes me quite sad... permalink fedilink source parent hideshow 3 child comments replies: [–] lennivelkant@discuss.tchncs.de 3 points 1 year ago (2 children) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (1 child) All of your points are quite valid. Personally, I would go for a whitelist over a blacklist. permalink fedilink source parent hideshow 1 child comment replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago For some character sets with a lot of different characters like the Han Unicode representation, that could be cumbersome. Granted, Han might not be a great risk for confusion so you might just whitelist them collectively, but my point is that the approach would have to be more nuanced and complex. Ultimately, humans are complex and so are their languages. permalink fedilink source parent
[–] MimicJar@lemmy.world 4 points 1 year ago (6 children) 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 "xn--ggle-55da.com". permalink fedilink source parent hideshow 6 child comments replies: [–] princessnorah@lemmy.blahaj.zone 1 point 1 year ago (5 children) 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 "xn--xxx.com" formatting. Though I guess that would be a lot harder. permalink fedilink source parent hideshow 5 child comments replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago (4 children) 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?" permalink fedilink source parent hideshow 4 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (3 children) ...and just how important is it to render foreign domains properly? This is such a western-centric take, and it makes me quite sad... permalink fedilink source parent hideshow 3 child comments replies: [–] lennivelkant@discuss.tchncs.de 3 points 1 year ago (2 children) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (1 child) All of your points are quite valid. Personally, I would go for a whitelist over a blacklist. permalink fedilink source parent hideshow 1 child comment replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago For some character sets with a lot of different characters like the Han Unicode representation, that could be cumbersome. Granted, Han might not be a great risk for confusion so you might just whitelist them collectively, but my point is that the approach would have to be more nuanced and complex. Ultimately, humans are complex and so are their languages. permalink fedilink source parent
[–] princessnorah@lemmy.blahaj.zone 1 point 1 year ago (5 children) 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 "xn--xxx.com" formatting. Though I guess that would be a lot harder. permalink fedilink source parent hideshow 5 child comments replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago (4 children) 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?" permalink fedilink source parent hideshow 4 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (3 children) ...and just how important is it to render foreign domains properly? This is such a western-centric take, and it makes me quite sad... permalink fedilink source parent hideshow 3 child comments replies: [–] lennivelkant@discuss.tchncs.de 3 points 1 year ago (2 children) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (1 child) All of your points are quite valid. Personally, I would go for a whitelist over a blacklist. permalink fedilink source parent hideshow 1 child comment replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago For some character sets with a lot of different characters like the Han Unicode representation, that could be cumbersome. Granted, Han might not be a great risk for confusion so you might just whitelist them collectively, but my point is that the approach would have to be more nuanced and complex. Ultimately, humans are complex and so are their languages. permalink fedilink source parent
[–] lennivelkant@discuss.tchncs.de 2 points 1 year ago (4 children) 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?" permalink fedilink source parent hideshow 4 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (3 children) ...and just how important is it to render foreign domains properly? This is such a western-centric take, and it makes me quite sad... permalink fedilink source parent hideshow 3 child comments replies: [–] lennivelkant@discuss.tchncs.de 3 points 1 year ago (2 children) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (1 child) All of your points are quite valid. Personally, I would go for a whitelist over a blacklist. permalink fedilink source parent hideshow 1 child comment replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago For some character sets with a lot of different characters like the Han Unicode representation, that could be cumbersome. Granted, Han might not be a great risk for confusion so you might just whitelist them collectively, but my point is that the approach would have to be more nuanced and complex. Ultimately, humans are complex and so are their languages. permalink fedilink source parent
[–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (3 children) ...and just how important is it to render foreign domains properly? This is such a western-centric take, and it makes me quite sad... permalink fedilink source parent hideshow 3 child comments replies: [–] lennivelkant@discuss.tchncs.de 3 points 1 year ago (2 children) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (1 child) All of your points are quite valid. Personally, I would go for a whitelist over a blacklist. permalink fedilink source parent hideshow 1 child comment replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago For some character sets with a lot of different characters like the Han Unicode representation, that could be cumbersome. Granted, Han might not be a great risk for confusion so you might just whitelist them collectively, but my point is that the approach would have to be more nuanced and complex. Ultimately, humans are complex and so are their languages. permalink fedilink source parent
[–] lennivelkant@discuss.tchncs.de 3 points 1 year ago (2 children) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (1 child) All of your points are quite valid. Personally, I would go for a whitelist over a blacklist. permalink fedilink source parent hideshow 1 child comment replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago For some character sets with a lot of different characters like the Han Unicode representation, that could be cumbersome. Granted, Han might not be a great risk for confusion so you might just whitelist them collectively, but my point is that the approach would have to be more nuanced and complex. Ultimately, humans are complex and so are their languages. permalink fedilink source parent
[–] princessnorah@lemmy.blahaj.zone 2 points 1 year ago (1 child) All of your points are quite valid. Personally, I would go for a whitelist over a blacklist. permalink fedilink source parent hideshow 1 child comment replies: [–] lennivelkant@discuss.tchncs.de 2 points 1 year ago For some character sets with a lot of different characters like the Han Unicode representation, that could be cumbersome. Granted, Han might not be a great risk for confusion so you might just whitelist them collectively, but my point is that the approach would have to be more nuanced and complex. Ultimately, humans are complex and so are their languages. permalink fedilink source parent
[–] lennivelkant@discuss.tchncs.de 2 points 1 year ago For some character sets with a lot of different characters like the Han Unicode representation, that could be cumbersome. Granted, Han might not be a great risk for confusion so you might just whitelist them collectively, but my point is that the approach would have to be more nuanced and complex. Ultimately, humans are complex and so are their languages. permalink fedilink source parent