Sam: Get this: the private keys for signing every driver's license in multiple US states were just… compiled into a public Android app.
Kai: I'm Kai.
Sam: And I'm Sam. It's Thursday, September 17th, 2026, and this is Trending Repos.
Kai: We've got a packed show today, from jaw-dropping security fails to AI that's running circles around old-school tech.
Kai: First, we'll talk about how the master keys for US driver's licenses were just... left out in the open.
Sam: Then, there's a new AI model that claims it can write database queries eighty-one percent faster than Postgres itself.
Kai: And we'll wrap with a wild paper on making LLMs hyper-efficient by smashing through a long-standing theoretical wall.
Kai: Alright, let's get back to that bombshell you dropped at the top, Sam. A blog post on ryan.science called 'Keys Not Included' is blowing up right now.
Sam: It's an incredible bit of digital sleuthing. The author dug into the PDF417 barcodes on the back of US driver's licenses—the ones that are supposed to be tamper-proof because they're digitally signed.
Kai: Right, public key infrastructure. The DMV has the private key, scanners get the public key to verify it. Pretty standard.
Sam: Except the 'private' key wasn't so private. The researcher found an official Android app, a digital ID wallet, and just... decompiled it.
Kai: Wait, no—
Sam: Yes. Inside the app's code were the private keys for multiple states. Not just test keys. The real deal. Hardcoded.
Kai: That's a catastrophic failure. So anyone could just grab these keys, generate a fake ID barcode, sign it, and any scanner would think it's real?
Sam: Any scanner that trusts those public keys—which is the whole point—would say 'yep, looks good.' It completely shatters the trust in the AAMVA standard used across North America.
Kai: The repo he published even includes a proof-of-concept tool, `bardecode`, to read and validate these licenses. It’s a perfect example of why this kind of public scrutiny is so important.
Sam: It’s great that he disclosed it responsibly, but let's be clear: this is not a 'fun hack.' This has serious implications for ID checks everywhere, from bars to airports. It's a five-alarm fire for digital identity.
Kai: The lesson for developers here is simple: never embed private keys in a client-side app. Ever. It's rule number one.
Sam: And for the rest of us? It means our digital ID systems are only as secure as the weakest link in the chain. I wouldn't trust a barcode scan for anything important anytime soon.
Sam: Alright, let's move on to making databases faster. A lot faster. A project called 'qorl' from Rohan Bansal is shooting up the charts.
Kai: Oh, I starred this one the second I saw it. It's a four-billion-parameter model trained with reinforcement learning to do one thing: optimize Postgres query plans.
Sam: So instead of using Postgres's own query planner, you feed the query to this AI, and it tries to find a faster way to run it?
Kai: Exactly. And the benchmarks are wild. The blog post claims it generates query plans that execute up to eighty-one percent faster than Postgres's own planner on complex joins.
Sam: Eighty-one percent. That's a very specific, very high number. Is that on a real-world workload or a synthetic benchmark designed to make the model look good?
Kai: It's based on the JOIN Order Benchmark, which is a standard test. The point is, for queries with tons of joins, the number of possible execution plans is huge. Postgres takes shortcuts, but this model can explore that search space more intelligently.
Sam: And what's the catch? You're running a 4 billion-parameter model next to your database. What's the latency on the planning itself? If it takes ten seconds to plan a query that runs one second faster, you've lost.
Kai: That's the trade-off. This is for complex, long-running analytical queries, where a few extra seconds of planning is nothing compared to the execution time. We're talking data warehousing, not quick web requests.
Sam: So for devs, this is a cool experiment, but don't try bolting a four-billion-parameter model onto your production web app's database. The overhead will kill you.
Kai: But it's a peek at the future! Imagine your database just... learning how to get faster on its own. That's the dream.
Kai: Alright, for our last story, we're going from huge models to tiny ones. A new paper on arXiv is getting a ton of buzz. It’s called 'Breaking the 1.58-bit Barrier for Ternary LLMs'.
Sam: Okay, my academic-buzzword-translator is firing up. 'Ternary' means the model's weights can only be one of three values, right? Like -1, 0, or 1.
Kai: You got it. It's an extreme form of model compression. Instead of using 16-bit or 8-bit numbers for each weight, you're only using three possible values. It makes the models tiny and incredibly fast.
Sam: And this '1.58-bit barrier'? What's that?
Kai: That's the theoretical minimum number of bits you need to represent one of three states—it comes from Shannon's information theory. Think log base 2 of 3. For years, nobody could get a ternary model smaller than that without losing information.
Sam: And these researchers did?
Kai: They broke it. Using some clever arithmetic coding and context modeling, they got it down to about 1.57 bits per weight, with almost no loss in accuracy.
Sam: Hold on. They're claiming to have broken a fundamental limit of information theory?
Kai: Not exactly. They're just being clever about exploiting patterns in the model's weights, so the average bits per weight is lower. It's like how a zip file works. This is a huge deal for running powerful AI on small devices.
Sam: Okay, that's more plausible. So the takeaway for developers is... nothing, for now. This is a research paper. You can't just `pip install` this yet.
Kai: But it shows where the puck is going! In a year or two, we could be running models that used to need a whole datacenter, right on our phones. This is the path to real on-device AI.
Sam: Alright, let's do a quick recap. A massive security failure exposed the private signing keys for US driver's licenses inside a public app.
Kai: Then we saw `qorl`, a new AI model that promises to massively speed up complex Postgres queries, even if the overhead is a big question mark.
Sam: And we wrapped with a research paper that's pushing the limits of AI model compression, hinting at a future of powerful but tiny LLMs.
Kai: Before we go, here's a fun fact, Sam. Since we were talking about secure foundational documents... today, September 17th, happens to be Constitution Day in the US.
Sam: How fitting. A day to celebrate a secure foundational document, right as we learn the document for our physical identity... can be signed with a key from a public repo.
Kai: You just couldn't resist. Alright, that’s our show for today!
Sam: Thanks for listening to Trending Repos. We'll be back tomorrow. Until then… maybe bring a second form of ID.
This show is made with AI: the hosts’ voices are synthetic and the scripts are AI-assisted. Every story links to its original source.