Conversation

Notices

1. Embed this notice
   Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 00:26:53 JST Soatok Dreamseeker

   harmless design decision + obvious thing to do by default + sensible trade-off that minimizes support burden for dev teams + obvious thing to do = CVSS 10

   • Rich Felker repeated this.
   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 00:26:52 JST Soatok Dreamseeker

     in reply to

     common programming habit + LGTM + unit tests pass + static analysis is good + (optional) the fucking thing compiles = oops I got your private key

     Rich Felker repeated this.
   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 00:32:46 JST Soatok Dreamseeker

     in reply to

     • SwiftOnSecurity

     A while ago, @SwiftOnSecurity started writing Decent Security, about personal computers and mobile device security.

     Appsec (writing secure software) is less friendly because everything you learned about programming becomes suspect.

     Why can't I just combine user data into this SQL query string if I'm careful enough? I know about Bobby Tables. I'll sanitize my inputs!!!

     Bam, SQL injection because integers can be used to reference column names in some injected queries.

     Doughnut Lollipop 【記録係】:blobfoxgooglymlem: repeated this.
   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 00:32:47 JST Soatok Dreamseeker

     in reply to

     The security nerds haven't commented yet because this pattern-matches to way too many vulns to know which one I'm talking about yet

   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 00:41:37 JST Soatok Dreamseeker

     in reply to

     There's been a lot of "excitement" from business types about using LLMs to find vulnerabilities in source code.

     Naturally, the goal is to cheapen labor and extract more value for themselves. But I do suspect they're going to fall on their own sword with this one.

     Not every vulnerability is obvious. Something can look fine and be the Achilles' heel that wrecks your shit. Something can look incredibly dangerous but end up being a NOP.

     If people think their stochastic parrot can do a better job than humans, point them at OpenSSL or libgcrypt, and then have someone with relevant experience interrogate the "findings" before you waste the developers' time. I can guarantee almost everything they complain about will be a false positive with even the shallowest scrutiny.

     Doughnut Lollipop 【記録係】:blobfoxgooglymlem: likes this.
   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 00:46:37 JST Soatok Dreamseeker

     in reply to

     There's another dimension to this.

     Attackers don't always choose the same targets that you think are highest value.

     Why attack your hardened authentication gateway when the marketing team has an unpatched WordPress 3.1 blog sitting right there talking to your production MySQL database?

   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 00:47:43 JST Soatok Dreamseeker

     in reply to

     Every time you talk seriously about security-in-practice you will find yourself circling around this point:

     https://infosec.exchange/@dymaxion/109344795644687902

   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 00:54:43 JST Soatok Dreamseeker

     in reply to

     • Matthew Green

     On the topic of "political problems", sometimes you have attack vectors that nobody in the C-Suite considers an attack vector, like the FBI demanding the BitLocker disk encryption keys for Windows users.

     https://www.forbes.com/sites/thomasbrewster/2026/01/22/microsoft-gave-fbi-keys-to-unlock-bitlocker-encrypted-data/

     Cryptographers have been complaining about this for decades. @matthew_d_green coined the term "Mud Puddle Test" to talk about it.

     https://blog.cryptographyengineering.com/2012/04/05/icloud-who-holds-key/

   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 00:55:25 JST Soatok Dreamseeker

     in reply to

     While working on https://publickey.directory, two really annoying problems cropped up.

     1. What if someone demands their data be stricken from the transparency log, as is their right under the EU's GDPR?
     2. What if someone legitimately loses access to all their secret keys (catastrophic hardware failure) and wants their instance admin to be able to restore their ability to use E2EE?

     When I say "annoying problems", I do NOT mean the people that would experience them are annoying.

     I mean they are annoying because they are fundamentally incompatible with the simplest possible solution.

   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 01:18:35 JST Soatok Dreamseeker

     in reply to

     Anyway, I'm going to log off fedi and get back to group therapy for abused programming languages work.

     If this pops off while I'm afk:

     Hi, I'm Soatok, a gay furry cryptography nerd. I blog at https://soatok.blog and once led a charge to fund a library because the local mayor is a bigot and wanted to illegally withhold their funding.

   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 01:18:37 JST Soatok Dreamseeker

     in reply to

     For the first issue, I wrote https://soatok.blog/2024/11/21/key-transparency-and-the-right-to-be-forgotten/ in 2024.

     It made the spec more complicated, but operators being able to run a command line script instead of dealing with lawyers is a win.

     For the second issue, which was documented in https://utcc.utoronto.ca/~cks/space/blog/tech/AccountRecoveryHardPKIProblem before I devised a solution, BurnDown + Fireproof were introduced to support a balanced approach.

     • Power users (esp. the kinds of people governments would target, such as journalists, activists, and whistleblowers) can become immune to BurnDown. But if they lose their keys, they're SOL.
     • Everyone else can recover access by having their instance admin issue a BurnDown and starting over with a fresh keypair.

     Passing the Mud Puddle Test was important to me, but being usable by real people who aren't 100% perfectly disciplined all the time is even more important.

   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 01:18:37 JST Soatok Dreamseeker

     in reply to

     • Eleanor Saitta

     With respect to the @dymaxion toot I quote frequently:

     There are myriad political problems surrounding the development and adoption of cryptography tooling.

     Is this the right balance for everyone?

     Probably not. I anticipate someone will write an E2EE client someday that forces users to be Fireproof with PKDs (and refuses to chat with anyone that isn't), even to their own detriment, and some folks on Hacker News will cargo-cult that as the only secure client to use for E2EE on Fedi. And then I will have a headache to deal with.

     I also anticipate some governments considering using GDPR-like takedown demands to cover up their own crimes against their citizens. (Mitigating that might require operators having the sensibility to back up the keys they're shredding in their online service and have their lawyers hold onto it.)

     But at the end of the day, what I'm building are merely tools, not panaceas.

   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 01:30:51 JST Soatok Dreamseeker

     in reply to

     • RootWyrm 🇺🇦:progress:

     @rootwyrm I'm happy to say I spend more time using WeAudit for VSCode than videoconferencing software, but my job is kind of cool

   • Embed this notice
     RootWyrm 🇺🇦:progress: (rootwyrm@weird.autos)'s status on Saturday, 24-Jan-2026 01:30:52 JST RootWyrm 🇺🇦:progress:

     in reply to

     @soatok I once did the actual math.

     Doing the security standards for a large company subject to thousands upon thousands of laws and regulations, quite literally 84% of my time was spent on writing justifications, explaining mitigations, and meetings with deeply non-technical people.

     5% was actually implementing technical measures.

     Less than 30 minutes of it was addressing actual technical security issues.

     This is in the context of a six week process.

   • Embed this notice
     RootWyrm 🇺🇦:progress: (rootwyrm@weird.autos)'s status on Saturday, 24-Jan-2026 01:30:53 JST RootWyrm 🇺🇦:progress:

     in reply to

     @soatok as arguably the most experienced among us:

     Oh, no, you sweet summer children.

     ALL security questions are political problems first and foremost. No, seriously, ALL of them. Don't believe me?

     Ask why Department X isn't allowed to access Resource Y.

     Ask why data-at-rest encryption is required but not data-in-flight encryption.

     Oh and then there's FedRAMP! Where only U. S. citizens can touch things, unless they're writing the application itself. For reasons.

     UhHUH.

   • Embed this notice
     Soatok Dreamseeker (soatok@furry.engineer)'s status on Saturday, 24-Jan-2026 01:52:35 JST Soatok Dreamseeker

     • Patch Arcana

     @patcharcana See my next post lol :D

   • Embed this notice
     nadja (dequbed@mastodon.chaosfield.at)'s status on Sunday, 25-Jan-2026 23:55:20 JST nadja

     in reply to

     @soatok > cheapen labor and extract more value for themselves

     Which is still why I argue we need liability for software bugs that is persecuted ex officio; it can't be that in 2026 companies are still hiding behind the “software just does that *shrug*” excuse for bugs and security issues.

   • Embed this notice
     Luna :neofox_snug: (lunareclipse@snug.moe)'s status on Sunday, 25-Jan-2026 23:55:35 JST Luna :neofox_snug:

     in reply to

     @soatok this is why I refuse to use the platform passkeys on Android.
     
     If you don't let me disable sync the security guarantees are gone. Encrypting the passkey with my screen lock pattern is laughable since the only reason that pattern is adequate for unlocking the phone itself is relying on the TPM to rate-limit unlock attempts.

     Soatok Dreamseeker repeated this.
   • Embed this notice
     Firstyear (firstyear@infosec.exchange)'s status on Monday, 26-Jan-2026 08:27:16 JST Firstyear

     in reply to

     • Luna :neofox_snug:

     @lunareclipse @soatok During the development of this, we lobbied google and apple to both allow the user to choose if keys should be synced or device only. Both flatout denied this and said "why would you want device only?!" Despite us listing a lot of possible cases eg dv. And so now here we are 🙃