Correction, October 7, 2026: The earlier version presented marketing claims as verified architecture and recommended the service for sensitive communications without evidence to support that recommendation. We have withdrawn those assurances. It also described Ghost Chat as WebRTC-only; the public site now describes chat over Nostr relays. The original publication date is retained so readers can recognize the corrected article.
What the public site says
On October 7, we reviewed the walls.rip homepage. It advertises disposable email, a paid persistent inbox, encrypted message drops, temporary phone numbers, phone plans and chat. It describes Dead Drop as using client-side AES-256-GCM encryption, and Ghost Chat as PGP-encrypted messaging over Nostr relays. These are the provider’s descriptions, not results of a TDA audit.
The page also claims no IP or user-agent logging and automatic expiry. We have not verified those claims through infrastructure access, code review, retention testing or an independent audit. A public page cannot by itself establish what every server, relay or upstream provider retains.
What we removed from the earlier article
The previous article claimed that messages never touch a server, that closing a tab removes every trace, and that recipients cannot record conversations. It also asserted perfect forward secrecy for message drops without citing a protocol analysis. Those claims were not established by the evidence we had.
We removed the unsupported comparisons with other messengers, claims of untraceable payments, recommendations for whistleblowers, and categorical legal assurances. We also removed unrelated cryptocurrency promotion. Readers should not treat the old article or its cached search excerpt as a security review.
Questions a proper review would need to answer
A useful assessment needs more than feature names. For each service, we would want to establish:
Where plaintext first exists and where encryption happens.
How a sender verifies a recipient’s identity or encryption key.
Which parties handle messages, phone numbers and payments.
What metadata each party receives, retains and can disclose.
Whether expiry removes server copies, backups and recipients’ saved copies.
How a user recovers access, and what happens when a temporary number is reassigned.
Which published audit, code version and configuration support each claim.
These are review questions, not findings that a particular implementation is broken. The lack of verification here should not be substituted with either an endorsement or an accusation.
A practical decision for readers
Do not use our earlier article as the basis for sending recovery codes, confidential documents or identifying source material through the service. We have not completed the assessment needed to recommend it for those uses.
Start by identifying what you need to protect and who might access it, as the EFF security-plan guide suggests. For everyday account and file checks, our practical privacy guide describes narrower tasks with explicit limits. If you have an independent audit or documentation that answers the questions above, send the source for review.