A note on funding: CypherpunkGuide carries no surveillance advertising—no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially-aligned affiliate later. We answer to our readers, not to advertisers.
A private payment, an encrypted conversation, and an encrypted cloud folder look like three solved problems. Monero, SimpleX, and Cryptomator can each protect an important boundary. The comforting mistake is to assume that using all three turns those boundaries into one anonymous system.
I audited 18 pieces of data an observer may see across the three tools—six per layer—against current official documentation. The source-bound CSV records four states; a deterministic validator rejects missing scope, source, or as-of data. I excluded a composite privacy score because counts across unrelated fields would manufacture a ranking that the evidence cannot support.
The harder question is composition. The audit found six recurring ways to join layers: alias, device, internet path, counterparty, a timing-and-size pattern, and recovery material. A capable observer with access across records can use those shared clues to connect a payment, message, and file event. This guide maps the documented protections first, then builds around the records that still exist.
A Privacy Stack Is Three Boundaries, Not One Shield#
A privacy stack is a set of controls with separate scopes, not a combined anonymity guarantee. Monero protects payment fields, SimpleX protects message delivery, and Cryptomator protects cloud-file contents. None protects every observer.
Start with the record, not the product. A blockchain observer, an internet provider, a relay operator, a cloud provider, a counterparty, and malware on your own device see different things. The same field can therefore be protected from one observer and exposed to another.
| Layer | What the tool is designed to protect | What remains outside that boundary |
|---|---|---|
| Payment — Monero | sender-input ambiguity, recipient address privacy, transaction amount | wallet IP path, merchant records, voluntarily disclosed identity, endpoint keys and plaintext |
| Messaging — SimpleX | message content in transit, absence of one global user profile ID, destination-relay separation | pairwise queue identifiers, traffic timing, some relay/network metadata, contact knowledge, endpoint history |
| Storage — Cryptomator | file contents and names before cloud sync; obscured directory structure | timestamps, object counts, stored sizes, recognizable vault format, sync-account identity, unlocked plaintext |
“Protected” in this article always means protected from the named observer within the documented scope. It does not mean invisible to a recipient, immune to endpoint compromise, or impossible to correlate. Partial means the cited control reduces what that observer can see without eliminating the field or every way to link it. Exposed means the cited documentation establishes that the observer can see the field or that the tool does not protect it. Unknown means the source establishes neither protection nor exposure.
This is the same discipline used in a real threat model: name the observer, the asset, and the event before selecting a control. If the observer changes, the answer can change with it.
Monero Hides the Transaction Graph, Not the Whole Payment#
Monero gives senders probabilistic cover, recipients stealth addresses, and amounts RingCT protection. These are transaction-protocol properties. Remote nodes, networks, counterparties, accounts, and compromised wallets remain separate boundaries.
Current Monero technical specifications describe a ring size of 16: the real input appears with 15 decoys. That is plausible deniability, not a justified “one in sixteen” chance that an observer guesses correctly. Monero’s OSPEAD research models nonuniform and timing-related selection risk; the protocol number must not be converted into a personal anonymity probability.
Recipient and amount protection have different mechanics. Stealth addresses prevent the public chain from exposing the recipient’s reusable address, while RingCT hides the transferred amount. This makes “Monero privacy” a three-part statement—sender, recipient, amount—not one blanket property.
| Observer | What Monero changes | What the observer can still have |
|---|---|---|
| Public blockchain analyst | obscured sender input, recipient link, and amount | the existence and timing of a protocol event; probabilistic inferences |
| Remote-node operator | cannot read a recipient address or amount from the chain as plaintext | a wallet connection and its source IP unless the network path is separately protected |
| ISP or VPN provider | transaction-graph privacy remains | a connection path, timing, and destination pattern |
| Counterparty or exchange | outside observers do not gain the private transaction fields | the identity, order, shipping address, account, amount, or conversation you gave it |
| Compromised endpoint | protocol privacy still exists for public observers | wallet keys, destination, amount, screen contents, clipboard, and password entry |
The official FAQ rejects guaranteed anonymity and warns that endpoint compromise, exposed keys, weak passwords, and identifying details given to another party remain consequential. A unique subaddress per payer or payment can reduce counterparty-side address reuse. It cannot make the same merchant forget your delivery address.
Network privacy is similarly separate. Monero’s documentation warns that a wallet using a remote node has no IP protection by default and describes Tor or I2P as additional routing controls. Dandelion++ changes transaction propagation; it does not hide a full-node connection from an ISP, VPN provider, or first peer. If network origin is in scope, protect it deliberately and verify that the wallet configuration actually uses the intended route.
For a broader payment threat model, see the Bitcoin on-chain privacy guide. The protocol differs, but the operational lesson is the same: chain privacy does not erase purchase records or endpoint evidence.
SimpleX Removes Global User IDs, Not Every Link#
SimpleX uses no global user profile identifier for message delivery; it uses pairwise queue identifiers and end-to-end encryption. Relays, networks, contacts, notification systems, and endpoints can still observe different metadata.
The SimpleX privacy policy says profiles and delivered history live on user devices rather than in relay accounts. Undelivered encrypted messages can remain on preset relays until delivery or for up to 21 days, and preset file relays retain encrypted files for 48 hours. “Servers store nothing” is therefore inaccurate even though the relay does not hold message plaintext.
Messages are padded to 16 KiB, and files use fixed-size chunks. Padding reduces exact size information; it does not hide that traffic occurred. On iOS, instant notifications can also reveal the number of notification-enabled queues and approximate message volume to the notification server.
| Boundary | Default behavior | A harder configuration | Residual exposure |
|---|---|---|---|
| Profile identity | no global user profile ID; pairwise connection data | use incognito profiles where the relationship requires separation | contacts still know the profile they interact with; repeated traits can link contexts |
| Relay path | private routing inserts a configured forwarding relay before the destination relay; with multiple preset operators, the app prefers a different operator | use Tor or another approved overlay when the chosen relay must not see the source IP | forwarding and destination relays are not guaranteed to have independent operators; local observers can still see traffic |
| Transport correlation | one profile shares a TCP connection by default | enable per-contact transport isolation after reviewing its BETA status | timing and volume can remain correlated |
| Contact authenticity | invitation link establishes the connection | compare the in-app security code over an independent channel | the independent channel itself must belong to the intended person |
| Endpoint history | delivered history is stored locally | use an app database passphrase and an appropriate retention policy | unlocked devices, recipients, screenshots, and malware can retain plaintext |
The privacy and security guide warns that an invitation link can be substituted in transit. Compare the in-app security code over a genuinely independent channel before treating a sensitive contact as authenticated. A second message sent through the same unverified account is not independent verification.
The protocol threat model also narrows the phrase “no identifiers.” Peers may be able to test identical non-incognito profile data, while receipts or automated responses can reveal whether and when someone is active. Calls have different exposure from messages: SimpleX’s call guide says relay-assisted calls reveal duration to the TURN relay, while peer-to-peer calls reveal IP addresses to contacts. Audit calls separately if they are part of the workflow.
SimpleX protects a messaging boundary; it does not make every message safe to send. The phone-number privacy guide explains why removing a telephone identifier helps, but contact behavior and endpoint compromise still need their own controls.
Cryptomator Encrypts Files, Not Their Activity Pattern#
Cryptomator encrypts file contents and names before cloud sync and obscures directory structure. Its security target leaves timestamps, object counts, stored sizes, and the recognizable vault format visible.
The Cryptomator security target is unusually explicit about scope. A cloud provider should not receive readable filenames or file contents, but it can observe when objects change, how many exist, and their stored sizes. Recognizable .c9r or .c9s objects and vault configuration files can reveal that Cryptomator is being used. This is encryption, not steganography.
The endpoint boundary is more important than the cloud boundary once the vault is unlocked. Malware, a hostile device administrator, screenshots, application temporary files, clipboard history, and application-created copies outside Cryptomator’s protection can all bypass the intended workflow. Cryptomator does not protect copies another program creates while working with vault files.
Cryptomator is also not your synchronization or backup policy. Its official best-practices guide calls for regular encrypted-vault backups, while the sync-conflict guide treats synchronization as a separate system that can create conflicts. Keep vault credentials and recovery material separate from the cloud account and device they unlock; vault recovery cannot recreate deleted encrypted files. If several applications can read the unlocked mount, treat each application as part of the trusted endpoint.
Our 18-Field Cross-Layer Leakage Audit#
The audit maps three tools against six observable fields each. Every row names an observer, official source, date, and limitation. It finds composition failures; it is not a benchmark, review score, or privacy ranking.
I built the 18-row boundary ledger from the official sources cited in this article. I then ran the validator, which confirmed exactly 18 rows, six rows per tool, unique fields, approved source hosts, ISO dates, and nonblank limitation text. The generated summary keeps the four assessment states but warns against comparing their counts.
The method imposes five constraints:
- One field, one observer. “Network origin” is assessed against a relay or network observer, not against an undefined attacker.
- Default and hardened states stay separate.
Hardenedrecords a documented configuration or a separately named control, not a hands-on grade or proof that Cora tested that network path. A Tor-capable workflow is not described as the default unless the documentation says it is. - Every row carries its failure boundary. A protected message in transit can still be plaintext on both endpoints.
- Missing evidence stays unknown. Cryptomator’s security target does not promise network anonymity for cloud sync, so that field remains
unknownrather than receiving an invented answer. - Counts never become scores. Six fields with different observers and consequences cannot be added into one valid measure of product privacy.
That last row is one of the most useful findings. I deliberately left one Cryptomator field unknown rather than fill it with product reputation. I also fixed every row to a named observer before classifying it. Evidence discipline stops a reader from configuring the wrong layer because a comparison table looked complete.
The Six Joins That Rebuild One Identity#
The following is a Cora inference from the component evidence, not a claim that one vendor documents the complete three-tool workflow. The official NIST glossary defines disassociability as processing data or events without linking them to people or devices beyond operational need. A layered workflow loses that property when the layers share a durable join.
| Cross-layer join | Example | Who may correlate it | Separation control |
|---|---|---|---|
| Alias or account | the same handle appears in a SimpleX profile, exchange record, and cloud account | counterparty, account provider, data broker | distinct purpose-bound identities; no shared recovery email |
| Endpoint | one infected laptop sees wallet, chat, and unlocked vault plaintext | malware, device administrator, forensic examiner | separate devices or strongly isolated systems where justified; ordinary OS accounts organize access but do not stop administrator/root-level malware |
| Network path | wallet, relay, and cloud sync connect through one stable household IP | ISP, VPN, relay, cloud provider with auxiliary data | route each sensitive boundary deliberately; do not assume file or protocol encryption hides IP |
| Counterparty | one person receives the message, payment, and file link | recipient or merchant | reveal only the fields the transaction requires; use purpose-specific subaddresses and links |
| Timing and size | a message, payment, and cloud upload happen within seconds | a capable observer with access to multiple logs | batch, delay, and avoid narrating exact amounts or filenames in real time |
| Recovery material | one email, password manager, or photo backup restores every layer | account takeover attacker, cloud provider, coerced holder | separate recovery channels and offline material; test each path independently |
Timing deserves restraint. A synchronized event is a clue, not proof that two records belong to one person. But repeating the same sequence—message, payment, upload—can give an observer a stronger pattern than any single occurrence. Do not claim that random delay creates anonymity; use scheduling only to remove unnecessary precision after you have fixed stronger joins such as identity and endpoint sharing.
This composition problem echoes the AI deanonymization guide: inference becomes cheap when many weak signals share a key. Here, the signals are machine-observable events rather than writing style.
Build the Stack Without Building One Master Identifier#
Build from the threat model outward: separate purposes, verify software and contacts, protect required network paths, encrypt before sync, and rehearse recovery. The stack is ready when one failed account or device does not expose every layer.
Use this order on noncritical data before moving real funds or sensitive records:
- Write three observer statements. Example: “The public chain must not expose recipient or amount,” “the messaging relay must not hold plaintext,” and “the cloud provider must not read filenames or file contents.” Add network and endpoint observers only where your risk justifies the cost.
- Separate purpose-bound identities. Decide whether the counterparty should be allowed to link the payment, chat, and file. If not, avoid a shared alias, recovery email, profile image, cloud account, and narrative that gives the join away.
- Obtain software from official sources and verify it. Check release signatures or reproducible-build guidance where the project publishes it. Test Monero on stagenet and use nonsecret SimpleX and Cryptomator data first. A privacy stack built from an unverified binary has the wrong trust root.
- Configure the payment boundary. Use a unique subaddress per payer or purpose. If a remote node must not see the wallet’s source IP, route and test that connection separately. Record which counterparty facts still exist.
- Authenticate the messaging boundary. Establish the SimpleX contact, compare the security code over an independent channel, review incognito and transport-isolation settings, and decide whether push notifications or calls fit the threat model.
- Configure the storage boundary. Create the vault locally, use a strong unique password, separate its recovery material, then synchronize ciphertext. Confirm that temporary exports and application backups do not leave plaintext elsewhere.
- Rehearse failure with noncritical material. Restore a test vault, recover or migrate a noncritical chat profile according to current documentation, and use an empty test wallet or a deliberately isolated test environment for wallet recovery. Never enter a seed that protects real funds into a website, cloud service, unverified device, or unfamiliar recovery tool, and never overwrite the existing wallet during a drill. Do not discover during an emergency that all three paths depend on one phone.
- Run a cross-layer join review. Compare alias, device, network path, counterparty, time, size, and recovery channel. Remove joins that provide no operational benefit, and document the ones you accept.
Compartmentation has costs: more recovery material, slower workflows, missed notifications, routing failures, and a greater chance of operator error. The goal is not maximum separation. It is the smallest separation that defeats the observer you actually named. The self-hosting sovereignty guide applies the same principle to infrastructure: moving a service home changes the trust boundary but does not eliminate administration or recovery risk.
Bottom Line: Choose the Boundary You Need#
Use Monero for transaction-graph privacy, SimpleX for identifier-minimized messaging, and Cryptomator for cloud-file encryption when those records need protection. Then audit identity, endpoint, network, timing, and recovery joins.
If your only concern is a cloud provider reading filenames, Cryptomator may be the complete answer. If a merchant already knows your legal identity and shipping address, Monero cannot erase that business record. If a contact is unverified, SimpleX encryption can securely connect you to the wrong person. More tools do not repair a mismatched threat model.
The stack becomes defensible when every claim has an observer and every recovery path has been tested. Keep one honest unknown, if necessary. It is safer than a clean-looking matrix that promises a property no source establishes.
Frequently Asked Questions#
The stack protects specific protocol and storage fields, not every identity, network, endpoint, or recovery record around them. Start with the observer, then choose only the layers that change what that observer can see.
Do Monero, SimpleX, and Cryptomator make me anonymous together?#
No. They protect different records. A counterparty, compromised device, stable IP path, synchronized timing pattern, or shared account-recovery channel can link the workflow. Treat anonymity as a threat-model outcome, not a feature inherited from three product names.
Does Monero hide my IP address from a remote node?#
Not by default. Monero’s technical documentation treats network privacy as a separate layer and describes Tor or I2P wrapping for that boundary. Verify the wallet’s actual route; do not infer IP protection from on-chain sender, recipient, or amount privacy.
Does SimpleX have no identifiers or metadata?#
It has no global user profile identifier for message delivery, but it uses pairwise queue identifiers and retains operational metadata within documented limits. Relays, contacts, push systems, network observers, and endpoints each see different fields.
Can my cloud provider tell that I use Cryptomator?#
Yes. Cryptomator encrypts content and names but does not try to hide its vault format. Recognizable encrypted-object extensions, configuration files, timestamps, counts, and stored sizes can remain visible.
Should I put all recovery material in one password manager?#
Only if your threat model accepts that manager and its recovery path as a master join. Higher-risk workflows should separate the materials whose combined loss or compromise would expose every layer, then test recovery so separation does not become self-lockout.
References#
The table pairs each mutable original source with a Wayback index link. Claims use the live official page; the archive column provides a second route for later verification.
