A grab-bag that’s really about one theme: the shape of the work is changing. Session security is getting cryptographic with DBSC, CI is buckling under agents, and the tools we drive are learning to drive each other.
Device Bound Session Credentials: Making Stolen Cookies Useless
Scott Helme’s clear explainer of DBSC, and the point lands hard: after all our progress on passwords, 2FA, and passkeys, the thing an attacker actually steals is still just a cookie. DBSC binds the session to a device-held private key, so a short-lived cookie has to be cryptographically refreshed by proving possession of that key: a stolen cookie replayed from another machine simply can’t. He walks the registration and one-step vs. two-step refresh flows, plus the privacy design (fresh key pair per session, cleared with site data). Given the security angle in my own work, this is a keeper.
Open-Sourcing dbsc-php: a Server Library for Device Bound Session Credentials in PHP
The companion release: a ~700-line, zero-dependency, MIT-licensed PHP library (ES256 only) that encodes the hard-won corrections between “what the spec says” and “what Chrome actually does.” The wire-protocol notes in the README are the real gold: registration is single-phase, refresh is two-phase, both the cookie value and challenge must rotate every refresh, and (the one that bit them in production) DBSC state must live in its own key space (Redis/table) keyed by session id, never inside a read-modify-written session blob, or a race silently clobbers the binding. Framework-agnostic by design.
Replace Your CI With a Merge Queue
David Crawshaw’s argument is short and provocative: after-the-fact CI worked because humans break HEAD rarely and at human speed, but agents are always new to a codebase, regress things constantly, and by the time the “you broke CI” email lands, the agent’s context window is long gone. His fix is to run all tests in a merge queue (no slow daily-only suites), then hand agents a second command that runs the queue minus the merge, so they fix problems before inflicting them on anyone. Provocative, but it clarified something I’d felt and not named.
How do you do continuous profiling / execution tracing? (r/golang)
A Go community thread on continuous profiling and execution tracing in production: how people actually wire up low-overhead, always-on profiling and trace collection rather than one-off pprof runs. Useful as a survey of the current tooling and the trade-offs people are living with.
Claude up front, Codex in the back
A fun proof-of-concept: use Claude Code purely as the orchestrator (the pleasant UI you argue with) and have it invoke Codex non-interactively for the heavy lifting, so you get Claude’s UX with Codex’s depth at minimal Claude token spend. The honest part is the caveats: the orchestration overhead is roughly flat (~5-7K tokens per round trip), so on a one-line change the wrapper costs more than the work, and stacking two prompt layers plus three sets of agent rules (CLAUDE.md / CODEX.md / AGENTS.md) makes failures quietly hard to debug. Worth it only when the task is genuinely big.