Build or Replaced
Today: Virginia bans sale of geolocation data | Right to Local Intelligence | CarPlay Is Additive Episode date: 2026-07-03.
Download MP3 →JOSH: It's Friday, July 3. This is Build or Be Replaced, powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Privacy laws, local AI, and encryption keys sitting in memory. That's a pretty good Friday if you like systems that can hurt you. JOSH: Stick around. Erik's got an AI pro tip at the end about the short leash method for coding agents. [pause] JOSH: First headline. Virginia just banned the sale of geolocation data. Big privacy move? ERIK: Yep. The key word is sale. They defined it as money changing hands between controllers and third parties. Narrow definition, but it's still another state saying location data is not just harmless exhaust from an app. JOSH: Next one. Right to Local Intelligence. Sounds like AI policy language. ERIK: It is, but the idea is solid. Run the model near the user, on the device when you can, and stop shipping every private thought to somebody else's cloud. Local inference is going to matter more than people think. JOSH: Third headline. Since Linux 6.9, LUKS suspend stopped wiping disk encryption keys from memory. That sounds bad. ERIK: That is the kind of boring kernel detail that becomes a real incident later. Disk encryption only helps if the key handling is tight. If suspend leaves keys around, your laptop threat model just changed. [pause] JOSH: Let's start with Virginia. Why does a state geolocation law matter to builders? ERIK: Because location data is one of those things teams collect casually and then forget they're holding a loaded weapon. [beat] ERIK: A phone ping is not just a dot on a map. It's where you sleep, where you work, what doctor you visited, what church you attend, which protest you walked past, and where your kids go after school. JOSH: Wait, really? From just location? ERIK: Absolutely. You don't need a spy movie. Give me enough points over time and I can infer a life. That's why selling it is nasty. The customer didn't really consent to that. They clicked through a screen so a flashlight app could work. JOSH: But Virginia's law defines sale pretty narrowly. Does that weaken it? ERIK: It does. If money has to change hands, a lot of data sharing gets dressed up as partnership, analytics, fraud prevention, ad measurement, whatever. Same data movement, different label. Lawyers are good at that. Shocking development. [beat] ERIK: But it's still a signal. States are tired of waiting for federal privacy law. Builders need to assume location data is regulated, sensitive, and radioactive if mishandled. JOSH: What would you do differently if you're building an app today? ERIK: First, don't collect precise location unless the feature dies without it. Second, separate location from identity as early as possible. Third, set a retention clock. If the data isn't needed tomorrow, delete it today. JOSH: That's the opposite of the usual product instinct. ERIK: The usual product instinct is hoard everything and call it future insight. That's how you end up explaining a CSV export to regulators. [beat] ERIK: In ScanBrief today, it scored 88 items across 54 sources. I don't need to store every raw artifact forever to make the product useful. Score it, summarize it, keep what matters, drop what doesn't. Same mindset applies to location. JOSH: So privacy by deletion. ERIK: Exactly. Deletion is architecture. It's not a cleanup task. Build the pipeline so data ages out by design. JOSH: How does this connect to automation teams? ERIK: Automation teams love telemetry. I love telemetry. PrimeBus processed 993 automation events across 15 projects today. That data is gold for debugging. But I don't treat every event the same. Some events can live forever as counters. Some should expire. Some should never contain secrets in the first place. JOSH: That's the part people skip. ERIK: Yep. They log the whole payload because it's convenient. Then the logs become the breach. [pause] JOSH: The second story pairs with that. Right to Local Intelligence. What is local AI actually solving? ERIK: It solves three problems. Privacy, latency, and control. [beat] ERIK: Privacy because the data stays on the device. Latency because you're not waiting on a cloud round trip. Control because the user can run the tool even if a provider changes terms, rate limits, or has an outage. JOSH: But aren't the best models still in the cloud? ERIK: For heavy reasoning, yes. Claude, GPT, Gemini, the big models still win on hard tasks. But not every task needs a giant brain in a data center. JOSH: Give me an example. ERIK: Email triage. Meeting notes cleanup. Local search over personal files. Small code edits. Screenshot classification. Command suggestions. A local model can handle a lot of that without shipping private data off the box. JOSH: Where do you draw the line? ERIK: Route by risk and complexity. That's the whole trick. [beat] ERIK: Low-risk, low-complexity tasks go local. High-complexity tasks go to a frontier model. Sensitive tasks get redacted first or stay local. If confidence drops, send it to a human or a stronger model with a smaller context window. JOSH: That sounds like HumanRail. ERIK: Yeah. HumanRail exists because agents should not pretend they're sure when they're not. Route the work. Put confidence thresholds on it. If the model is guessing, stop and ask. JOSH: People hear local AI and think, fine, but it won't be as smart. ERIK: That's the wrong test. The test is whether it's smart enough for the job. A hammer doesn't need Kubernetes. [beat] ERIK: If I need Claude to reason through a broken Terraform module, I'll use Claude. If I need a local agent to classify a log line and decide whether PrimeSentinel should wake up a workflow, that's a smaller problem. JOSH: So the future isn't local versus cloud. ERIK: Correct. It's routing. Local first when it makes sense. Cloud when it earns the trip. Human when the cost of being wrong is high. JOSH: What's the builder mistake here? ERIK: Treating every AI call like a chat app. Prompt in, answer out. That's not a system. A system has policies. What data can leave? What model gets used? What gets logged? What gets retried? What gets blocked? JOSH: And what gets deleted. ERIK: Exactly. Privacy and automation are tied together. The more agents you run, the more important your data boundaries get. [pause] JOSH: Let's hit the Linux LUKS story. Disk encryption keys not being wiped from memory after suspend since Linux 6.9. How serious is that? ERIK: Depends on your threat model, but it's not nothing. [beat] ERIK: LUKS protects the disk at rest. If the machine is powered off and someone steals it, they need the passphrase or key material. But suspend is different. The machine is sleeping. RAM may still hold secrets. JOSH: So encryption is only as strong as the state the machine is in? ERIK: Yep. Security is always stateful. Powered off, locked, suspended, hibernated, logged in over SSH, screen locked with agents running. Those are not the same condition. JOSH: Who should care about this? ERIK: Anyone carrying a Linux laptop with sensitive data. Engineers, journalists, lawyers, finance people, security teams. Also anyone who says, "It's fine, my disk is encrypted," and then suspends the laptop in an airport. JOSH: That's a lot of people. ERIK: It is. Suspend is convenient. Convenience is usually where security goes to get mugged. [beat] JOSH: What would you change? ERIK: If the data matters, prefer full shutdown or hibernate with proper swap encryption over suspend. Keep firmware updated. Watch distro advisories. And test your own fleet behavior instead of assuming the blog post matches your setup. JOSH: How do you test something like that in a real environment? ERIK: Make it boring. Inventory kernel versions. Track suspend settings. Flag machines on risky combinations. Put it in your dashboard. PrimeDash exists because I don't want to guess what the lab is running. JOSH: That's the difference between reading about risk and managing risk. ERIK: Exactly. Reading the headline is step one. Turning it into a check is the builder move. [pause] JOSH: Another headline today was Podman v6.0.0. You use containers all over the place. What do you look for in a release like that? ERIK: I look for boring improvements. Better networking, better systemd behavior, fewer weird edge cases around rootless containers, cleaner compatibility with Docker workflows. Containers are plumbing. Plumbing should not be exciting at 2 AM. JOSH: Podman versus Docker. Do you have a side? ERIK: Use what fits the operating model. Docker is still familiar and easy. Podman is strong when you care about rootless operation, systemd integration, and not running a big daemon for everything. JOSH: Would you switch a production fleet just because v6 dropped? ERIK: No. Version number is not a migration plan. I'd test it against actual services, especially anything using volumes, networking, and restart behavior. Then move one boring service first. [beat] ERIK: That's how I handle almost everything. Start small in the lab. Prove the win. Add guardrails. Then prod. JOSH: That sounds very not glamorous. ERIK: Good. Glamorous infrastructure is usually on fire. [pause] JOSH: The Postgres story also stood out. "Postgres transactions are a distributed systems superpower." Is that overselling it? ERIK: Not really. Transactions are one of the reasons Postgres keeps surviving every trend cycle. JOSH: Why do transactions matter so much? ERIK: Because state is where systems lie to you. You think a thing happened, then half of it failed. Now the UI says paid, the ledger says unpaid, and the job queue is holding a message from the past like it's evidence. JOSH: That's specific. ERIK: Because it happens. Transactions let you make a group of changes atomic. All of it commits, or none of it commits. That's not fancy. That's civilization. [beat] JOSH: How does that become distributed systems power? ERIK: Pair transactions with durable queues, outbox tables, idempotency keys, and careful retries. Now Postgres isn't just a database. It's the control point for reliable work. JOSH: Is that better than adding a message broker? ERIK: Sometimes. NATS is great. I use NATS in PrimeBus because event flow matters there. But not every app needs a separate broker on day one. A Postgres outbox can carry a shocking amount of real workload if you design it well. JOSH: So don't add moving parts for sport. ERIK: Exactly. Every new component is another thing with logs, upgrades, backups, metrics, and failure modes. If Postgres can solve the coordination problem cleanly, let it. JOSH: Where would you still use NATS? ERIK: Fanout, telemetry, agent coordination, event-driven automation. PrimeBus is built around that because agents need to react to messages across projects. Different shape of problem. [beat] ERIK: But for a SaaS app doing billing events, emails, user actions, background jobs, Postgres plus an outbox is often plenty. Ship the product. Don't cosplay as a hyperscaler. [pause] JOSH: We also had a headline about the short leash AI coding method. Since that's the pro tip later, give me the quick version now. ERIK: Don't hand an agent the whole repo and ask it to make magic. Give it a small task, force it to inspect first, make it explain the edit, run tests, then repeat. Short leash. More control. Less cleanup. JOSH: Sounds slower. ERIK: It feels slower for about ten minutes. Then you stop spending two hours undoing confident nonsense. [pause] ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Use the short leash method with your coding agent today. [beat] ERIK: Give it one file or one behavior. Ask it to read before editing. Then make it state the plan in plain English. After the edit, require a test command or a reason why no test exists. JOSH: What's the actual prompt? ERIK: Say this: "Inspect the relevant files first. Do not edit yet. Tell me the smallest safe change and the test you'll run." Then after it answers, say: "Make only that change." [beat] ERIK: That's it. You're turning the model from a wandering intern into a tool with rails. Claude is very good when the task is bounded. It gets weird when you give it a fog machine and a dream. JOSH: And if it finds more problems? ERIK: New task. New leash. Don't let one fix become a renovation. That's your tip. Use it. [pause] JOSH: Binge all five episodes this weekend plus our YouTube shorts — links at buildorbereplaced.dev. [pause] JOSH: One more thing — we started a Discord for builders. If you're shipping AI, automation, or anything that makes a human obsolete — come hang out. Link at buildorbereplaced.dev. ERIK: Post what you built. We'll post what we're building. Real wins, real builds, no fluff. [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.