The Case for Privacy

--- introduction in 1994, congress passed a law most americans have never heard of. the communications assistance for law enforcement act — calea — requires every telecommunications carrier in the united states to build surveillance capabilities directly into its network infrastructure. the idea was straightforward: as phone networks transitioned from analog copper to digital switching, law enforcement was losing the ability to execute court-ordered wiretaps. calea was meant to preserve that ability. three decades later, the scope of calea has expanded well beyond telephone switches. the infrastructure it mandates has been exploited by foreign adversaries. and the fundamental tension it embodies — between enabling lawful surveillance and creating systemic vulnerability — has never been more relevant. this isn't a conspiracy theory. it's federal law, codified at 47 u.s.c. §§ 1001–1010, overseen by the fcc, and its consequences are documented in public court records, government reports, and cybersecurity incident disclosures. understanding calea matters because the tradeoffs it represents affect everyone who uses a phone or connects to the internet in the united states. what calea requires at its core, calea mandates that telecommunications carriers design their equipment so that when law enforcement presents a valid court order targeting a specific subscriber, the carrier can isolate that person's communications and deliver them to the requesting agency. the carrier must also be able to provide call-identifying information — metadata showing who called whom, when, and for how long. the law includes safeguards. interceptions can only be activated pursuant to a court order, and a designated carrier employee must affirmatively enable each tap after reviewing the order for validity. carriers are required to file system security and integrity plans with the fcc, documenting how they protect their intercept systems from unauthorized access. originally, calea applied only to traditional telephone carriers. but in 2004, the department of justice, fbi, and dea petitioned the fcc to extend its scope. by 2005, the fcc ruled that calea also applies to facilities-based broadband internet access providers and interconnected voice-over-ip services. what began as a law about phone switches now covered internet infrastructure. the scale of surveillance the administrative office of the u.s. courts publishes an annual wiretap report to congress documenting every authorized interception. these reports, available at uscourts.gov, provide the most authoritative public data on how often these capabilities are used. the numbers tell a story of steady growth. authorized wiretaps peaked at nearly 5,000 per year around 2012 before declining somewhat, though 2024 saw 2,297 authorized wiretaps — a 9% increase over the previous year. federal wiretaps alone rose 14% year-over-year. drug offenses remain the primary justification, cited in 49% of all applications. in 2024, 1,600 extensions were authorized, a 15% increase from the prior year. these figures capture only title iii intercepts — traditional wiretaps requiring individual court orders. they explicitly exclude surveillance conducted under the foreign intelligence surveillance act (fisa), which operates under a separate, classified reporting structure. the actual volume of communications interception enabled by calea infrastructure is certainly higher than what the wiretap report reflects. encryption is an increasingly common obstacle. in 2024, 350 federal wiretaps encountered encryption, and officials were unable to decrypt the communications in 313 of those cases. on the state side, 258 wiretaps encountered encryption, with 220 proving undecryptable. this growing gap between interception capability and decryption capability is at the heart of the ongoing "going dark" debate in law enforcement and policy circles. it is also worth noting the irony: the "going dark" framing is frequently used to argue for expanded mandated access — the very approach that, as the rest of this post documents, creates systemic vulnerabilities exploitable by adversaries. end-to-end encryption represents the architectural alternative: rather than building intercept points into infrastructure and trying to secure them, it removes the centralized access point entirely. that design choice has its own tradeoffs for law enforcement, but it eliminates the class of risk that calea creates. the risk that was always there every security professional understands a basic principle: you cannot build an access mechanism that is available only to authorized parties. any system designed to allow interception is, by definition, a system that can be exploited by unauthorized actors. this is not a hypothetical concern. it has happened repeatedly. the most dramatic example predates salt typhoon by nearly two decades. in 2004–2005, unknown parties — later linked by greek investigators to the u.s. embassy in athens — compromised vodafone greece's ericsson axe telephone switches. the attackers installed rogue software that exploited the switches' built-in lawful interception modules to tap more than 100 mobile phones belonging to the greek prime minister, cabinet ministers, military officers, journalists, and others. the surveillance ran for roughly ten months before being detected. a vodafone network engineer, kostas tsalikidis, was found dead in his apartment the day after the company ordered the rogue software removed. the detailed technical analysis of the attack was published by ieee spectrum in their article "the athens affair," and the case remains a landmark example of lawful intercept infrastructure being turned against the very government officials it was ostensibly designed to protect. salt typhoon in september 2024, it became public that a chinese state-sponsored hacking group known as salt typhoon had infiltrated at least eight major u.s. telecommunications companies — including at&t, verizon, and lumen technologies — in what u.s. officials described as one of the most significant cyber-espionage campaigns ever to target american communications infrastructure. among the systems compromised were the calea-mandated lawful intercept portals themselves. salt typhoon gained access to the very systems that carriers had built to comply with court-ordered surveillance, giving the attackers visibility into who was being surveilled, what communications were being intercepted, and the associated metadata. the fbi estimated that fewer than 100 individuals had their actual call content directly intercepted, but the number affected by metadata collection was far larger. targets included individuals associated with both major presidential campaigns during the 2024 election cycle and numerous government officials identified as "targets of interest." the breach was not the result of exotic zero-day exploits. according to cisa and a joint cybersecurity advisory published by the u.s. and more than 30 allied nations, the attackers exploited publicly known vulnerabilities — some with patches available for years — and basic security failures. one provider's management system was reportedly protected with the password "1111" [[10]](#references). the attackers used standard "living off the land" techniques, leveraging legitimate administrative tools to blend in with normal network traffic, and maintained access for an estimated one to two years before discovery. the fcc responded by proposing a declaratory ruling clarifying that calea's section 105 creates a legal obligation for carriers to secure their intercept systems from unauthorized access. this may seem obvious, but the ruling was necessary precisely because the existing regulatory framework focused on building intercept capability without equivalently rigorous requirements for securing it. the irony was noted widely. the electronic frontier foundation observed that the salt typhoon breach meant a foreign government likely possessed more knowledge about who the u.s. government surveils than american citizens themselves have access to. the eff's assessment was blunt: "you cannot build a backdoor that only lets in good guys and not bad guys." the risk from within the external threat is only half the picture. surveillance infrastructure is also subject to misuse by the people authorized to operate it — and the safeguards designed to prevent that misuse are thinner than they appear. consider the court order requirement. calea's framework assumes that judicial oversight acts as a meaningful check on surveillance: law enforcement must obtain a court order before a wiretap can be activated. in practice, wiretap applications are almost never denied. the administrative office of the u.s. courts' annual wiretap reports document this consistently. in 2015, zero applications were denied out of 4,148 authorized. in 2016, two were denied out of 3,168. in 2018, two out of 2,937. in 2013 and 2014, one each. across tens of thousands of applications over decades, the denial rate has been functionally zero. this doesn't necessarily mean courts are rubber-stamping requests — prosecutors may simply self-select cases they know will be approved — but it does mean the judicial check operates more as a procedural formality than a meaningful constraint. beyond the formal wiretap process, the broader pattern of law enforcement database misuse is well-documented. a 2016 associated press investigation found that police officers across the country routinely misuse confidential law enforcement databases — including the fbi's national crime information center (ncic), which processes an average of 14 million transactions daily — for personal purposes. officers looked up romantic interests, ex-partners, journalists who covered their departments unfavorably, and personal acquaintances. the ap found that between 2013 and 2015, officers were fired, suspended, or resigned over database misuse more than 325 times. they received lesser discipline more than 250 additional times. the ap emphasized that their count was "unquestionably an undercount," as no single agency tracks misuse nationally and record-keeping is inconsistent. the worst punishment in many cases was a reprimand. at the intelligence community level, the nsa's own inspector general documented what analysts internally called "loveint" — a play on intelligence terminology like sigint and humint — referring to employees using surveillance tools to monitor romantic interests or ex-partners. in a 2013 letter to senator charles grassley, nsa inspector general george ellard disclosed 12 substantiated cases of intentional misuse over the preceding decade. one analyst entered six email addresses belonging to an ex-girlfriend into a surveillance system on his first day of access, claiming he "wanted to practice." the worst administrative sanction was a two-month pay reduction and a demotion. most employees involved resigned before discipline could be imposed. the justice department declined to prosecute the one case referred to it. these are the documented cases. the nsa noted that most loveint incidents were "self-reported," typically surfacing during polygraph examinations for security clearance renewals — meaning detection depends heavily on the honesty of the people being tested. perhaps most concerning is the practice of parallel construction, documented by reuters in 2013 and subsequently investigated by human rights watch in a 2018 report titled "dark side: secret origins of evidence in us criminal cases." the dea's special operations division (sod) — which includes representatives from the fbi, nsa, cia, irs, and dhs — funnels intelligence from surveillance intercepts and classified sources to field agents, who then construct an alternative, seemingly independent evidence trail to use in court. the original surveillance-derived source is hidden from prosecutors, judges, and defense attorneys. a senior dea official told reuters that parallel construction is "a law enforcement technique we use every day" and called it "decades old, a bedrock concept." the constitutional concern is straightforward: if defendants don't know how an investigation actually began, they cannot challenge the legality of the methods used to find them. the fruit of the poisonous tree doctrine — which normally bars illegally obtained evidence — becomes unenforceable when the tree itself is hidden. none of this proves that calea intercept infrastructure is being routinely misused by domestic law enforcement. but it establishes a pattern: when surveillance tools exist, some fraction of the people authorized to use them will use them for unauthorized purposes. the more powerful and centralized the tool, the greater the potential for abuse. and the oversight mechanisms — court orders, internal audits, inspector general reviews — consistently prove to be weaker in practice than they are on paper. where this leaves us calea is not going away. it reflects a legitimate law enforcement need — courts issue wiretap orders, and carriers must be able to comply with them. the question is not whether lawful intercept capability should exist, but whether the current approach to implementing, securing, and overseeing it is adequate given both the external threat landscape and the documented history of internal misuse. the salt typhoon breach demonstrated that mandating surveillance infrastructure without equally mandating its security creates a systemic vulnerability in national communications infrastructure. the greek wiretapping case demonstrated the same thing twenty years earlier. the pattern of domestic misuse — from loveint to parallel construction to routine database abuse — demonstrates that the human factors are just as real as the technical ones. the oversight mechanisms designed to prevent abuse have repeatedly proven insufficient to catch or deter it. none of this requires a conspiratorial worldview to find concerning. the facts are publicly documented, the risks are well-understood by the technical community, and the policy tradeoffs are real. the policy response is already underway but far from settled. the fcc has initiated a rulemaking to impose explicit cybersecurity obligations on carriers under calea's section 105 — an acknowledgment that mandating intercept capability without equivalently mandating its security was a structural failure. cisa and allied intelligence agencies have begun recommending end-to-end encrypted messaging — a notable shift from agencies that have historically opposed strong encryption — as a practical defensive measure in light of salt typhoon. meanwhile, the "going dark" debate continues in congress, with some proposals that would expand mandated access rather than reduce it. for individuals, the immediate practical step is straightforward: use end-to-end encrypted communications (signal, imessage, whatsapp) wherever possible. for policymakers and engineers, the harder question remains open: whether the calea model of centralized, carrier-level intercept capability can ever be made secure enough to justify the systemic risk it creates, or whether the thirty-year experiment has produced its verdict. references 1. communications assistance for law enforcement act, 47 u.s.c. §§ 1001–1010 (1994). full text available at epic archive. 2. federal communications commission, "calea" — overview and ssi plan filing requirements. fcc.gov/calea. 3. administrative office of the u.s. courts, "wiretap reports" (1997–2024). uscourts.gov. 4. administrative office of the u.s. courts, "2024 wiretap report: intercepts and convictions rise" (june 30, 2025). uscourts.gov. 5. fcc fact sheet, "implications of salt typhoon attack and fcc response" (december 5, 2024). docs.fcc.gov. 6. federal register, "protecting the nation's communications systems from cybersecurity threats" (december 15, 2025). federalregister.gov. 7. prevelakis, v. and spinellis, d., "the athens affair," ieee spectrum (july 2007). spectrum.ieee.org. 8. electronic frontier foundation, "salt typhoon hack shows there's no security backdoor that's only for the 'good guys'" (october 2024). eff.org. 9. sentinelone, "malicious apprentice: how two hackers went from cisco academy to cisco cves" (december 2025). sentinelone.com. 10. nextgov/fcw, "hundreds of organizations were notified of potential salt typhoon compromise" (december 30, 2024). nextgov.com. 11. congressional research service, "the communications assistance for law enforcement act" (report rl30677). everycrsreport.com. 12. new lines institute, "2024: when china's salt typhoon made cyberspace tidal waves" (october 2025). newlinesinstitute.org. 13. associated press, "across us, police officers abuse confidential databases" (september 28, 2016). cbsnews.com. 14. nsa inspector general george ellard, letter to sen. charles grassley re: intentional misuse of sigint authorities (september 2013). reported by nbc news: nbcnews.com. 15. shiffman, j. and cooke, k., "exclusive: u.s. directs agents to cover up program used to investigate americans," reuters (august 5, 2013). referenced in human rights watch report. 16. human rights watch, "dark side: secret origins of evidence in us criminal cases" (january 9, 2018). hrw.org. 17. muckrock, "dea teaches agents to recreate evidence chains to hide methods" (february 3, 2014). muckrock.com. 18. administrative office of the u.s. courts, wiretap reports 2013–2018 (denial rate data). available at uscourts.gov.

Wired for Surveillance

--- introduction quantum computing will eventually break the encryption that protects most data in transit today. this isn't a distant hypothetical — adversaries are already preparing by collecting encrypted data now, banking on future quantum capabilities to decrypt it later. for organizations handling data with long-term sensitivity, the question isn't whether to prepare, but how. air-gapping offers something that no encryption algorithm can: it removes the network as a collection vector entirely. data that never traverses a network can't be passively harvested, regardless of how powerful future decryption becomes. harvest now, decrypt later the "harvest now, decrypt later" attack is straightforward. an adversary with access to encrypted network traffic — whether through a compromised isp, a tapped undersea cable, or a breach at a cloud provider — records everything. the data is meaningless today because current computers can't break the encryption in any reasonable timeframe. but quantum computers will change that math. this threatens two of the three pillars of the cia triad. confidentiality is the obvious one — encrypted data becomes readable. but integrity is also at risk: if an adversary can break the cryptographic signatures that verify data hasn't been tampered with, they can potentially forge trusted communications. the data most at risk has a long shelf life. medical records remain sensitive for a patient's lifetime. classified government information may carry decades-long protection periods. financial data, intellectual property, legal communications, and trade secrets all retain value well beyond the horizon when quantum decryption may become practical. the scale of the problem is daunting. one organization conducting a cryptographic inventory found 4,000 custom cryptographic implementations across their systems. at one conversion per day, remediation would take over a decade. as one security professional put it: "you can't secure what you can't see. and you can't fix the crypto you don't know about." why air-gapping mitigates this the core insight is simple: data that never touches a network can't be harvested from one. the "harvest now, decrypt later" attack depends on passive collection — intercepting encrypted data as it flows across networks. air-gapping eliminates this vector entirely. when sensitive data moves only on physical media across a physical air gap, an adversary needs physical access to the transfer media, not just network proximity or a compromised router. this is the sneakernet's security advantage. a usb drive carried across a room is not routable, not interceptable at a network tap, and not stored in some transit log at a cloud provider. the transfer is a discrete physical event that happens in a specific place at a specific time, observable by the people involved. for environments handling data with decades-long sensitivity — healthcare, defense, legal, financial — air-gapping buys time that no encryption algorithm can guarantee right now. post-quantum cryptographic standards are still maturing. nist has published initial post-quantum algorithms, but widespread adoption across the software ecosystem will take years. air-gapping provides protection during that transition by removing the collection opportunity altogether. this echoes the thesis from why air-gapping?: air-gapping collapses continuous, distributed exposure into discrete, auditable events. in the quantum context, "continuous exposure" means every packet of encrypted data flowing across a network is a potential future plaintext. the air gap reduces that to only the data deliberately placed on physical media — a dramatically smaller and more controllable surface. how airgap transfer supports this moving sensitive data across an air gap requires more than just copying files to a usb drive. you need integrity verification, audit trails, and a way to handle transfers that exceed a single drive's capacity. this is what airgap transfer is built for. - hash verification. every file transferred across the air gap is verified with cryptographic hashes. integrity is confirmed at the point of transfer, not assumed. if something changes between the source system and the air-gapped destination — whether from drive corruption, tampering, or a faulty copy — you'll know before the data enters the secure environment. - manifest tracking. airgap transfer generates json manifests documenting exactly what crossed the gap: file names, sizes, hash values, chunk assignments, and verification status. this is the audit trail that makes air-gapped transfers accountable. when compliance requires demonstrating chain of custody for sensitive data, the manifest is the record. - multi-drive chunking. sensitive datasets frequently exceed single-drive capacity. medical imaging archives, ml training data, financial modeling datasets — these routinely run into tens or hundreds of gigabytes. airgap transfer splits large transfers across multiple usb drives with integrity preserved across chunks, then reconstructs and verifies on the other side. - no network exposure. the transfer mechanism is physical media, not a network protocol. there's no tcp stream to intercept, no tls handshake to record, no encrypted packet to store for future decryption. the "harvest now" phase of the attack has nothing to harvest. cryptographic bill of materials preparing for the quantum era requires knowing what cryptographic algorithms your systems actually use. a cryptographic bill of materials (cbom) extends the sbom concept by inventorying not just your software components, but the specific cryptographic implementations they rely on. on an air-gapped system, maintaining a cbom serves two purposes: 1. planning. you know which components need post-quantum replacement and can prioritize based on the sensitivity of the data they protect. a hashing algorithm used for file integrity checks has different urgency than an encryption algorithm protecting patient records at rest. 2. crypto agility. security professionals use this term to describe systems designed so that cryptographic algorithms can be swapped without rearchitecting the entire application. when post-quantum standards are finalized and implementations are ready, you need a process to get those updates into the air-gapped environment. the same disciplined transfer workflow that manages your software dependencies can manage cryptographic updates. download the new implementations on the connected side, verify them, transfer across the air gap with airgap transfer, and deploy to the air-gapped system. the air gap doesn't prevent upgrades — it ensures they happen deliberately, with verification at every step. conclusion air-gapping doesn't solve the quantum threat. nothing does yet — post-quantum cryptography is still being standardized and adopted. but air-gapping removes the most scalable attack vector: passive network collection. combined with sboms and cboms for visibility, a deliberate update cadence for cryptographic agility, and tools like airgap transfer for verified physical transfers, it's a practical strategy for protecting sensitive data while the rest of the ecosystem catches up. the organizations most at risk are those handling data that will still be sensitive a decade from now. for them, the question isn't whether quantum computers will eventually break today's encryption — it's whether their data is being collected off the wire right now. air-gapping ensures it isn't. while "harvest now, decrypt later" targets encrypted traffic for future decryption, network surveillance infrastructure enables real-time collection today. for how mandated surveillance capabilities have already been exploited by foreign adversaries, see wired for surveillance. for the broader case for air-gapping as a security strategy, see why air-gapping?. for how air-gapping applies to software supply chain security, see air-gapping your software supply chain. for the full suite of tools, see privacy-first tools for air-gapped environments. references - securing ai for the quantum era - nist post-quantum cryptography project - cisa/nsa esf: securing the software supply chain — oss and sboms (december 2023)

Air-Gapping in the Quantum Era

--- introduction the software supply chain is under increasing attack. incidents like log4shell and the xz utils backdoor have demonstrated how deeply embedded vulnerabilities in open-source dependencies can compromise entire systems. in response, cisa, nsa, and the enduring security framework have published guidance on managing open-source software and sboms that recommends creating deliberate boundaries between external sources and development environments. air-gapping is a natural fit for these recommendations. if you've read why air-gapping?, you know the core thesis: air-gapping collapses a distributed, continuous attack surface into discrete, auditable events. software supply chain security is one of the clearest use cases for that principle. the problem: your build depends on the internet modern development workflows pull dependencies from public registries on every build. , , — each command reaches out to a centralized package manager, downloads code written by strangers, and executes it on your machine. this happens so frequently that most developers don't think about it. but package managers are what cisa describes as "centralized nodes" for software distribution, and they're increasingly under attack. the problem isn't hypothetical. open source creates an estimated $8 trillion in annual value, but only $4 billion is invested back — and 96% of that value is created by just 5% of core maintainers. this imbalance creates fragility. the internet calls it the "nebraska problem," after the xkcd comic about all of modern infrastructure depending on a project one person in nebraska has been maintaining since 2003. in reality, there are thousands of these dependencies across enterprise supply chains. when one of those dependencies is compromised — whether through a maintainer's account being hijacked, a malicious contribution slipping through review, or a backdoor inserted into build infrastructure — every system that pulls from that registry is exposed. the attack surface is continuous and largely invisible. what cisa recommends: the secure repository workflow the cisa/nsa enduring security framework guidance on managing open-source software outlines a multi-stage workflow for vetting open-source components before they reach development environments: 1. developer selects a component from external libraries and dependencies. 2. component is downloaded and scanned — initial automated checks catch known vulnerabilities. 3. intermediate secure repository — the component is reviewed, scanned, and tested using tools like software composition analysis (sca) before being promoted to the shared secure repository. 4. secure repository — additional sca is performed. continuous checks monitor for new vulnerabilities, version updates, patches, and licensing issues. notifications are sent when new threats or updates are discovered. 5. component passes initial testing — the developer is notified to download from the secure repository. or, if an issue is found, developers who already downloaded the vulnerable component are notified. 6. development repository — vetted components are available for use in builds. the key insight is that this workflow creates deliberate boundaries. components don't flow directly from the internet into your build. they pass through stages of review, each adding a layer of verification. cisa's enterprise recommendations reinforce this: run internal build systems, cache all dependencies internally, and maintain what they call "basic hygiene of good open source consumption." where air-gapping fits in the secure repository workflow is conceptually an air gap. it separates external sources from development through deliberate, auditable transfer points. air-gapping makes this separation physical rather than just logical. in an air-gapped supply chain workflow: - connected side: a system with internet access downloads dependencies, runs sca tools, checks against vulnerability databases, generates sboms, and stages approved packages for transfer. this is your intermediate secure repository. - the air gap: approved packages are transferred via physical media (usb drives, optical media). nothing crosses automatically. every transfer is a deliberate act. - air-gapped side: the development environment receives vetted packages into its secure repository. builds pull only from this local, curated mirror. the development machines never have direct internet access. this maps directly to the cisa workflow. the air gap is the boundary between the intermediate secure repository and the secure repository. every dependency that crosses it is a discrete, auditable event — exactly the property that makes air-gapping effective as a security measure. the advantage over a purely logical separation (network segmentation, firewall rules) is that the air gap can't be misconfigured, bypassed by a compromised process, or eroded by convenience shortcuts. if a dependency isn't on the usb drive, it doesn't exist in the build environment. practical recommendations if you're considering air-gapping your software supply chain, here's what the workflow looks like in practice: - maintain an internal package mirror. cache approved dependencies in an offline-accessible repository. tools like verdaccio (npm), devpi (python), or a simple file-based cargo registry can serve packages to your air-gapped build environment without internet access. - use sboms to track what crosses the gap. every transfer should be accompanied by a software bill of materials documenting exactly what's included — package names, versions, licenses, and transitive dependencies. this is the audit trail that makes the air gap meaningful. - verify before transfer. run sca tools and vulnerability scanners on the connected side before anything crosses to the air-gapped environment. the connected system is where you check against cve databases, run openssf scorecard assessments, and evaluate component health. - hash everything. use cryptographic hashes to verify file integrity across the transfer. if something changes in transit, you need to know. airgap transfer automates this with hash verification for every file that crosses the boundary. - audit the crossing points. log every dependency transfer — what crossed, when, who approved it, and what verification was performed. the air gap collapses continuous risk into discrete, reviewable events. make the most of that property. - plan for updates. air-gapping your supply chain doesn't mean freezing it. vulnerability notifications on the connected side should trigger a review-and-transfer cycle for patches. define a cadence for routine updates and an expedited process for critical security fixes. conclusion air-gapping your software supply chain isn't just for classified environments. it's a practical implementation of the boundaries that cisa and the enduring security framework recommend for any organization that depends on open-source software. the workflow is straightforward: download and verify on the connected side, transfer deliberately across the gap, build from curated local mirrors on the air-gapped side. the tools exist. the guidance exists. the question is whether the friction of deliberate transfers is worth the security it provides. for environments where software integrity matters — and where a compromised dependency could mean more than a service disruption — the answer is increasingly yes. for more on why air-gapping works as a security strategy, see why air-gapping?. for tools that make air-gapped workflows practical, see privacy-first tools for air-gapped environments. for how air-gapping addresses emerging quantum threats like "harvest now, decrypt later" attacks, see air-gapping in the quantum era. for how mandated surveillance infrastructure creates systemic network vulnerabilities, see wired for surveillance. references - cisa/nsa esf: securing the software supply chain — recommended practices for managing oss and sboms (december 2023) - cisa announcement: new guidance on securing the software supply chain - making open source secure by design — cisa at rustconf - openssf scorecard

Air-Gapping Your Software Supply Chain

--- introduction a sneakernet is the practice of transferring data by physically carrying storage media between computers. the term dates back to the 1980s — a joke about wearing sneakers to walk a floppy disk down the hall. before broadband, this was just how things worked. floppy disks, zip drives, burned cds, passed hand to hand. the funny thing is, sneakernets never really went away. they just stopped being the default. and for certain use cases — large files, privacy-sensitive data, unreliable connections, or just the satisfaction of handing someone a physical thing — they're still the best option. amazon's now-retired snowmobile service, which physically trucked exabytes of data to aws data centers in a 45-foot shipping container, was a sneakernet. so is handing your friend a usb drive with photos from last weekend's trip. this post is an invitation: start a sneakernet with your friends. it's practical, it's private, and it's more fun than you'd expect. why would you want one? the case for a sneakernet isn't about paranoia. it's about practicality. large file sharing without the wait. most home internet connections have asymmetric speeds — downloads are fast, uploads are slow. a 200gb video archive from a group trip could take days to upload to a cloud service on a typical 10 mbps upload connection. copy that same archive to a usb 3.0 external drive and it takes minutes. for large transfers, the physical layer wins on raw throughput. as andrew tanenbaum famously put it: "never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." no accounts, no terms of service, no file size limits. cloud services decide what you can share, how long it stays, and who can access it. free tiers impose storage caps. upload limits are common. content policies can flag or remove files you've shared. a usb drive doesn't have terms of service. it holds what you put on it, for as long as you want, and nobody else has a say. geographic backup redundancy without monthly fees. one of the oldest strategies in data protection is the offsite backup — keeping a copy of important data in a physically separate location. cloud storage solves this, but it costs money every month and requires trusting a third party with your data. a sneakernet solves it too: your friend across town has a copy of your important files. no subscription required. no data center outage can touch it. swap updated backup drives every month or two and you've got a distributed, resilient storage network for the cost of a couple of usb drives. curated libraries. this is where sneakernets get fun. share a collection of development tools, linux isos, ebook archives, music playlists, photography presets, game mods — whatever your group is into. think of it as a lending library with no late fees. a friend curates a drive of open-source software they've vetted. another maintains a collection of conference talks and technical podcasts. each drive reflects someone's taste and effort, which makes it more interesting than a search engine result. it's satisfying. there's something tangible about handing someone a drive. it's a gift, not a notification. you can label it, decorate it, put a sticker on it. the physical exchange creates a moment — a brief conversation about what's on the drive, what's worth checking out, what you've been working on. that social layer doesn't exist when you paste a google drive link into a chat window. what you need the barrier to entry is low: - a few usb drives. usb 3.0 flash drives are cheap and widely available. for larger transfers, a portable ssd offers better speed and durability. a 1tb portable ssd costs around the same as a few months of cloud storage — except you own it forever. - friends. this is the hard part. a sneakernet is a social protocol. you need people who are interested in sharing files, who you see regularly enough to swap drives, and who have things worth sharing. coworkers, neighbors, members of a local tech meetup, d&d groups, photography clubs — any community with shared interests and regular in-person contact. - optional: airgap transfer for hash verification and multi-drive chunking. for casual exchanges — a folder of photos, a few isos — you don't need anything beyond drag-and-drop. but when transfers get larger or integrity matters, airgap transfer adds cryptographic hash verification to confirm nothing got corrupted in the copy, and automatic multi-drive chunking when your data exceeds a single drive's capacity. it turns a casual sneakernet into a reliable one. how it works a sneakernet exchange is simple. here's the workflow: 1. curate. decide what you want to share. photos from a trip, a software toolkit, a dataset, a backup archive, a music collection. the best sneakernet contributions are things that are useful, large enough that downloading them would be annoying, or personal enough that you wouldn't want to upload them to a cloud service. 2. load. copy the files onto a drive. if you want peace of mind, use airgap transfer — it generates cryptographic hashes during the copy, so you (and the recipient) can verify that every file arrived intact. this is especially useful for large archives where a single corrupted file might not be immediately obvious. 3. hand it off. at the office, at dinner, at a meetup, in the parking lot. the transfer protocol is a handshake. no bandwidth caps, no upload progress bars, no "link expired" messages. the exchange itself is a social interaction — you'll probably end up talking about what's on the drive, which is half the fun. 4. verify and copy. the recipient plugs in the drive and copies what they want. if you used airgap transfer, verification is automatic — the tool checks every file's hash against the manifest and flags anything that doesn't match. otherwise, a quick spot-check of a few files is usually enough for casual exchanges. 5. return or circulate. the drive comes back to you, or it moves on to the next person in the group. some sneakernets work best as a direct exchange (you lend a drive, it comes back). others work as a circulating library (a drive makes the rounds, and people add or take content as it passes through). level it up once your sneakernet is running, there are ways to make it more interesting. the rotating library designate a drive as communal. it circulates through your group on a schedule — weekly, biweekly, whenever you see each other. each person adds content and takes what they want. over time, the drive becomes a shared archive that reflects the collective interests of the group. one pass it has a folder of conference talks; the next time around, someone's added a photography tutorial series and a collection of zines. the key is that it's curated. unlike an infinite cloud folder, a physical drive has a finite capacity, which forces people to be intentional about what they contribute. that constraint makes the library more interesting, not less. neighborhood software mirror if your group includes developers, sysadmins, or anyone who regularly downloads large software packages, a sneakernet mirror saves everyone time and bandwidth. one person downloads os updates, development toolchains, container images, language packages, and ide extensions. the rest of the group copies what they need from the drive instead of each pulling the same gigabytes individually. this is especially valuable if anyone in the group has bandwidth caps or slow connections. it's also how air-gapped development environments manage software dependencies — see packaging rust applications for air-gapped systems for how to package complete application builds for offline deployment. photo and video co-op group trips, weddings, family reunions, and community events generate gigabytes of photos and video across everyone's phones and cameras. the usual approach is "everyone uploads to google photos and shares the album." in practice, half the group forgets, the uploads take forever on hotel wi-fi, and the cloud service compresses your videos. a sneakernet co-op is simpler: bring a drive to the event. everyone dumps their photos and videos onto it at the end of the day. one person takes it home, organizes it, and circulates copies. the full-resolution originals stay intact, no cloud compression, no waiting for uploads, no "storage full" warnings. local ai model sharing large language models are huge. a single ollama model can be 4-8gb, and a full local ai setup with multiple models can easily hit 50gb or more. if your friend group is interested in running local llms, a sneakernet means one person downloads the models and passes the drive around instead of everyone pulling the same multi-gigabyte files over the internet. this is exactly the workflow that airgap transfer was designed for. it handles multi-usb orchestration for packages that exceed a single drive's capacity, with manifest tracking and hash verification across chunks. what works for deploying ai models to secure facilities works just as well for sharing them with friends. game mods and creative assets modding communities have been running informal sneakernets for decades — sharing mod packs, texture overhauls, and custom maps on physical media at lan parties and meetups. a deliberate sneakernet makes this systematic. maintain a drive of vetted, compatible mod packs for the games your group plays. add asset libraries for creative work — blender models, music samples, lightroom presets. the physical medium encourages curation over hoarding. the privacy angle this isn't the primary reason to start a sneakernet, but it's worth noting: a sneakernet is inherently private. no cloud provider scans or indexes your shared files. there's no metadata trail of who shared what with whom and when. there are no analytics dashboards tracking how many times a file was accessed. you control the copies — there's no "shared link" that lives forever and can be revoked by a service provider, leaked by a breach, or included in a data request. the data exists in exactly the places you put it and nowhere else. not on a server in a data center you've never visited, managed by a company whose privacy policy is 8,000 words long. on your drive, and on your friend's drive. that's it. this matters more than most people realize. for an evidence-based look at why privacy is important — even when you have "nothing to hide" — see the case for privacy. getting started start small. one drive. one friend. one batch of files. pick something worth sharing — a folder of photos, a curated music collection, a set of useful tools — and load it onto a usb drive. next time you see your friend, hand it over. that's your sneakernet. see what happens. if it's useful, do it again. if other people are interested, expand the group. the tools don't need to be complicated. for casual exchanges, drag-and-drop is fine. when your sneakernet grows and integrity matters, airgap transfer adds hash verification, multi-drive chunking, and manifest tracking. for best practices on keeping your usb drives secure, see usb security for airgap data transfers. the oldest file-sharing protocol is still one of the best. it's fast, it's private, it scales to any file size, and it comes with a built-in social layer that no cloud service can replicate. all you need is a drive and a friend.

Start a Sneakernet with Your Friends

--- introduction air-gapped systems exist for a reason — they're isolated from networks to protect sensitive data. but that isolation creates a challenge: how do you get data in and out? for most people, the answer is usb drives. this creates a security tradeoff. the same physical media that lets you move data safely offline can also introduce risks. understanding these risks helps you transfer data confidently. what you're actually worried about usb threats fall into a few categories, ordered by how likely you are to encounter them: malicious files on the drive the most common risk. an infected source system writes malware to the drive alongside (or instead of) your intended files. when you open them on the air-gapped system, you've bridged the gap. airgap transfer's hash verification helps here — if a file doesn't match its expected hash, something changed it. for background on how malware propagates via removable media, see nist sp 800-83. badusb and hid attacks some usb devices can be programmed to impersonate keyboards or other trusted device types. plug in what looks like a flash drive, and it types commands at superhuman speed. this requires a malicious or compromised device, not just malicious files. the original badusb research by karsten nohl and jakob lell demonstrated this class of attack. firmware-level compromise usb drive controllers have firmware that's largely invisible to your computer. sophisticated attackers can modify this firmware to hide data, inject malware, or behave maliciously while appearing normal. this is rare — it's targeted attack territory, not something in commodity malware. verifying firmware integrity is beyond what most users can do themselves. if your threat model includes firmware-level attacks, consult a cybersecurity professional who can advise on hardware verification, trusted supply chains, or alternative transfer methods appropriate to your situation. dma attacks not relevant to standard usb drives, but worth knowing: thunderbolt and usb4 devices can directly access system memory. use iommu protections if your workflow involves these ports. see thunderclap research for details on dma-based vulnerabilities. choosing and verifying drives no usb drive comes with a "verified secure" guarantee, but you can reduce risk: - buy from reputable sources. purchase directly from manufacturers or authorized retailers. avoid secondary marketplaces or suspiciously cheap deals. supply chain interception is a real (if uncommon) attack. - prefer simple over smart. basic drives have less firmware complexity than drives with fingerprint readers, hardware encryption chips, or wireless features. less complexity means less attack surface. if you need encryption, software-based full-disk encryption on a simple drive is often preferable to proprietary hardware encryption you can't audit. - consider write-once media for sensitive transfers. for one-way transfers into an air-gapped system, optical media (dvd-r, bd-r) eliminates firmware concerns entirely. the drive can't be reprogrammed because the media is physically write-once. - dedicated drives for sensitive workflows. don't use the same drive for air-gap transfers and general-purpose file sharing. dedicate specific drives to specific workflows and label them clearly. what to look for in a drive if you're selecting drives for security-sensitive workflows, consider: - transparent supply chain. manufacturers that sell direct and have clear sourcing are preferable to white-label or no-name brands where origin is unclear. - no unnecessary features. wifi connectivity, companion apps, and cloud integration are attack surface you don't need. a drive that just stores data is ideal. - metal casing. not a security feature per se, but physical durability matters when drives are handled frequently. it also makes tampering slightly more evident than flimsy plastic. - standard usb mass storage protocol. avoid drives that require special drivers or software to function. if the os doesn't recognize it as simple removable storage, something extra is running. - user-replaceable or verifiable components (if available). some security-focused drives allow firmware verification or use open hardware designs. these are niche but exist for high-security applications. for most users, a basic drive from a well-known manufacturer, purchased through official channels, is sufficient. the goal is reducing variables, not achieving perfection. practical habits - verify file integrity. airgap transfer generates and checks hashes for transferred files. use this. if a hash doesn't match, don't trust the file — investigate why it changed. - minimize the bridge. transfer only what you need. every file crossing the air gap is a potential vector. - keep the air-gapped system minimal. disable autorun. don't open files you weren't expecting. consider a read-only os configuration where possible. - have a plan for untrusted drives. if someone hands you a usb drive, assume it's hostile until proven otherwise. inspect it on a dedicated, isolated machine before it touches anything sensitive. some organizations use write-blocking hardware for this. what airgap transfer does airgap transfer verifies file integrity using cryptographic hashes, so you'll know if something was modified in transit. future versions will add support for encrypted drives and additional protections against malicious files. the goal is simple: make the transfer process auditable and trustworthy, so the air gap stays meaningful.

USB Security for Airgap Data Transfers

--- introduction deploying software to systems without internet access usually means manually tracking down every dependency. airgap deploy automates this—packaging rust applications with everything they need into a single transferable archive. the challenge: deploying software without the internet you've built a useful application—maybe a data analysis tool, a monitoring system, or a transcription app. it works perfectly on your development machine. now you need to deploy it to a production environment that has no internet access. the traditional approach looks like this: 1. manually download every dependency listed in your project 2. download the correct version of the rust toolchain 3. collect platform-specific build tools 4. copy everything to usb drives 5. transfer to the offline system 6. try to build from source 7. discover you forgot a dependency 8. start over each iteration takes days. you discover missing pieces only after walking usb drives across the building. your colleagues start to dread the phrase "just one more dependency." why is this so hard? modern software has complex dependency chains. a typical rust application might depend on 50+ crates, each potentially pulling in its own dependencies. some crates need c libraries. some have build-time dependencies different from runtime dependencies. manual tracking is error-prone and frustrating. for organizations working in: - government: classified environments with strict air-gap requirements - finance: isolated trading systems that can't connect to external networks - healthcare: systems processing protected health information (phi) - research: secure labs analyzing sensitive data this deployment challenge isn't just annoying—it's a blocker. projects get delayed because deployment is too difficult. --- the solution: airgap deploy airgap deploy automates the entire workflow. you describe what you want to package in a simple, human-readable manifest file. run one command. it downloads everything needed, packages it into a single archive, and generates platform-specific installation scripts that build and install your application completely offline. the workflow: create a deployment manifest → run the prep command → transfer the package → run the install script. everything builds and installs automatically on the air-gapped system. no missing dependencies. no manual steps. no iteration. the manifest captures everything you need, so nothing gets forgotten. for detailed technical specifications, see the airgap deploy documentation. this post focuses on the workflow. --- packaging in action scenario: deploying your rust application you've built a data processing application in rust. it needs to run on an air-gapped linux server in your organization's secure environment. step 1: create the deployment manifest you create a simple manifest file that describes your application: - your rust project (with all its dependencies) - the rust toolchain needed to build it - any external tools or libraries required - the target platform (linux, macos, or windows) the manifest uses a straightforward format—you're describing what you need, not writing complex deployment scripts. think of it as a shopping list for your deployment. step 2: run the prep command on your internet-connected machine, you run one command. airgap deploy: - reads your manifest - downloads all rust crate dependencies and vendors them (copies them locally) - includes the rust toolchain installer for your target platform - collects any external binaries or libraries - validates that everything is present - creates a single compressed archive (tar.gz or zip) - generates a platform-specific installation script this takes a few minutes depending on your project size. when it's done, you have one file containing everything needed. step 3: transfer across the air gap copy the archive to a usb drive. walk it to the air-gapped system. (or if the package is larger than your usb capacity, use airgap transfer to chunk it across multiple drives.) step 4: install on the air-gapped system extract the archive. run the generated install script. it: - installs the rust toolchain (if needed) - builds your application using the vendored dependencies - runs tests (if specified) - installs the binary to the appropriate location - sets up configuration files - verifies the installation the offline system doesn't need internet access—all dependencies are included in the package. --- beyond basic deployment complex applications with multiple components what if your application depends on external tools? maybe you're building an offline transcription system that needs both your rust application and the whisper.cpp binary. airgap deploy handles this: your manifest can specify: - your rust application - the whisper.cpp repository (cloned and built automatically) - pre-trained model files (downloaded with checksum verification) - any required system libraries one manifest. one package. one install command. everything works together. cross-platform support need to deploy to both linux servers and windows workstations? create separate manifests for each platform (or use conditional logic in a single manifest). each package includes the right toolchain and generates the right install script for its target platform. reproducible builds six months from now, you need to rebuild the exact same version. your deployment manifest acts as documentation—it specifies exact version numbers, checksums, and build instructions. reproducibility is built in, not bolted on. integration with ci/cd airgap deploy fits naturally into continuous integration pipelines. your ci system creates deployment packages automatically as part of the release process. when it's time to deploy to air-gapped production, the package is ready and validated. --- why this matters eliminates human error manual dependency tracking is error-prone. you forget packages. you download the wrong versions. you miss build-time dependencies. airgap deploy's manifest system ensures consistency—the same manifest produces the same package every time. saves time and frustration this removes the iteration cycles and repeated usb walks to fetch forgotten dependencies. create the package once, install it once, done. enables secure deployment air-gapped environments exist for a reason—they protect sensitive data and critical systems. but if deployment is too hard, people find workarounds that compromise security. airgap deploy removes the temptation to bypass security for convenience. declarative and transparent the manifest file is human-readable. anyone can review it and understand what's being deployed. this transparency is crucial for security reviews and compliance audits. open source airgap deploy is open source with no external dependencies beyond the rust toolchain. --- getting started airgap deploy will be available as part of the v1.0.0 release. once released, you'll be able to: 1. install airgap deploy (single binary, no dependencies) 2. create a manifest for your application 3. run the prep command on a connected system 4. transfer and install on air-gapped systems example manifests will be provided for common scenarios: - simple rust cli applications - applications with c library dependencies - multi-component systems (like cleanroom whisper + whisper.cpp) - large ml deployments (see the ollama deployment post) want to learn more? - airgap deploy documentation - full project overview - ollama deployment workflow - detailed technical example - privacy-first tools for air-gapped environments - how all three projects work together

Packaging Rust Applications for Air-Gapped Systems

--- introduction large ml models like ollama often exceed the capacity of a single usb drive, making air-gapped deployment a logistical challenge. this walkthrough shows how airgap transfer and airgap deploy work together to split, transfer, and reconstruct large packages across the air gap. the challenge: when one usb drive isn't enough you're a data scientist working in a secure research environment. your team needs to deploy ollama—a local ai model runtime—along with the llama2-7b language model to an air-gapped analysis system. the combined package is about 20gb. there's one problem: your usb drives are 16gb each. the traditional approach: use command-line tools to manually split the archive into chunks. calculate sizes carefully so each chunk fits on a drive. keep detailed notes about which chunk goes on which drive. manually create checksum files. transfer drives one by one. reconstruct by hand on the other side. verify checksums manually. hope you didn't mix up any drives. it's tedious, error-prone, and nerve-wracking. one wrong checksum, one misplaced chunk, and you're starting over. each mistake means another walk across the secure facility to get the right usb drive. for packages containing: - large ml models: multi-gigabyte weights that don't compress well - development environments: complete toolchains with all dependencies - dataset archives: research data, training sets, simulation results - system images: virtual machines or container registries manual chunking isn't just annoying—it's a deployment blocker. --- the solution: airgap deploy + airgap transfer this is where the airgap tools work together. airgap deploy packages everything you need (application, dependencies, models) into a single deployment archive. airgap transfer handles the multi-usb orchestration automatically. the workflow: package with deploy → chunk with transfer → physically transfer usb drives → reconstruct with transfer → install with deploy's generated script. the process is automated, reducing human error. for technical details, see the ollama deployment workflow documentation. this post focuses on the end-to-end experience. --- step 1: package with airgap deploy on your internet-connected preparation machine, you create a deployment manifest that describes what you need: - ollama: the ai runtime (cloned from its github repository) - llama2-7b model: the pre-trained weights (~7gb, downloaded automatically) - build tools: everything needed to compile ollama on the target platform - dependencies: required system libraries run the airgap deploy prep command. it: - clones the ollama repository at the specified version - downloads the llama2-7b model file from ollama's model registry - verifies the model's checksum (cryptographic integrity check) - collects all build dependencies - creates a complete deployment package the result: a single tar.gz archive (~20gb) containing everything needed to get ollama running on your air-gapped system. no internet required on the target machine. but there's a problem—that 20gb archive won't fit on your 16gb usb drives. --- step 2: chunk with airgap transfer this is where airgap transfer solves the multi-usb challenge. on the same preparation machine, you run the pack command, specifying: - the source file (your 20gb deployment package) - the destination (your first usb drive) - the chunk size (16gb, or let it auto-detect from the usb capacity) what airgap transfer does: 1. analyzes the package: determines how many chunks are needed (in this case: two 16gb drives will cover the 20gb package) 2. creates chunks with metadata: splits the archive intelligently and creates a manifest file tracking: - total file size - number of chunks - chunk sizes - sha-256 checksums for each chunk - reconstruction instructions 3. writes to usb #1: fills the first drive with chunk 1 (~16gb) plus the manifest 4. prompts for usb #2: when the first drive is full, tells you to insert the next drive 5. writes to usb #2: writes the remaining data (~4gb) plus a copy of the manifest key features: - automatic verification: each chunk's checksum is calculated and stored - resume capability: if interrupted, you can continue without starting over - no manual tracking: the manifest handles everything automatically - platform-independent: works the same on linux, macos, and windows when it's done, you have two usb drives that contain your complete deployment package, split intelligently with full integrity protection. --- step 3: reconstruct and deploy you physically carry the two usb drives across the air-gap boundary. on the secure, isolated target system, you run the airgap transfer unpack command. what happens: 1. reads the manifest: transfer finds the manifest on the first usb drive and understands the complete package structure 2. locates all chunks: finds chunk 1 on usb #1 and prompts you to insert usb #2 for chunk 2 3. verifies integrity: before reconstructing, verifies each chunk's checksum against the manifest. this ensures no corruption occurred during transfer. 4. reconstructs the package: combines the chunks back into the original 20gb deployment archive 5. verifies final integrity: checks the complete reconstructed file's checksum against the original if any chunk fails verification, transfer tells you exactly which usb drive has a problem. no guessing. no detective work. once reconstruction succeeds, you have the complete deployment package on your air-gapped system. extract it and run the installation script that airgap deploy generated. it: - builds ollama from source (no internet needed—all dependencies are included) - installs the llama2-7b model in the correct location - configures ollama to use the local model - verifies the installation minutes later, ollama is running on your air-gapped system with the llama2-7b model available for inference. no manual dependency hunting. no missing files. no internet connection ever required. --- why this matters reliable verification manual chunking and verification is error-prone. airgap transfer automates it with cryptographic checksums, manifest tracking, and resume capability. eliminates the "sneaker net" pain points the physical transfer of usb drives ("sneaker net") is a reality in secure environments. airgap transfer makes it reliable: - no lost chunks (manifest tracks everything) - no corruption anxiety (checksums verify integrity) - no manual record-keeping (automated manifest) - no wasted time (resume capability on interruption) enables complex deployments without automated chunking, large deployments become impractical. with airgap transfer, deploying 50gb packages or 100gb datasets is just as straightforward as 5gb. the workflow doesn't change—only the number of usb drives. reproducible and auditable the manifest file serves as a complete record of what was transferred. for compliance-heavy environments (government, healthcare, finance), this audit trail is crucial. you can prove exactly what was deployed and verify its integrity cryptographically. --- next steps airgap transfer and airgap deploy will be available as part of the v1.0.0 release. once released, you'll be able to deploy ollama and other large applications to air-gapped systems with confidence. want to learn more? - airgap transfer documentation - full project overview and cli reference - airgap deploy documentation - packaging system documentation - ollama deployment workflow - detailed technical walkthrough - privacy-first tools for air-gapped environments - overview of all three tools

Deploying Ollama and Large Models Across the Air Gap

--- introduction learn how cleanroom whisper enables quick voice capture workflows—transcribing meeting notes, action items, and ideas locally without sending your audio to external servers. the challenge: staying focused while taking notes you're in a meeting. someone says something important—an action item, a decision, a brilliant idea. you want to capture it before it's forgotten, but typing breaks your flow. you lose track of the conversation while your fingers hunt for keys. by the time you've typed the note, the discussion has moved on and you've missed the context. the modern solution? cloud-based voice transcription tools like otter.ai or the built-in dictation on your phone. press a button, speak your thought, and text appears. it's convenient—until you remember where that audio is going. your meeting might contain: - sensitive customer data: names, account numbers, project details - unreleased product plans: features still under nda - internal discussions: personnel matters, strategic decisions - personal health information: if you're in healthcare or research every time you use cloud transcription, you're sending this audio to someone else's server. you're trusting their security, their policies, and their future business decisions. for many professionals—in government, healthcare, finance, or research—this simply isn't acceptable. and if you're working in an air-gapped environment? cloud tools aren't even an option. --- the solution: cleanroom whisper cleanroom whisper brings the convenience of voice transcription without the privacy compromise. it's a desktop application that runs completely offline, converting your voice to text using local processing. no network connection required. no data sent anywhere. the workflow is simple: press a global hotkey → speak your thought → press the hotkey again → your transcription appears instantly. copy it with another hotkey or click from the system tray menu. everything stays on your machine. all processing happens locally on your machine. for detailed technical specifications, see the cleanroom whisper documentation. this post focuses on how it works in practice. --- quick capture in action scenario: the morning standup you're in your daily team standup. as each person shares their updates, you want to capture the key points. with cleanroom whisper running in your system tray, here's what you do: capture #1: press the hotkey. the tray icon changes color—recording has started. you speak: "sarah blocked on api authentication. needs mark's input by thursday." press the hotkey again. within seconds, a notification appears with your transcription. you press the copy hotkey and paste it into your notes document. total time: 10 seconds. you never stopped listening to the meeting. capture #2: the product manager mentions a deadline shift. press hotkey: "launch date moved to march 15th. update roadmap and customer communications." press hotkey. copy. paste. done. capture #3: an important action item for you. press hotkey: "follow up with design team about mobile mockups. due friday." press hotkey. copy. paste into your task manager. the meeting ends. you have detailed notes without ever breaking eye contact or losing focus. everything was captured accurately because you spoke it naturally—no abbreviated typing, no missed words. what makes this work: - global hotkeys: record from any application without switching windows - background operation: no main window cluttering your screen - instant access: transcriptions available immediately in the tray menu - local history: review and copy past transcriptions anytime - complete privacy: audio never leaves your machine --- beyond meetings: everyday use cases quick task capture you're deep in focused work when you remember something: "email linda about q2 budget by monday." press the hotkey, speak it, done. the thought is captured without breaking your concentration. later, you review your transcription history and add it to your task list. documentation while working you're debugging a complex issue and discover the solution. press hotkey: "bug in database connection pool. fixed by increasing timeout from 5 to 30 seconds. may need to document this for the team." your future self thanks you for capturing this while it was fresh. accessibility for users with mobility limitations or repetitive strain injuries, typing can be painful or impossible. voice transcription becomes not just convenient but necessary. cleanroom whisper provides this capability without requiring cloud services that might not meet accessibility or privacy requirements. research and interviews researchers conducting interviews in privacy-sensitive contexts (healthcare, legal, social services) need transcription that never exposes participant data to third parties. cleanroom whisper processes everything locally, making it suitable for environments where data protection regulations are strict. --- why this matters privacy through architecture cleanroom whisper has no network code. it can't send data to external servers because it doesn't have the capability to make network requests. your audio is processed locally by whisper.cpp (a well-established open-source transcription engine) and stored in a local sqlite database. nothing leaves your machine. no subscriptions or accounts once installed, cleanroom whisper works indefinitely without accounts or subscriptions. cross-platform consistency whether you're on macos, windows, or linux, the experience is identical. the same hotkeys, the same interface, the same reliability. if you work across multiple machines, your workflow doesn't change. speed and reliability local processing means no waiting for network requests. transcription appears in seconds. there are no rate limits or service outages to deal with. --- getting started cleanroom whisper will be available as part of the v1.0.0 release. once released, you'll need: 1. the cleanroom whisper application (available as a pre-built binary for your platform) 2. whisper.cpp (the open-source transcription engine) 3. a trained model file (we recommend base.en for english, ~140mb) after installation, configure the paths to your whisper.cpp binary and model file in the settings dialog, set your preferred hotkeys, and you're ready to go. for deployment to air-gapped systems, see the companion post on using airgap deploy to package cleanroom whisper with all its dependencies for offline installation. want to learn more? - cleanroom whisper documentation - full project overview - cleanroom whisper use cases - detailed workflow scenarios - privacy-first tools for air-gapped environments - how all three projects work together

Capturing Meeting Notes with Your Voice—No Cloud Required

--- introduction we've built three tools for air-gapped environments: cleanroom whisper for voice transcription, airgap deploy for packaging applications, and airgap transfer for moving large files across the air gap. the problem: computing in isolation imagine you're a researcher working with sensitive patient data, a government employee handling classified information, or a financial analyst working in a secure trading environment. your computer isn't connected to the internet—not because of a network problem, but by design. this isolation, called an "air gap," is one of the strongest security measures available. but working offline presents unique challenges. how do you transcribe interview recordings when cloud-based services aren't an option? how do you deploy new software when you can't simply run or download from the internet? how do you transfer a 20gb dataset when it won't fit on a single usb drive? for years, the answer has been either expensive enterprise solutions, manual workarounds prone to human error, or platform-specific tools that only work on macos. if you needed cross-platform, affordable, and privacy-respecting tools for offline computing, you were largely out of luck. that's why we built these tools. --- three tools for offline computing we've developed three foundation projects designed specifically for computing in isolated, offline environments: cleanroom whisper converts your voice to text completely offline, using no cloud services. press a hotkey, speak your thoughts, and get instant transcription—perfect for quick notes, meeting documentation, or accessibility needs. airgap deploy packages applications and all their dependencies into a single bundle that can be installed on air-gapped systems. no more hunting down missing libraries or trying to compile software without internet access. airgap transfer safely moves large files and datasets across the air gap, even when they're too big for a single usb drive. it automatically chunks data, verifies integrity, and reassembles everything on the other side. all three are designed from the ground up with a single philosophy: privacy through data locality. your data never leaves your machine. there's no network code, no telemetry, no "phoning home." everything stays exactly where you put it. and because all three tools are written in rust with minimal dependencies, they work consistently across macos, windows, and linux—no virtualization, no cloud accounts, no subscriptions required. these three projects form the core foundation that is being actively developing in the near term. they're designed not just as standalone tools, but as building blocks that demonstrate patterns and principles for privacy-first, offline computing. --- cleanroom whisper: your private voice assistant have you ever been in a meeting where you wanted to capture a quick thought but didn't want to break your focus by typing? or perhaps you've conducted interviews that needed transcription but couldn't use cloud services for privacy reasons? cleanroom whisper addresses this. it's a system tray application that listens for a global hotkey (like ). press the hotkey once to start recording, speak your memo, then press it again to stop. within seconds, you have accurate text transcription—completely offline. real-world example: a healthcare researcher conducting patient interviews can transcribe recordings locally, keeping sensitive health information on their secure machine. a productivity enthusiast can capture task ideas by voice while keeping hands on the keyboard. someone with mobility limitations can use it as an accessibility tool for hands-free text input. unlike cloud-based tools like otter.ai or fireflies that require subscriptions and send your audio to external servers, cleanroom whisper processes everything locally using whisper.cpp. unlike macos-only tools like macwhisper or superwhisper, it works consistently across all major platforms. the application runs silently in your system tray with no main window cluttering your screen. your transcription history is stored locally in sqlite, and you can access recent transcriptions with a click or copy the latest one instantly with another hotkey (). we couldn't find existing cross-platform, open-source voice transcription tools designed for quick capture workflows in air-gapped environments, so we built one. learn more: cleanroom whisper documentation --- airgap deploy: package once, deploy anywhere now imagine you've built a useful application—perhaps a data analysis tool or a machine learning model—and you need to deploy it to air-gapped systems. the traditional approach involves: 1. manually downloading every dependency 2. copying them to usb drives 3. figuring out build instructions on the offline machine 4. discovering you forgot a critical library 5. starting over airgap deploy automates this entire workflow. you create a simple toml manifest file that describes your application, its dependencies, and how to build it. run one command (), and it downloads everything needed, packages it into a single archive, and generates platform-specific installation scripts. real-world example: a developer building an offline voice transcription app (like cleanroom whisper itself!) can create a manifest that includes the rust application, whisper.cpp binary, pre-trained model files, and all required build tools. transfer the package via usb, run the install script on the air-gapped machine, and everything builds and installs automatically—no internet required. this is fundamentally different from existing tools. kubernetes-based solutions like zarf and uds are excellent for containerized server workloads but require heavy infrastructure. docker provides containers but needs a daemon running on the target system. language-specific tools like or handle only one component type. enterprise tools like jfrog artifactory require expensive licenses and complex setup. airgap deploy is lightweight (single rust binary), declarative (human-readable toml manifests), and comprehensive (handles applications, binaries, models, and system packages in one workflow). it's designed for release engineers and developers who need to package desktop applications for air-gapped deployment—not enterprise it managing datacenter infrastructure. we couldn't find existing tools for packaging rust applications with ml models for air-gapped desktop deployment, so we built one. learn more: airgap deploy documentation --- airgap transfer: moving data across the air gap here's a common scenario: you've used airgap deploy to create a 25gb package containing your application, models, and dependencies. great! except your usb drives are only 16gb each. how do you get this package across the air gap? traditionally, people use with to manually chunk files, carefully calculate sizes, track which chunk goes on which drive, and manually verify checksums. it's tedious, error-prone, and if you forget to verify one chunk, you might not discover corruption until it's too late. airgap transfer automates this "sneaker net" workflow. run and it automatically splits your data across multiple usb drives, generates a manifest tracking all chunks, and creates checksums for integrity verification. real-world example: a defense contractor needs to transfer 50gb of classified training data to an isolated analysis system. airgap transfer chunks it across four 16gb usb drives, tracks everything in a json manifest, and verifies each chunk with sha-256 checksums. on the air-gapped machine, reconstructs the original data and verifies integrity automatically. this is different from rsync (which is excellent for local synchronization but doesn't handle multi-usb orchestration), enterprise backup solutions like commvault or veeam (which require expensive licenses and complex infrastructure), or hardware solutions like data diodes (which cost thousands and only work in one direction). airgap transfer includes checksum verification and resume capability. it's free, open source, and works with any usb storage on any platform. learn more: airgap transfer documentation --- how they work together each tool solves a specific problem, and they also integrate well: complete offline workflow: a developer uses airgap deploy to package cleanroom whisper with all dependencies and model files (20gb total). the package is too large for a single usb drive, so they use airgap transfer to chunk it across multiple drives with verification. on the air-gapped machine, they use airgap transfer to reconstruct the package, then run the installation script generated by airgap deploy. once installed, cleanroom whisper provides offline voice transcription capability. you can: - develop applications with complex dependencies - package them with airgap deploy's declarative manifests - transfer them safely with airgap transfer's chunking and verification - deploy automatically with generated install scripts - use privacy-respecting tools like cleanroom whisper each tool works independently—you can use airgap transfer without airgap deploy, or cleanroom whisper without either—but together they form a complete solution for air-gapped computing. the technical foundation is consistent across all three: rust for reliability and cross-platform support, minimal dependencies to avoid complexity, and zero network code to guarantee privacy. everything is open source with no vendor lock-in. a foundation for the future this integrated architecture isn't just useful today—it demonstrates patterns that can support future air-gapped tools. the principles of privacy through data locality, minimal dependencies, and cross-platform rust development provide a solid foundation. we're focused on these three projects for now, but the architecture is intentionally designed to support an expanding ecosystem of air-gapped computing tools. learn more: meta-architecture | design principles --- who benefits? these tools are designed for anyone who needs to work in isolated environments or values complete data privacy: government and defense: deploy classified applications, transfer sensitive datasets, transcribe briefings—all without network exposure or security compromises. healthcare: process patient recordings, analyze sensitive health data, deploy hipaa-compliant tools—without sending protected health information to cloud services. finance: run analysis tools in isolated trading systems, transfer market data securely, maintain audit trails with cryptographic verification. research: transcribe sensitive interviews, deploy analysis tools to secure labs, transfer large datasets while maintaining data integrity. privacy-conscious individuals: anyone who wants voice transcription, software deployment, or file transfer without cloud dependencies or telemetry. the common thread: keeping data local instead of sending it to external servers. --- getting started ready to try it out? each tool is available as source code and will be available as pre-built binaries once development is complete. cleanroom whisper: build from source with cargo, configure whisper.cpp path, and start transcribing with global hotkeys. useful for taking notes by voice or for accessibility needs. learn more airgap deploy: create a toml manifest, run , and generate deployment packages for air-gapped systems. learn more airgap transfer: split large files with , physically transfer usb drives, and reconstruct with . learn more all three projects are open source and welcome contributions. these foundation tools represent the near-term development focus, but we have ideas for additional projects and we're eager to collaborate with others who share the vision of privacy-first computing. have ideas for air-gapped tools? want to build on this foundation? whether you're interested in contributing to these three projects, proposing new tools that fit the ecosystem, or building your own projects on these principles—the community is here to help. the patterns established by cleanroom whisper, airgap deploy, and airgap transfer can serve as a foundation for a broader ecosystem of offline-capable tools.

