Sunday, 24 May 2026
ICE deploys 1,570 iris-scanners without FedRAMP review; Oura stonewalls government data requests; 80386 microcode fully reverse-engineered from die photos
Today's Lead
Project Saltbox
ICE Awards $25M Iris-Scanning Contract Without Standard Security Reviews
ICE awarded a $25.1 million no-bid contract to Bi2 Technologies for 1,570 iris-scanning devices — a five-fold expansion from a previous $4.6 million agreement — without FedRAMP clearance, independent audits, or congressional notification. The devices must be delivered by late June 2026 and provide field agents real-time access to a database of over 5 million booking records for identity verification. FedRAMP is the mandatory federal security review process for cloud systems handling sensitive government data; bypassing it raises significant questions about data integrity and accountability for a system that will touch millions of biometric records. The no-bid structure also forecloses competitive scrutiny of both cost and security posture.
Also today
This Week in Security
Oura Refuses to Disclose How Many Government Data Requests It Receives
Oura, maker of the popular smart ring worn by approximately 5.5 million users, acknowledged receiving government data requests and claiming to evaluate each for legality — but refuses to publish how many requests it receives, how often it complies, or what categories of data are targeted. This is particularly notable because Oura's biometric health data (sleep, heart rate, temperature, activity) is not end-to-end encrypted, meaning it is accessible to prosecutors armed with a warrant. Eight months after saying it was 'actively evaluating' publishing aggregate transparency data, the company has gone silent. By contrast, Apple, Google, and most major tech platforms publish regular transparency reports; Oura's silence is conspicuous given how sensitive continuous biometric data is compared to standard app usage metrics.
Read →reenigne.org
80386 Microcode Fully Disassembled from Die Photographs
Researchers successfully reverse-engineered and disassembled the complete Intel 80386 microcode by extracting nearly 95,000 bits of ROM data from high-resolution die photographs — revealing that the 386's microcode is almost nine times larger than the 8086's. Unlike its predecessor, the 80386 executes microcode for every instruction with 215 entry points rather than selectively; hardware accelerators (multiplier, barrel shifter, protection and paging units) are orchestrated by microcode rather than implemented in it. The analysis also uncovered a potential bug in I/O permission bitmap checking that could theoretically allow unauthorized hardware register access at specific memory boundaries. This work directly enables the z386 FPGA implementation (see below), provides more accurate CPU emulators, and documents decades-old processor internals that had never been fully visible before.
Read →nand2mario
z386: An Open-Source 80386 Rebuilt Around Original Microcode
Building on the newly recovered 80386 microcode, nand2mario implemented z386 — a fully functional open-source Intel 80386 on FPGA that drives the original 37-bit microcode ROM through a reconstructed hardware datapath. All eight major functional units are implemented: prefetch, decode, ALU/shifter, segmentation, protection, paging, and memory. The result runs at 85MHz with a 16KB L1 cache, achieves performance comparable to a fast cached 386 or entry-level 486, and successfully runs real DOS applications, protected-mode software, and games like Doom. This approach differs fundamentally from software emulators: rather than interpreting instruction semantics, z386 replicates the actual hardware architecture microcode was designed to run on, producing authentic cycle-accurate behavior.
Read →TechCrunch
Scammers Abused a Microsoft Internal Account to Send Phishing Spam
Attackers exploited Microsoft's official `[email protected]` address — the same account Microsoft uses for legitimate account notifications — to send phishing emails containing spam links and fake account alerts, persisting for months before detection. The root cause was excessive customization allowed in Microsoft's automated notification pipeline, which permitted crafting messages indistinguishable from real system emails. The abuse is especially damaging because recipients have been trained to trust this address, and email security tools whitelisting Microsoft's own infrastructure would pass these messages without flagging them. Microsoft is 'actively investigating' and strengthening detection, though the timeline to a fix has not been disclosed.
Read →Andrew Lock
.NET 11 Preview 2: C# Finally Gets Native Union Types
C# 15, shipping in .NET 11 Preview 2, adds native union types — one of the most-requested language features in the ecosystem's history. Union types allow a variable to hold one of several distinct types with exhaustive, compiler-enforced pattern matching via switch expressions that require no catch-all case. The implementation uses struct-based boxing-free unions for performance, and future additions include union member providers and closed hierarchies. Developers targeting earlier .NET runtimes can access the feature via helper types. This closes a major expressiveness gap between C# and functional-leaning languages, and brings safer, more concise domain modeling to the mainstream .NET audience.
Read →seriot.ch
A researcher rigorously proved that Atlassian Jira's automation system is Turing-complete by implementing Minsky register machines entirely within Jira rules and issue relationships. The mapping is direct: issue counts represent registers, Epic status values serve as program counters, and automation rules execute instructions. The piece includes working implementations of an addition program and a Fibonacci generator built purely in Jira. While Jira Cloud imposes practical recursion depth limits, these don't undermine the theoretical result. The finding is both a humorous indictment of enterprise automation feature creep and a serious flag: if your workflow tool is Turing-complete, your workflow definitions are effectively programs, with all the debugging and correctness implications that implies.
Read →veronicaexplains.net
Building a Writerdeck: Console-Only Debian as a Distraction-Free Writing Machine
Veronica turned an old System76 laptop into a dedicated writing device by stripping it down to console-only Debian — no desktop environment, no GUI, deliberately no internet connectivity during writing sessions. The setup boots directly into Neovim via automatic login, with tmux providing session management and Syncthing syncing files to a home server for backup. The key constraint is intentional: removing the possibility of context-switching to a browser or notification surface forces sustained attention in a way that software-level blockers and habit trackers never quite achieve. The piece resonates at over 350 upvotes on Hacker News because it articulates a growing frustration with modern computing environments optimized for engagement rather than output.
Read →righto.com
Reverse Engineering the Circuitry of a 1980 Spacelab Computer
Ken Shirriff reverse-engineered the ALU board of the Mitra 125 MS, a French 16-bit minicomputer built from discrete TTL chips that controlled experiments aboard NASA's Spacelab missions in the Space Shuttle. Rather than using a microprocessor, the Mitra's CPU was constructed from multiple boards of 54S181 ALU chips, multiplexers, and registers — notably implementing a 32-bit ALU despite the computer's 16-bit native architecture, likely to accelerate the multiply and divide operations required for scientific payloads. The Mitra 125 MS was produced under France's Plan Calcul computing sovereignty initiative, and these systems were eventually replaced by IBM processors in the early 1990s. Shirriff's detailed schematic reconstruction documents a category of mission-critical computing that left almost no digital records.
Read →Pointiest Stick
'Long-Term Support' Doesn't Mean What You Think
A widely-shared post clarifies that LTS Linux releases commit only to backporting security patches for a fixed period — not to fixing non-security bugs, improving hardware compatibility, or providing any form of personal support. Every non-security bug present on release day remains frozen in the LTS branch unless a distribution maintainer explicitly chooses to backport a fix, which rarely happens outside of high-profile regressions. The practical implication: organizations choosing LTS for 'stability' are often choosing stable bugs over regularly-fixed ones. The post summarizes the tradeoff as choosing between 'stale bugs' (LTS) and 'new bugs' (rolling release), and argues the right answer depends on what failure mode is more dangerous for a given workload — a reminder worth circulating before the next infrastructure decision meeting.
Read →