Yes, the journalists did the redactions. The metadata timestamps in one of the documents show that the versions were created three weeks before the publication.
And to be honest, the journalists generally have done a great work on pretty much in all the other published PDFs. We've went through hundreds and hundreds of the published documents, and these two documents were pretty much the only ones which had metadata leak by a mistake revealing something significant (there are other documents as well with metadata leaks/failed redactions, but nothing huge). Our next part will be a technical deep-dive on PDF forensic/metadata analysis we've done.
Thank you. The most recent completely new information from the Snowden files is found in Jacob Appelbaum's 2022 thesis[1], in which he revealed information that had not been previously public (not found on any previously published documents and so on). And AFAIK, the most recent new information from the published documents (along with this post) might actually be in our other posts[2], but there might be some others we aren't aware of.
No, these encrypted VMs are not protected from buggy or malicious on-die components. SEV assumes that the SoC hardware is trusted.[1] And we don't even have to go that deep: both AMD SEV and Intel's equivalent, Intel SGX, have historically been vulnerable to side-channel and speculative-execution attacks, among others, that can undermine their isolation guarantees.[2]
[1]: "As with the previous SEV and SEV-ES features, under SEV-SNP the AMD System-on-Chip (SOC) hardware, the AMD Secure Processor (AMD-SP), and the VM itself are all treated as fully trusted." https://www.amd.com/content/dam/amd/en/documents/epyc-busine...
backdoors in the supply chain are always hard to avoid but if it can't even protect against third-party attackers including any of the hardware attached what's the point
Rip-packs and drill guards are designed for running system protection. Those don't protect against compromised components, though, so select your hardware with care?
It's hard to take corporate denials at face value. History shows that when it comes to surveillance and government cooperation, big tech companies often say one thing in public while doing another behind closed doors.
Before the Snowden revelations, firms like Microsoft, Google, and Apple explicitly denied participating in any form of mass-surveillance. They insisted they only complied with lawful, targeted requests and never provided "direct access" to their systems. Yet the Snowden documents revealed that the NSA's PRISM program did, in fact, collect data directly from these same companies. Other programs like XKEYSCORE showed how that data was searched and analyzed at scale without meaningful oversight.
Even after the Snowden disclosures, the denials (read: lies) continued. Microsoft, for example, repeatedly claimed it "does not provide any government with direct or unfettered access to customer data" and only discloses data when "legally compelled."[1] But we now know that Microsoft works with the NSA to enable pre‑encryption access to Outlook emails, Skype calls, and SkyDrive files, and that the NSA has direct access to Microsoft's systems through PRISM, directly contradicting the company's public statements.[2]
It's scary how easily people believe what these big companies say. Even the EFF praised Microsoft's 2013 transparency report just months before the Snowden revelations, showing how effective these PR strategies are.[3]
When Cloudflare says it doesn't engage in mass-surveillance, we should treat that claim with extreme skepticism. History demonstrates how easily a platform with this level of access can be misused or quietly co-opted by intelligence agencies.
[1]:
10/20/2025
> "Microsoft discloses customer data only when legally compelled to do so. Microsoft does not provide any government with direct or unfettered access to customer data. Microsoft does not provide any government with direct or unfettered access to customer data. Microsoft does not provide any government with our encryption keys or the ability to break our encryption."
https://www.microsoft.com/en-us/corporate-responsibility/rep...
> At Microsoft, as The Guardian has reported, the N.S.A. worked with company officials to get pre-encryption access to Microsoft’s most popular services, including Outlook e-mail, Skype Internet phone calls and chats, and SkyDrive, the company’s cloud storage service.
https://archive.is/DyVgN
> the Guardian revealed that the NSA claimed to have "direct access" through the Prism program to the systems of many major internet companies, including Microsoft, Skype, Apple, Google, Facebook and Yahoo.
https://www.theguardian.com/world/2013/jul/11/microsoft-nsa-...
> these systems allow analysts to listen to whatever emails they want, whatever telephone calls, browsing histories, Microsoft Word documents.
> And it's all done with no need to go to a court, with no need to even get supervisor approval on the part of the analyst
> all an analyst has to do is enter an email address or an IP address, and it does two things. It searches that database and lets them listen to the calls or read the emails of everything that the NSA has stored, or look at the browsing histories or Google search terms that you've entered, and it also alerts them to any further activity that people connected to that email address or that IP address do in the future
Sure, threat models matter, but that's exactly the point. TEEs are marketed as if they solve the "malicious infrastructure" problem. Cloud providers tell you they can't see your data, and vendors pitch TEEs as some kind of hardware-rooted guarantee. If your threat model is "malicious sysadmin" or "host operator" then the fact that the root of trust is opaque, unauditable, and repeatedly compromised does matter.
Saying "what's your alternative" also misses the criticism. The issue isn't whether TEEs can reduce some threats compared to no isolation at all. Obviously they can in some scenarios. The issue is that their trust model is misrepresented: you're still trusting vendors and firmware you can't inspect, and history shows that trust is often misplaced. That's not "no alternative", that's "don't build your security story on black boxes with a track record of holes."
If the only way TEEs "work" is if you lower your expectations to "slightly better than nothing," then the marketing and security claims around them are deeply misleading. At that point, calling them "trusted" environments is just branding, not security.
> Additionally, you still get attestation which gives you cryptographic proof of what code is running.
Remote attestation ultimately relies on the same implicit trust it claims to replace. For example this paper[1] from 2019 showed how AMD's PSP secure boot can be compromised, giving an attacker an possibility to load a patched firmware that grants arbitrary read/write access to the PSP memory, which then allows the attacker to extract the Chip Endorsement Key (CEK), which is AMD's attestation root key. Once you have the CEK, you can forge attestation reports (for example impersonate a legitimate SEV platform) or bypass attestation entirely. And the CEK had (changed in 2023) an infinite lifetime and there was no rollback protection, so even if AMD issued a firmware update, attackers could revert to the old vulnerable firmware and re-extract the CEK.
And to be honest, the journalists generally have done a great work on pretty much in all the other published PDFs. We've went through hundreds and hundreds of the published documents, and these two documents were pretty much the only ones which had metadata leak by a mistake revealing something significant (there are other documents as well with metadata leaks/failed redactions, but nothing huge). Our next part will be a technical deep-dive on PDF forensic/metadata analysis we've done.