Privacy-First Tools for Air-Gapped Environments

--- introduction air-gapping isn't perfect. no security measure is. but it solves a specific problem better than any alternative: it collapses a distributed, continuous attack surface into discrete, auditable events. the threat landscape the network is hostile by default. not because any single tool or service is malicious, but because connectivity itself creates exposure — and that exposure is being exploited across multiple vectors simultaneously. network surveillance by design. u.s. telecommunications infrastructure is legally required to include surveillance capabilities under federal law. those capabilities have been compromised by foreign adversaries, giving hostile actors access to the very systems built for court-ordered wiretaps. the infrastructure meant to enable lawful intercept has become a systemic vulnerability. harvest now, decrypt later. encrypted network traffic collected today may be decryptable by quantum computers tomorrow. adversaries are already stockpiling encrypted data, banking on future capabilities to read it. for data with long-term sensitivity — medical records, intellectual property, classified information — the collection is happening now, even if the decryption comes later. software supply chain compromise. package managers, build systems, and update channels are increasingly targeted. a single compromised dependency — a backdoored library, a hijacked maintainer account, a poisoned build pipeline — can propagate to thousands of downstream systems through the same automated workflows developers rely on every day. these threats share a common thread: they exploit the continuous, implicit trust that connected systems place in their network infrastructure. what air-gapping actually provides air-gapping doesn't make attacks impossible. it makes them visible. when your development environment has no network access, every piece of software entering that environment must be explicitly transferred. this creates a natural chokepoint—a single boundary where verification can happen. what this mitigates: - dependency sprawl — no or pulling hundreds of packages automatically. every dependency crosses the air gap deliberately, giving you the opportunity to audit, hash-check, or delay until vulnerabilities surface publicly. - malicious updates — connected systems receive updates the moment they're published. air-gapped systems don't. this lag—often seen as a disadvantage—becomes an asset when the community catches backdoors before you've imported them. - exfiltration — many backdoors are only valuable if they can phone home. stolen credentials, harvested keys, scraped source code—none of it leaves an air-gapped machine. this significantly reduces the payoff for many attack patterns. - build-time attacks — compromised ci/cd pipelines, malicious compiler toolchains, and infected build environments can't reach isolated systems. what it doesn't solve: - initial trust — whatever you first bring into the air gap must still be verified. if you import a compromised toolchain, you've just sealed the threat inside with you. - hardware — air gaps don't protect against compromised chips, firmware, or storage devices. if you carry a malicious usb drive across the gap, physical isolation doesn't help. - the transfer boundary — the sneakernet itself becomes your critical trust point. this is where verification tooling matters most. - insider threats — physical access is physical access. air-gapping assumes the human operating the system is trustworthy. - side channels — acoustic, electromagnetic, and power analysis attacks can theoretically leak data from isolated systems. these are expensive and targeted, but they exist. so why bother? because threat modeling is about reducing attack surface, not eliminating it entirely. connected systems require you to trust: - every package registry you pull from - every maintainer of every transitive dependency - every update server your tools contact - every network your machine touches - every intermediate system between you and all of the above air-gapped systems require you to trust: - the software you explicitly choose to import - the verification process you apply at the boundary - the person carrying data across the gap that's a dramatically smaller trust surface. more importantly, it's a visible trust surface—one you can reason about, document, and audit. the question isn't "is air-gapping perfect?" the question is: "can i enumerate my trust assumptions?" for connected systems, the honest answer is usually no. considerations before you commit air-gapping introduces friction. that friction is the point—it's what forces deliberate choices—but it also has costs. workflow disruption — tasks that take seconds on a connected machine (installing a package, fetching documentation, pulling an update) become multi-step processes. this overhead is real and shouldn't be underestimated. tooling gaps — many modern developer tools assume network access. language servers want to download components. ides expect to sync settings. even help commands sometimes phone home. working air-gapped means identifying these dependencies and finding alternatives. verification burden — the air gap only helps if you actually verify what crosses it. this means checksums, signatures, reproducible builds, or at minimum, deliberate delay. without verification, you're just adding inconvenience without security benefit. update lag — the same lag that protects you from supply chain attacks also delays security patches. you'll need a process for monitoring vulnerabilities and deciding when the risk of not updating outweighs the risk of importing new code. physical security — air-gapping shifts your threat model toward physical vectors. if someone can access your isolated machine or your transfer media, network isolation doesn't help. when air-gapping makes sense air-gapping isn't for everyone. it's best suited for environments where: - you're handling sensitive data that shouldn't leave a controlled environment - you operate in regulated industries with strict isolation requirements - you're building high-assurance software where supply chain integrity matters - you want to reclaim control over what runs on your machine - you're willing to trade convenience for visibility it's less appropriate when: - you need real-time collaboration with distributed teams - your work depends on frequently-changing cloud services - the overhead outweighs your threat model - you can't commit to the verification discipline that makes it worthwhile conclusion air-gapping isn't about paranoia. it's about clarity. connected systems obscure the trust relationships we depend on. isolation makes them explicit. and explicit trust—trust you can name, examine, and choose—is the foundation of security you can actually reason about. good tooling can make this tradeoff more practical by reducing the friction of air-gapped development to the point where the security benefits are worth the cost.

Blog