Safety on cruush: privacy starts with control
Meeting people nearby should not mean giving up control of your information. cruush is built around a simple idea: privacy settings should shape what people can see and how they can reach you.
Here is how that works today.
Written by Julien Lenaz, admin and lead developer of cruush.
Sensitive information is encrypted at rest
cruush encrypts sensitive profile data, relationship records, stored location data, messages, feed content, and media while it is stored on the server. That protection includes the privacy policy behind Ghost Mode and the relationship record created when a cruush becomes mutual. Encryption is paired with integrity checks, versioned keys, and access controls, helping protect stored information from unauthorized access or tampering.
This secure server-side foundation lets cruush run core features such as mutual cruushes, visibility controls, account recovery, moderation, and abuse prevention while protecting stored information.
Your map presence is not a public trail
cruush uses location permission from your device to power nearby discovery. Your stored location is encrypted. For nearby discovery, cruush derives privacy-preserving coarse location index tokens and searches nearby cells, rather than publishing your exact coordinates for everyone to query.
When the app shows another member's location, it creates a protected display value for that specific viewer and session. Your actual location is not simply passed around as an open map coordinate.
You decide how your presence appears. Precise sharing is an opt-in setting for mutual cruushes. You can also choose Ghost Mode when you want nearby discovery without showing your precise pin.
Ghost Mode shifts your public pin
Ghost Mode replaces your public map position with a decoy position inside the privacy radius you choose. That decoy changes over the course of your Ghost Mode session, so it does not become a fixed stand-in for your actual location.
Ghost Mode is protected at rest as well. The privacy policy that stores its state and sharing choices receives the same encryption protection as other sensitive data.
Ghost Mode keeps location privacy focused. It does not silently change messaging permissions or erase profile-view activity. Those rules stay separate, with blocking remaining a hard boundary across the app. You can turn Ghost Mode on or off in your privacy controls.
Ghost Mode reduces what other members can infer from the map. It does not make anyone anonymous to cruush, its service providers, or legal requests where disclosure is required. It also cannot undo information someone may have already seen.
Mutual cruushes require two choices
A cruush is an expression of interest. A mutual cruush happens only when both people choose each other. cruush creates and protects that relationship as a separate encrypted record.
The mutual-cruush relationship itself is encrypted at rest, not only the messages or profile information around it.
Mutual cruushes can unlock settings a member has chosen to reserve for that relationship, including protected profile information and precise location sharing. Mutual cruushes do not share precise location automatically. If a member's setting allows it, mutual cruushes can share precise location with each other, and that access can be revoked. Blocking is a hard boundary across the app.
The mutual-cruush model gives cruush a clear foundation for consent-based sharing. Ghost Mode adds a further safeguard by keeping precise location behind a decoy, while messaging and blocking rules remain explicit.
Safety is a set of layers
Encryption matters, but it is only one part of safety. cruush also uses secure session handling, password hashing, rate limits, access controls, reporting, blocking, moderation, and protections against unsafe links and spam.
No tool can guarantee a perfect outcome. The goal is to give members meaningful control, reduce unnecessary exposure, and make consent part of how connection works on cruush.
Building the next privacy layer
We are approaching end-to-end encryption as a focused post-launch engineering track. It would change more than the way messages are stored. It would touch account recovery, multiple devices, key changes, abuse reporting, moderation, search, mutual cruushes, and visibility controls.
Our next phase is to define the threat model and identify which cruush surfaces can support E2EE while keeping those protections strong. We then plan to prototype the key and recovery flows, test migration from the beta architecture, and review the design independently before rollout.
We will publish the user-facing protections and limits as the work advances. Until rollout, cruush continues to protect stored data with server-side encryption at rest.