Live data from Hacker News

Hidden Messages in Emojis and Hacking the US Treasury

slamdunksoftware.substack.com

81–82 of 82 posts

Re: Hidden Messages in Emojis and Hacking the US Treasury

#81
post #77
post #59

Earlier quoted context omitted.

I have had a developer look me dead in the eye and say "this is not a security concern, because I can't see how this can be exploited". Security by obscurity from self. It was very hard to explain to that person what was wrong with that line of reasoning.

But... You have to see things that way or else literally everything becomes a security concern.. Extra whitespace before a semicolon? I don't see how it can be exploited, but with the mindset you imply, I have to treat it as a security concern. But removing the whitespace is also a security concern.

Yes, general computers are fundamentally unsafe. We should always think about threat models, vulnerabilities, blast radii, defense in depth.

What we should never do is dismiss something as a non-concern because we don't know how it could be a problem. Especially when someone is trying to point out something we're doing is extensively documented as a security concern. In that case it would be quite obtuse to claim in a public discussion that the person pointing it out is wrong because you don't understand the issue, and yet I have lived through that.

Re: Hidden Messages in Emojis and Hacking the US Treasury

#82
post #79
post #52

Earlier quoted context omitted.

The cleverness is in the simplicity of its implementation while maintaining backwards compatibility. Which satisfies the definition of “elegance”. Working with Unicode is anything but elegant, but that’s another story.

> Working with Unicode is anything but elegant, but that’s another story. Yeah I hear ya. IMO this is really important though and I don’t think there’s much of a story if this isn’t part of it. The design is clever but the resulting usability (and error proneness) leaves much to be desired. Not knowing what’s in there, like a closed envelope, increases user complexity significantly.

You do know what’s inside a Unicode string though. They’re not hard to parse. Very easy in fact.

The biggest problem with Unicode parsing is that you don’t know how long a Unicode string is without parsing it. Which often leads to double parsing it. But we’d have this problem even with Unicode fixed to 2 or 4 bytes (like utf-16 and utf-32) because not all glyphs are going to be printable characters (eg accents).

…or you allow for every possible combination of characters, accents, etc and fixed at specific number of bytes and then suddenly you have a 6 or 8 byte character set that breaks backwards compatibility with ASCII and increases global network throughput by six times despite that mostly being empty space, while increase a greater burden on font developers to cater for every subtle variation of glyphs.

Sure things seem messy now, but I honestly think utf-8 is the least worst solution to the problem.

Post reply on HN