1. Overview
This page sets out how OnFire handles requests from law enforcement and government authorities for user information. It describes our practice. It does not grant any right of access, and it does not waive any objection we may raise to a particular request.
OnFire operates through two entities: OnFire Messenger Ltd., registered in Ireland (company number 796932), which serves users in Europe, and OnFire Messenger Inc., a Delaware corporation, which serves users in the United States. Which entity holds the records for a given account affects what process is effective, so please tell us which user population your request concerns and we will confirm the correct responding entity before you incur the cost of formal process.
2. Submitting Requests
Contact
Email: [email protected] — the fastest route, and the one we prefer for all correspondence.
United States postal address:
OnFire Messenger Inc.
Legal Department — Law Enforcement Requests
254 Chapman Rd, Ste 209
Newark, DE 19702, United States
To let us act without a round trip, please include: the legal authority relied on; the specific account identifiers — email address, phone number, username, or user ID, as we cannot reliably search on a person's real name alone; the precise categories of data sought; the relevant date range; and a return address on official letterhead or from an official domain.
Requests that identify no specific account, or that seek "all data" without limitation, will be returned for narrowing rather than actioned.
3. U.S. Legal Process
Where US process is properly directed to the responding entity, we apply the framework of the Stored Communications Act:
Subpoena
Basic subscriber information — account identifiers, creation date, and connection records.
Court order under 18 U.S.C. § 2703(d)
Non-content transactional records, including message metadata.
Search warrant
Required for the content of communications and for stored media.
4. International Requests
We accept UK process such as production orders, and EU instruments including the European Investigation Order, where validly issued and properly directed. Authorities elsewhere should proceed by mutual legal assistance treaty or another recognised cooperation mechanism.
Where records are held by the Irish entity, domestic US process will generally not be effective against them and an MLAT or EIO route will be required. Contact us early if you are unsure which applies.
5. Emergency Disclosure
Where we form a good-faith belief that there is an emergency involving imminent danger of death or serious physical injury, we may disclose information without legal process, to the extent necessary to address that danger. This is a discretion we apply narrowly, not an obligation.
Send emergency requests to [email protected] with EMERGENCY in the subject line, including the nature of the emergency, the person at risk, the specific information needed and why it will address the danger, and a verifiable official contact.
Please do not rely on this address alone where life is at risk. OnFire is a small team and does not operate a staffed 24-hour emergency desk. We cannot guarantee that an email to this address will be read within any particular period. If a delay of hours would matter, pursue exigent process through other channels in parallel rather than waiting on us.
6. What Data Exists
Correction to version 1.0 of this page
Version 1.0, published 22 January 2025, stated that certain OnFire communications are end-to-end encrypted and that we could not provide their content because we do not hold the keys. That statement was inaccurate and should not be relied on. We are correcting it rather than removing it, so that anyone who relied on the earlier version can see that it changed.
OnFire messaging is not end-to-end encrypted. Message content is transmitted over encrypted connections and is stored encrypted on the user's own device, but it is stored on OnFire servers in a form OnFire can read. Subject to valid legal process, message content is available. No current OnFire messaging feature withholds content from us on cryptographic grounds.
Subject to valid process, and to what exists for the particular account and period:
Basic subscriber information
Account identifiers, email address, phone number where provided, profile information, and account creation date. Note that OnFire does not collect or hold a date of birth, so we cannot confirm a user's age.
Connection and transactional records
IP addresses, session timestamps, and activity logs, to the extent retained.
Message metadata
Sender, recipients, timestamps, delivery and read state, and conversation membership.
Message content
The text of messages, available with a warrant or equivalent process.
Media
Images, video, audio and files shared through the service, and their upload metadata.
Service-specific records
Where the account used them: marketplace, rental, ride, delivery, and payment records.
Two points frequently relevant to an investigation:
- Deleted messages are not necessarily gone. Deletion in the app generally marks a message as deleted rather than erasing the stored record, and "delete for me" removes it only for that user. Content a user has deleted may therefore still exist.
- We do not offer real-time interception. We can produce stored records only. There is no wiretap or live-monitoring capability.
Retention periods vary by data category and are described in our Privacy Policy. If retention is material to your request, ask us before serving process and we will tell you what exists for the period you need.
7. Preservation
US authorities may request preservation under 18 U.S.C. § 2703(f) pending legal process. Preservation requests should identify the specific accounts and the categories of data to be preserved, and should be sent to the address above.
An honest limitation you should plan around. OnFire does not currently operate a technical legal-hold mechanism — there is no facility that marks an account as preserved and suspends ordinary or user-initiated deletion. In practice much data persists because deletion is generally soft rather than permanent, but that is a property of how the system is built, not a preservation guarantee, and you should not treat it as one. If preservation is critical, tell us so expressly and move to formal process promptly rather than relying on a preservation letter alone.
8. Child Exploitation Reporting
Where we obtain actual knowledge of apparent child sexual abuse material, we are required to report to the National Center for Missing & Exploited Children under 18 U.S.C. § 2258A and to preserve the associated material. Investigators seeking material connected to a report should contact us at the address above, referencing the NCMEC report number where one exists.
For completeness: OnFire does not currently perform hash-matching or automated classification of uploaded images or video, so material of this kind is identified through user reports rather than proactive detection. Our substantive rules and reporting routes are set out in the Child Safety Policy.
9. Notice to Users
We may notify a user before disclosing their information, so that they have an opportunity to object. We will not do so where we are legally prohibited, where the request carries a valid non-disclosure order, or where notice would create a risk to someone's safety or to a child. If you require non-disclosure, say so expressly and identify the legal basis and its duration.
10. How We Review Requests
We assess each request for valid legal authority, jurisdictional reach over the responding entity, and proportionality of scope. We may narrow, seek clarification of, or object to a request that is overbroad or vague, lacks an apparent legal basis, exceeds the issuing authority's jurisdiction, or would require disclosure contrary to applicable law. We disclose only what the process actually compels.
OnFire is a small organisation and does not maintain a dedicated 24-hour legal response team. We will engage with properly directed requests as promptly as we are able, and we would rather tell you that plainly than imply a turnaround we cannot consistently meet.