A gag order is a court order or statutory provision prohibiting the recipient from disclosing the existence or contents of a legal demand. Most consequentially attached to: National Security Letters (FBI-issued, statutorily gagged by default until 2015 reform), Section 702 directives (FISA Court process, gagged by statute), grand-jury subpoenas (sealed by court rule), and increasingly to ordinary warrants where the government argues disclosure would compromise the investigation. The mechanism that makes “we cannot tell you whether your data was demanded” the structural reality.
What it means in practice
The gag-order architecture creates a structural transparency problem. A provider receives a demand for a user’s data plus a gag preventing them from telling the user; the user has no notification, no opportunity to challenge, no way to know that production occurred. The 2015 USA FREEDOM Act introduced periodic-review provisions for NSL gags (the FBI must justify continued gag every three years), and the 2018 Microsoft v US ruling led to DOJ policy changes reducing routine secrecy in non-NSL contexts. Apple, Google, Microsoft, and others publicly fought specific gag orders in litigation, with mixed results. The 2024-26 environment continues to feature significant gag-order use, particularly in national-security and ongoing-investigation contexts; the providers most committed to user notification (Twilio, Cloudflare, Proton) publish notification policies that promise notification when legally permitted, which is the maximal commitment available given the gag framework.
Where it shows up
Operationally relevant for: anyone whose service provider receives a demand for their data with a gag attached; the practical effect is that you may not know your data was produced for years or ever. The Predaxia operational frame: the warrant-canary mechanism (where a provider publishes a regular statement that “we have not received NSLs” or equivalent, with the absence of the statement signaling without disclosing) was designed to address gag-order opacity but has had mixed effectiveness in practice. The structural defense is architectural: choose providers whose architecture prevents production of meaningful data regardless of gag-order-protected demands. End-to-end encryption that the provider cannot decrypt produces ciphertext on any demand; the gag becomes irrelevant because there is no useful production to gag.
What you can change today
Three implications for service-provider selection. First, prefer providers whose user-notification policy is explicit and meaningful: Cloudflare, Twilio, Proton, several others publish that they will notify users of legal-process demands when legally permitted (which is most non-gagged demands). Second, prefer architecture that defeats gagged demands: end-to-end encryption that the provider cannot decrypt structurally limits what can be produced regardless of the gag. Third, awareness that warrant canaries are partial signals: the absence of a canary update may indicate gag-order receipt or may indicate the provider stopped publishing for unrelated reasons; treat canaries as one data point in evaluating provider transparency, not as a comprehensive signal.