Law Enforcement Guidelines
This page is for law enforcement and government authorities requesting user data, and for users who want to know how we handle such requests.
Our position
We comply with valid legal requests from competent authorities. We also treat our users' privacy as something worth defending within the law.
Both of those are true at once, and this page explains how we reconcile them.
Part One — For law enforcement
Where to send requests
legal@letshoraro.com — subject line: LAW ENFORCEMENT REQUESTWe do not accept requests by phone, through support channels, or via social media.
What a request must include
- The requesting authority, with official letterhead and a case reference
- Legal basis — the statute, court order or warrant relied upon
- The specific user, identified by registered mobile number in full international format
- Specific data sought. Requests for "all data" will be narrowed or declined.
- Relevant date range
- Named contact — official email address and phone number
- Whether a non-disclosure obligation applies, and its legal basis and duration
Incomplete requests will be returned with an explanation of what's missing.
Emergency requests
Where there is an imminent risk of death or serious physical harm, email legal@letshoraro.com with EMERGENCY DISCLOSURE REQUEST in the subject line.
Include the nature of the emergency, the risk, why the data is needed urgently, and the minimum data required.
We treat genuine emergency requests as our highest priority and aim to respond within two (2) business days. We may disclose the minimum necessary to address the risk, and we will require follow-up formal process afterwards.
ℹ️ If life is at immediate risk, contact the local emergency services first. We are not an emergency service and cannot dispatch help.
⚠️ Emergency process is for emergencies. Using it to bypass ordinary legal process will result in the request being handled as a standard request.
What we can provide
| Data | Available? | Notes |
|---|---|---|
| Account registration details | ✅ | Number, date of birth as declared, registration date, linked email |
| Account status and history | ✅ | |
| IP addresses and connection logs | ✅ | Retained 12 months |
| Device information | ✅ | Model, OS, app version |
| Message metadata | ✅ | Who, when, size — subject to retention periods |
| Message content — private chats | ❌ | End-to-end encrypted. We do not hold the keys. |
| Message content — groups | ❌ | End-to-end encrypted. |
| Tribute content | ❌ | Encrypted. |
| Channel content | ✅ | Public broadcasts, not encrypted |
| Profile information | ✅ | Name, photo, About text |
| Group and Channel membership | ✅ | |
| Order and delivery records | ✅ | Retained 7 years |
| Payment records | ✅ | Retained 7 years. Full card numbers are held by our processors, not us. |
| Delivery addresses | ✅ | |
| Identity documents | ⚠️ | Only where we hold them — age verification or AML checks |
| Abuse reports and moderation records | ✅ | Retained 2 years |
| Sender identity behind an anonymous Tribute | ✅ | Anonymity is display-level only |
On encryption — please read before requesting
Direct chats, group chats and Tribute content are protected by end-to-end encryption. Encryption keys are generated on users' devices and stored in the iOS Keychain or Android Keystore. They are never transmitted to or stored on our servers.This means we cannot produce the content of those communications. Not "we would prefer not to" — we do not possess a means of decrypting them. A court order cannot compel us to produce something we do not have.
We will state this plainly in response to any request, rather than implying a capability we lack.
We can produce: metadata about those communications, Channel content, and everything else in the table above.
How we handle requests
- Receipt and logging
- Legal review — is the authority competent, is the legal basis valid, is the scope proportionate?
- Narrowing where a request is overbroad
- User notification — see below
- Production of the minimum data covered by the request
- Record retention — 5 years
Typical turnaround: we aim to acknowledge a standard request within five (5) business days and to respond substantively within twenty (20) business days. Complex or high-volume requests take longer, and we will say so. Emergency requests are prioritised.
User notification
We notify affected users about requests for their data, unless:
- We are legally prohibited from doing so
- Notification would create a risk to someone's safety
- The request relates to an emergency involving risk to life
- There is a court-ordered non-disclosure obligation
Where a non-disclosure obligation is time-limited, we notify the user when it expires.
We consider this default important. Users who don't know their data was disclosed cannot challenge it.
What we will decline
We will decline or challenge requests that:
- ❌ Come from an authority without jurisdiction over us
- ❌ Lack a valid legal basis
- ❌ Are overbroad — "all data on all users in [location]"
- ❌ Are not specific to identified accounts
- ❌ Seek bulk or indiscriminate access
- ❌ Would require us to build a capability we don't have, including weakening encryption
- ❌ Arrive through informal channels without proper process
We will not build backdoors, weaken encryption, or introduce interception capability. Beyond our position on it, doing so would compromise security for every user.
Preservation requests
We will preserve data pending legal process for 90 days, extendable on request.
A preservation request must identify the account and the data. Preservation is not disclosure — the data is held, not produced, until a valid request for production arrives.
Costs
We do not charge for responding to valid requests, except where a request is exceptionally voluminous, in which case we may seek reasonable cost recovery.
Part Two — For users
What this means for you
If an authority requests your data:
- We check whether the request is valid and narrow it if overbroad
- We disclose only what's covered — not everything we hold
- We tell you, unless legally prohibited
- We cannot disclose your encrypted message content, because we can't read it
What we can't protect
Metadata is not encrypted. We can be compelled to disclose who you communicated with and when, even though we can't disclose what was said. This is true of every messaging service.
Order and payment records are ordinary business records and are disclosable.
Anonymous Tributes are not anonymous to us. If you send one, we know it's you, and we can be required to say so.
If you're concerned
- Understand what's encrypted and what isn't → Can you read my messages?
- Understand what we keep and for how long → Data Retention Schedule
- Download your data → Settings → Account → Request My Data
- Delete your account → Deleting your account