How Closed-Source Software Testifies Against You
TLDR: You don't need to be hacked to be convicted. A warrant, a random backup toggle left on, or a foreign court order routed through a company's home jurisdiction is all its takes; three real-world case studies about prosecutions show exactly which OPSEC choice could have closed each door.
Introduction: The Backup You Forgot You Turned On
First, we shall begin with an individual's tale in Brazil: An accountant in San Paulo, named Rodrigo Morgado, believed his phone to be safe. That wasn't because he had actually done anything proactively to make it safe, but was because he blindly trusted Apple's brand name. Eventually, he happened to get arrested in October 2025 by the Brazilian federal police during a drug trafficking probe. Conveniently, the police didn't even need to break any encryption whatsoever to unravel what turned into one of the country's largest money laundering cases in recent memory! Apple simply ended up yielding to them when the Brazilian courts ended up demanding his iCloud backup. [9to5Mac, 2026].
That single backup ended up mapping an entire criminal organization: illegal betting rings, shell companies, crypto flows. Subsequently, 39 arrest warrants and 45 search-and-seizure orders followed across 8 Brazilian states [AppleInsider, 2026]. According to AppleInsider's article: "According to the Brazilian publication G1, Rodrigo Morgado 'placed great trust in the digital security of iCloud, which ultimately allowed the Federal Police to map the organization.' Authorities seized luxury cars, watches, jewelry, weapons, cash, documents, and electronic devices". Simply put, Morgado placed his trust in a corporation's (Apple's) marketing department, instead of maintaining his own OPSEC.
Herein lies the pattern of eventual betrayal by corporations that the OPSEC Bible keeps trying to warn netizens about. The above event isn't hypothetical; it is a real courtroom, a real sentence, a real person who found out the extremely hard way what relying on "closed-source" eventually cost him.
Why Should YOU Care?
Firstly, go ahead and absorb the thesis expressed in our post on "Surveillance Capitalism"; so that article must have already made you aware, that closed-source platforms, most often, are purpose-built from the ground up to extract your data for profit; ESPECIALLY if the service is free. What remains to be covered is the second half of that equation: the same surveillance capitalism pipeline that feeds advertisers, can be legally redirected to feed prosecutors, and all it takes is a boring piece of paper with a court judge's signature on it, for corporations to fold and capitulate immediately.
The concern lies thus: you aren't a master criminal. Maybe, you're just another regular person, handling something sensitive: say, an activist/protester, a journalist's whistleblower source, maybe a small-time hustler, or just someone going through something extremely private they would wish to keep to themselves. You have been bombarded with advertisements from services like iCloud (Apple), WhatsApp (Meta), and Bitlocker (Microsoft) regarding their amazing encryption, so naturally, you tend to assume you're covered. What you haven't accounted for, however, is that the company advertising to you, and sitting between you and your data, answers to a government; and that government doesn't need to hack you when it can simply ask your provider nicely (or not so nicely, as we shall see in the case study section further down in this article).
What Are Your Options?
Broadly, you have three choices available to you:
- Trust the brand name, blindly (what Morgado did): use the default settings on a closed-source platform; and pray to God that the company's privacy marketing matches its legal reality, and that said company serves your interests over a government.
- Trust open-source, ignoring jurisdiction: use a FOSS, or server-side E2EE tool(s) without taking into account the courts who can compel the company behind said tool(s).
- Control your own custody chain: hold your very own encryption keys, heavily minimize what any third party can be legally compelled to hand over, and pragmatically treat every cloud service as a potential witness for the prosecution.
When push comes to shove, only option 3 actually works. As promised, let's prove it with legal deep dives into 3 more real convictions: one from the United States, one from the European Union, and one from Switzerland.
Case Study I: The iCloud Warrant That Outlived Its Own Excuse (United States, 2020–2023)
The night of 11th April 2020 was a bad day at a poker table. Kevin McCall was losing quite heavily, grew enraged, and stepped outside to take a call, telling other players he "needed to take care of something" [USCA11, Op., p.3]. Mere minutes later, two masked armed men forced their way in, shot two of the players, and left with the cash and everyone's phones. Nobody disputed that investigators had probable cause (with the first warrant) to search McCall's own phone once he was arrested 3 days later, since the police account of that night, drawn from the four victims' sworn statements, ties him directly to the crime [United States v. McCall, 84 F.4th 1317, p.2].
For our OPSEC purposes, what matters is what happened after the phone search failed. McCall's iPhone was locked; and the detective assigned to the case didn't have the unlock code, thus the device warrant "proved largely useless" [United States v. McCall, 84 F.4th 1317, p.2]. What could the detective extract from the iPhone, however? The name of the associated iCloud account, and the timestamp of its last backup; which happened to be 12 hours before the robbery even happened. That backup timestamp led to the second search warrant, which ended up unlocking everything else, legally speaking.
Rosen's second warrant application asked a judge for access to 7 categories of iCloud data, described in the opinion as: "the device's registration information, its iCloud data (including all email content, photos, documents, contacts, and calendars), Find My iPhone data, communications records, iCloud backup history, Facetime communication logs, and iTunes account information" [United States v. McCall, 84 F.4th 1317, p.2].
Here's the problematic part - the second warrant didn't confine law enforcement's search to any time window. Apple was ordered to hand over "the entirety of the account records", because, as the warrant itself acknowledged, Apple holds no practical way to separate crime-relevant material from everything else in the account [United States v. McCall, 84 F.4th 1317, p.7]. It was executed as a two-step process: Apple dumped the full account, and officers sorted through it themselves afterward.
Buried in roughly two and a half months of backed-up data, the forensic examiner found photos and videos of McCall, a convicted felon, holding a 9mm handgun, taken about a month before the robbery and with no connection to it whatsoever. That discovery is what actually put McCall in front of a federal jury, on a felon-in-possession charge that had absolutely nothing to do with the original armed robbery investigation.
As a small consolation, the District Court did agree that the warrant was constitutionally overbroad and defective. It opined that probable cause did exist; but the warrant failed the 4th Amendment's "particularity" requirement, since it was too broad to describe what needed to be actually searched [United States v. McCall, 84 F.4th 1317, p.7]. The Eleventh Circuit didn't disagree on that point either; on appeal, the government itself conceded the warrant "fell short" of the particularity requirement!
…but under the "Leon good-faith exception", a warrant that a judge already signed off would normally be enforceable, even if a court later decides it shouldn't have been; unless it's so apparently defective that no competent officer could have relied on it [United States v. McCall, 84 F.4th 1317, p.8]. The panel (to nobody's surprise!) held this warrant didn't clear that (very low) bar; resulting in that evidence getting admitted despite the incidental unconstitutionality, resulting in McCall being convicted and sentenced to 27 months.
The OPSEC Lesson: The 12-hour gap between McCall's last iCloud backup and the robbery should have been a dead end, legally speaking; the backup couldn't have captured anything from that night of the actual crime being investigated. Instead, it became the door investigators eventually walked through to find unrelated evidence of an entirely different crime because the account itself, not the incident, was what the warrant reached! That's the structural risk of any default cloud backup: it doesn't just expose what might be actually relevant to an active investigation; it exposes whatever else happens to be incidentally sitting there once a court order compels the provider (in this case, Apple iCloud) to hand over the account. Apple's own documentation confirms that unless a user enables "Advanced Data Protection", the key protecting most iCloud backup categories is one Apple itself can access [Apple Platform Security Page, 2026]. Enabling Advanced Data Protection (which still would be following Option 1 from earlier), or replacing iCloud Backup with local, VeraCrypt-encrypted backups (recommended - Option 3), closes this exact door; covered in our post on VeraCrypt.
Case Study II: The Phone Company That Was Actually the Police (European Union, 2020–2024)
EncroChat sold itself as completely unbreakable: modified handsets, no camera, no GPS, no microphone, running custom software that routed every message through a single server in France, with E2EE on top [EncroChat Judgment 2024, ¶19]. French police got a foothold in that server as early as 2018. By spring 2020, a joint French-Dutch team had built and pushed a fake "update" to the entire network. It landed on over 66,000 centrally subscribed devices; more than 32,000 of them, spread across 122 countries, started silently forwarding their contents to police [EncroChat Judgment 2024, ¶20]. Users didn't uninstall EncroChat when they found out, because there was nothing to find out; the interception was invisible, and it stayed running for months!
What happened next is the part worth dwelling on. 9 days after a Eurojust briefing, where French and Dutch investigators previewed the operation to other EU police forces, Germany's federal police opened a nationwide, not against any named suspect, but against "all unknown users" of EncroChat in the country. Their justification, laid out plainly in their own internal note, was pretty alarming: that merely using an EncroChat phone was itself sufficient grounds to suspect someone of serious crime [EncroChat Judgment 2024, ¶21–22]. Nobody had to do anything else wrong. The product they'd chosen for security was the evidence itself!
Across the EU, Europol's own tally puts the total at close to 6,500 arrests and roughly €900 million in seized assets [Hoxhaj, Cambridge EJRR 2025, Section 1].
Defendants challenged the legality of how Germany obtained the French data, and the case reached the EU's top court in 2024. The ruling didn't just let the evidence stand; it made the standard for future cases looser, not tighter. The court held that prosecutors don't need individualized suspicion of each person before requesting their intercepted data; a general suspicion covering the whole user base of a compromised service is enough to justify pulling an individual's messages out of it [EncroChat Judgment 2024, ¶89, Holding 2]. In effect: if the platform you chose gets compromised, being one of its users can itself be treated as the reason your data gets handed over!
The OPSEC Lesson: EncroChat's fatal flaw wasn't its encryption; that reportedly held. It was centralization. Every user's security depended on one company's infrastructure, running one piece of software, sitting behind one server, in one jurisdiction. Compromise the server once, and there's no meaningful difference between the guilty and the merely careful: everyone's traffic flows through the same pipe to the same attacker. Worse, EU courts have now made clear that simply having used a compromised platform can be treated as grounds enough to target you individually afterward. A closed-source, single-vendor "secure phone" results in a shared fate with tens of thousands of strangers you've never met. This is exactly why we steer readers toward decentralized, auditable, open-source tools instead of any vendor's proprietary "unbreakable" phone; we'd once again implore you to see our post on why you can't trust closed-source software.
Case Study III: Even Open-Source Has a Jurisdiction (Switzerland, 2021)
A quick counterpoint, because "just switch to FOSS/E2EE" isn't the full answer either. In 2021, French police wanted to identify a Paris climate-activist collective communicating over ProtonMail. Since Proton doesn't answer to foreign police directly, France routed the request through Europol to Swiss authorities, who compelled Proton to log and hand over the group's IP address. At least one activist was arrested. Proton's CEO later said the company had no legal way to appeal that specific order [Proton, 2021].
That same year, Proton separately fought off an attempt by Swiss regulators to reclassify it as a full telecom provider; a status that would have forced it to store user data on demand for every account, by default [Lexology, 2021]. In October 2021, the Swiss Federal Administrative Court agreed email providers aren't telecoms and don't inherit that blanket retention duty.
Don't conflate the two. The ruling killed a standing, dragnet obligation: logging everyone, always, just in case. It did nothing to stop a targeted order for one account in one live investigation, which is exactly the mechanism that caught the activist. The legal analysis of the ruling says as much directly, citing the French activist request as a live example of disclosure Proton remains compelled to make case-by-case [Lexology, 2021].
The OPSEC Lesson: Proton's encryption held; the messages were never read. What leaked was metadata: an IP address, handed over via an ordinary cross-border legal request, not a backdoor. FOSS/E2EE tools defeat content interception. They don't defeat metadata compulsion under the provider's home jurisdiction, and a win against blanket retention doesn't touch a court's power to order a specific disclosure by name. If your threat model includes a state actor, pair any FOSS/E2EE tool with Tor onion-site access: no ruling protects data the provider never collected!
What All Three Case Studies Have in Common
Now pause for a second, go back, and consider the three options laid out earlier in this post. Each case study you read above is one of these options, playing out in a courtroom:
Option 1 (blind brand trust) is what broke Rodrigo Morgado, Kevin McCall, and every EncroChat defendant. Their hubris was not holding their own encryption keys. All three treated a certain company's promises: be it Apple's marketing, EncroChat's "unbreakable" sales pitch, as a legal guarantee. What it actually happened to be was a promise that lasted exactly until a court, or a hacked server, said otherwise. In this regard, EncroChat is the most extreme cautionary tale: it wasn't even open-source; it was a single closed-source vendor selling "military-grade" security to thousands of people who never got to verify that claim for themselves.
Option 2 (FOSS without jurisdiction-awareness) is what caught the Paris activist. Proton's open-source, E2EE mail did exactly what it promised: nobody, including Proton, could read the message content itself. What gave the activist away in the end was no broken cipher per se; it was simply that he picked a provider without first asking "which government could potentially force this company to capitulate, and what would this company still be able to hand over when a judge forces it to?".
Strip away the country, the crime, and the "celebrity" names, and you'll notice all four cases collapsing into the same general shape:
| Case | Jurisdiction | What was exposed | Legal mechanism | Outcome | OPSEC option that failed | Tutorial that would have prevented it |
|---|---|---|---|---|---|---|
| Morgado (Brazil iCloud) | Brazil | Full financial, contractual, and communication history of a criminal network | Standard warrant compelling Apple to hand over a default iCloud backup | 39 arrest warrants, 45 search-and-seizure orders, ~$300M in assets blocked | Option 1: blind brand trust | Advanced Data Protection, or local VeraCrypt-encrypted backups |
| McCall (US iCloud) | United States | Full iCloud account, no time limit | Overbroad warrant, saved by the "Leon good-faith exception" | 27-month federal sentence | Option 1: blind brand trust | Local, VeraCrypt-encrypted backups instead of iCloud |
| EncroChat (Encrypted Phone) | European Union (+ UK) | Over 120 million messages from 60,000+ users | State-sponsored device compromise, later legalized via a European Investigation Order and upheld by the CJEU | ~6,500 arrests, ~€900M seized, 7,134 cumulative years sentenced so far [Hoxhaj, Cambridge EJRR 2025, Section 1] | Option 1: blind brand trust, single vendor | Decentralized, open-source, auditable messaging |
| Proton IP | Switzerland/France | Account-registration IP address (metadata only, content stayed unread) | Targeted cross-border legal order routed through Europol | Activist identified and arrested | Option 2: FOSS, jurisdiction-blind | Tor / onion-service access to strip identifying metadata |
None of these people were undone by a wildly sophisticated hack. Every single one of them was undone by hubris: default settings, trust assumptions, or a jurisdiction they never thought to account for (which are common themes we continually highlight, like in the Bayrob Gang case study). That's the actual thesis of this post we aim to posit, and it's worth reading twice: closed-source software doesn't need to betray you actively, it just needs to keep doing exactly what it was designed to do, and let the courtroom take it from there. Don't think open-source software is automatically safe either: it just moves the same failure one layer down, from "can they read it" to "can they compel whoever's holding it." Only Option 3, holding your own keys and treating literally every provider as a future witness, closes both doors at once. Keep your providers blind.
Conclusion: Don't Be the Next Case Study
Every OPSEC failure above maps directly onto a tutorial we've already written, and onto one specific step toward Option 3:
- Morgado and McCall both handed over their entire account the moment a warrant landed, because Option 1 left Apple holding the keys by default. Disable iCloud Backup or turn on Advanced Data Protection, or better yet, replace it outright with local, VeraCrypt-encrypted backups that only you can open: see our aforementioned post on VeraCrypt hidden volumes.
- EncroChat's entire user base shared one company, one server, and one jurisdiction; thus they ended up sharing one fate. Never ever let a single centralized, closed-source vendor hold your whole communication history: see why you can't trust closed-source software.
- The Proton-using activist proved FOSS/E2EE tools only ever solve half the problem; that is, while the content stays unreadable, metadata doesn't. Assume any provider, FOSS or not, can be legally compelled in its home jurisdiction, and pair your tools with Tor so there's no identifying metadata left standing to compel in the first place.
- Across all four cases, "encrypted" and "not discoverable in court" turned out to be two completely different properties. Revisit our breakdown of privacy vs. anonymity vs. deniability if that distinction isn't fully clicking yet!
Rodrigo Morgado, Kevin McCall, every EncroChat defendant serving part of those 7,134 collective years, and the Paris activist who trusted a Swiss mailbox all had one thing in common before it caught up with them: they thought "it won't happen to me". It's an understandable thought. It's also, provably, the single most expensive assumption in this entire post.
External References
- 9to5Mac, "An iCloud backup helped uncover a $320M crime ring in Brazil", 9to5Mac, Apr. 2026. Available at: https://9to5mac.com/2026/04/16/an-icloud-backup-helped-uncover-a-320m-crime-ring-in-brazil/
- AppleInsider, "$320M money laundering scheme uncovered using iCloud backup", AppleInsider, Apr. 2026. Available at: https://appleinsider.com/articles/26/04/16/320m-money-laundering-scheme-uncovered-using-icloud-backup
- Justia, "USA v. Kevin McCall, No. 21-13092 (11th Cir. 2023)", Justia, 2023. Available at: https://law.justia.com/cases/federal/appellate-courts/ca11/21-13092/21-13092-2023-10-27.html
- United States v. McCall, 84 F.4th 1317 (11th Cir. 2023). Available at: https://www.supremecourt.gov/DocketPDF/23/23A676/295768/20240116111211608_United%20States%20v%20McCall.pdf
- Apple Inc., "Apple Platform Security", Apple Support, 2026. Available at: https://support.apple.com/en-gb/guide/security/sec973254c5f/web
- Court of Justice of the European Union, Case C-670/22, Staatsanwaltschaft Berlin v. M.N. (EncroChat), Judgment, ECLI:EU:C:2024:372, Apr. 30, 2024. Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:62022CJ0670
- A. Hoxhaj, "The CJEU ruled that the EncroChat data can be admissible evidence in the EU", European Journal of Risk Regulation, vol. 16, pp. 1567–1579, 2025. Available at: 10.1017/err.2025.10047.
- Proton, "Important clarifications regarding arrest of climate activist", Proton Blog, 2021. Available at: https://proton.me/blog/climate-activist-arrest
- Lexology, "E-mail service also subject to limited telecom surveillance only", Lexology, 2021. Available at: https://www.lexology.com/library/detail.aspx?g=4c434b5f-2a95-4883-9781-8091319c9328
Suggest changes
PaaniPuriProletariat
2026-07-17
Donate XMR to the author:89jnzah91KBf9NKVgnkyqodVK79x1Sg4u39LgFbkZKQvCNhVqDdRJFoDe9FtD28mLQR2LRvVc8tdnAZnHeNGNn3HCznBM8h