Good thread about the recent Unicode attacks and some previous work that predates it. I agree that citations could be improved. But I want to push back a little. 1/
What was interesting to me about the recent Unicode/Trojan attacks (link below) isn’t that Unicode contains some exploitable fluffery. *Of course* it does. Unicode is terrible. 2/ trojansource.codes
What was surprising to me is how many compilers, source management tools and IDEs were vulnerable to the attacks. I expected this from pomo languages like, say, Golang or Swift. But even compilers for ancient languages like C/C++ were happy to eat Unicode and not complain. 3/
This is a pretty common thing in infosec, where somebody says “that attack isn’t new, it’s been known for years” and then you look around and literally *everything* is still vulnerable to it. Maybe “new” isn’t what’s important. 4/
Over the past few days we’ve seen several advisories from compiler developers, source management systems and others. This is the result of a coordinated disclosure process, and, yes publicity process (with a website and logo!) That’s a good thing! 5/
To me what distinguishes this work is not “we found a vulnerability,” because the vulnerability is itself is fairly simple. But rather the effort that was put into classifying all the vulnerable tools and scanning for pre-existing exploitation. Thank god for grad students. 6/
With all those things said, crediting previous work is really important. And I think the citation here could be a lot more robust. 7/
Anyway, to conclude: we shouldn’t worry about 0days. We should worry about the 1538days that someone discovered, described in a quick blog or pastebin, and are now lying around for someone to find and exploit. //
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Fortunately I’m clever and I’ve checked my Dropbox into Github.
I keep every academic project since 2003 in a directory named src2/. Why src2? Because six years and three laptops ago I somehow corrupted src/ and was afraid to overwrite it. In 2025 I anticipate an upgrade to src3/.
Imagine creating a social media company and rigging the stock so nobody can ever depose you, and then *not* creating a giant candy factory staffed with weird and magical helpers.
Whenever I read about the exploits of Zuck I’m like SMH that’s what people who actually worry about their jobs do, you dumbass.
“Oh no, promoting voter info might make idiots think my company is politically biased, then we’d have a 4% drop in weekly engagement…”
Seriously, you could invent chewing gum that never loses its flavor and this is what you choose.
Yes, moderation is going to be harder in end-to-end encrypted spaces. You know what else is going to be harder? Algorithm-driven content amplification. And trust me, one of these things is doing way more damage.
The thing about end-to-end encryption (E2EE) is that it’s absolutely tractable to moderate conversations *if* participants report problems. This voluntary reporting capability is already baked into some systems through “message franking” 1/
So when we say “moderation of E2EE conversations is hard” we’re basically saying “moderation is hard if we’re talking about small(ish) closed groups where not one single participant hits the ‘report abuse’ button.” 2/
I don’t know what to make of the accusations re: Chrome logins in the revised antitrust complaint against Google, but I’m now really looking forward to learning more.
A few years back, Google activated a feature that would automatically log you into the Chrome browser anytime you logged into a Google site. This made it basically impossible to be logged out of Chrome if you used Google accounts.
The Chrome engineers said that they had to do this because users with multiple accounts were getting confused — apparently the idea that some people might not want Chrome to be logged in was not contemplated.