Editorial note: Today’s signal is about identity data becoming a honeypot. The rest of the digest follows with practical takeaways for engineers and product leaders deciding whether to centralize identity, trust automation, or rely on evolving language/compiler behavior.

Top Signal

Hackers Had a Live Feed of Every ID Verification Company Scanned for over a Year

Why this matters now: The reported IDScan.net leak of millions of driver’s-license scans — allegedly streamed continuously for over a year — directly threatens any product or policy that relies on centralized raw ID scans for age or identity checks.

According to reporting traced by KrebsOnSecurity and summarized by TechDirt, criminals on the dark web service Nexus claim to have been "continuously exfiltrating new data for over a year into our private database." The exposed trove reportedly includes scans of more than 153 million driver’s licenses plus millions of other ID and medical cards. The FBI has opened an inquiry and many downstream customers (from rental companies to dispensaries) face fallout even if they weren’t directly breached.

The practical harm is concrete: high‑resolution ID scans are reusable for identity theft, fraud, doxxing, and dangerous in cases of domestic abuse or witness protection. As one community thread put it, mandating “age verification” often builds “massive, irresistible databases of identity,” and this incident shows that tradeoff is brittle. A quote echoed in reporting: the vendor’s trust page still promises how they “protect data, maintain system reliability, and earn the confidence of our customers,” which, if accurate statements were being made, now sits in painful tension with the alleged breach.

Technically and policy‑wise, this reignites alternatives discussion. Proposals span from PKI‑backed single‑service credentials to government‑mediated digital wallets and tokenized attestations (Denmark’s AltID is often cited as a privacy‑oriented model). Those alternatives trade one central risk for others — e.g., supply‑chain compromise or large‑scale credential abuse — so the decision isn’t purely technical: it’s an operational and regulatory one. For product teams: prioritize threat models that assume stolen authoritative scans are likely, and design for minimal retention, cryptographic attestations, and reversible/de‑identifiable proofs where possible.

"We have been continuously exfiltrating new data for over a year into our private database," — Nexus (claimed, as reported).

AI & Agents

Solving the Jane Street Reverse Engineering Challenge

Why this matters now: Jane Street’s ASIC puzzle shows how commodity EDA tools plus SMT solving can turn raw layout into functional understanding — useful for hardware security researchers and teams auditing silicon.

A detailed write‑up of the solve is available at Jestoph’s blog. The author reconstructed a netlist from a GDS layout, mapped geometries to sky130 standard cells, wrote ad‑hoc parsing and simulation tooling, and — crucially — switched from forward simulation to constraint solving with Z3 to force the required signals. The satisfying final output (spoiler: "( TWO STARS )") came after translating time‑step behavior into solver constraints.

Lessons for teams: hand‑built tooling can teach you the failure modes and edge cases that black‑box tools miss, but mature open‑source EDA stacks (KLayout, yosys, Degate, etc.) can shortcut many steps. Also, the jump from simulation to SMT solving is important — once you express temporal constraints, deterministic recovery becomes tractable. If you do hardware reverse engineering or supply‑chain auditing, add a small SMT workflow to your toolbox.

"I solved it with a combination of hard‑headedness and sleep deprivation." — solver postmortem

Markets

Carbon‑aware electricity pricing, measured daily on 38 grids

Why this matters now: The small experiment at carbonawarepricing.com quantifies the real-world limits of using hourly price signals to nudge demand toward cleaner hours.

The project modeled three tariff variants across 38 grids and found modest gains: for Switzerland, a Carbon‑Aware Hourly tariff would have cut emissions about 2.4% versus an existing time‑of‑use plan; a critical‑peak carbon price managed ~3.0% improvement. Over a 32‑day window that amounted to a few thousand tonnes of CO₂ avoided. The core mechanism is simple: raise retail price when the grid is carbon‑heavy, lower it when the grid is clean, and let flexible loads move.

Two practical takeaways: (1) gains come from variability, not absolute grid dirtiness — grids with large renewables swings offer more opportunity; (2) carbon‑aware retail prices are a nudge, not a replacement for decarbonization policy. The project also flags real deployment issues: marginal vs average emissions signals, fairness impacts of price volatility, and the need for automation (smart EV charging, behind‑the‑meter controllers) if behavioral change is expected at scale.

World

1960s theory that Stonehenge was a prehistoric computer

Why this matters now: Revisiting Gerald Hawkins’s 1960s claim that Stonehenge functioned as an "eclipse computer" is a useful reminder: elegant computational narratives can outpace archaeological evidence.

The BBC retrospection (BBC Culture) documents how Hawkins used early IBM time‑sharing to argue the 56 Aubrey holes tracked lunar cycles and eclipses. Modern archaeology, however, shows the monument evolved across 1,500 years and alignments are generally too imprecise to support a single‑purpose eclipse device. The episode matters for technologists because it illustrates how computational models, when divorced from messy historical context, can produce compelling but over‑simplified narratives.

"Stonehenge was locked to the Sun and Moon as tightly as the tides," — Gerald Hawkins (1960s claim, now questioned)

Dev & Open Source

Authorization terminology is a mess: Let's fix it

Why this matters now: Andrea Chiarelli’s taxonomy reframes access control debates, turning marketing buzzwords into a practical multi‑axis design checklist teams can use to choose tradeoffs explicitly.

The IDPro post argues we’re muddling different questions under single labels. Chiarelli proposes six axes — who administers rules, data the rules use, policy artifact format, data sources for decisions, where decisions are computed, and where enforcement happens — and recommends describing systems as a tuple across those axes (for example: centralized admin, role‑based model, JSON policies, token source, centralized engine, gateway enforcement). That framing pushes teams to be explicit about latency, auditability, policy ownership, and operational boundaries instead of arguing abstractly over RBAC vs ABAC.

Practical action: when designing or procuring authorization, document your system along these axes and validate assumptions — especially "where" a decision is evaluated, since that impacts trust boundaries and observability.

Move in C++ without a std::move

Why this matters now: Modern C++ (C++23+) aggressively applies implicit moves and RVO, so developers can safely reduce explicit uses of std::move and avoid move‑related mistakes in many common return patterns.

Andreas Fertig’s post at andreasfertig.com walks through NRVO/RVO and how newer language rules let compilers elide copies or insert implicit moves where older standards required manual std::move. The upshot: prefer clear ownership semantics and rely on the compiler for common return optimizations; reserve std::move for cases where you explicitly want to transfer an already‑named object’s resources.

Caveat: NRVO and implicit moves still have corner cases across compilers and build modes; profiling and understanding value categories remain valuable.

The Bottom Line

Centralizing raw identity scans is an operational Achilles’ heel — assume compromise and redesign verification flows for minimal retention and cryptographic attestations. Elsewhere, formal tools (SMT, EDA stacks) and thoughtful taxonomy (authorization axes) are winning ways to reduce surprise, while modest policy experiments (carbon‑aware pricing) and language evolution (C++ moves) show incremental, practical gains. For engineering teams, the recurring lesson is: build with the assumption that data and components will be attacked or fail, and prefer designs that limit blast radius and preserve auditability.

Sources