Law-enforcement requests

Jinu is operated by Jinu App LLC, a Florida limited liability company. Legal process should name that entity. Naming "Jinu" alone is not fatal, but it slows a request down while we work out whether the right party was served.

Email is the fastest channel and the one we monitor. Service by post to the address above is equally valid and will be acted on, but it necessarily takes longer to reach the right person, so please do not use post for anything time sensitive. The telephone number is published so an agency can reach us and confirm receipt; we do not accept legal process by telephone, because a call cannot carry the signed process itself.

Send every law-enforcement request, of any kind, to legal@jinu.app from an official government email address, with the type of request in the subject line, for example "Search warrant", "Preservation request" or "Emergency disclosure request". This is the single intake channel. A request sent to safety@jinu.app, privacy@jinu.app or hello@jinu.app will be routed on, but it will be slower, and "slower" is the difference that matters when a record is inside a retention window.

A request we can act on states all of the following. A request that omits any of them will usually come back to you with a question rather than with records.

• The issuing authority. The agency, department or court, and the name, title, badge or bar number, and official contact details of the requesting officer or attorney.
• A case or reference number, so that later correspondence, a preservation request and the eventual legal process can be matched to one another.
• The legal process itself, attached. A subpoena, court order, search warrant or other instrument, signed and issued in a jurisdiction that reaches us. An unsupported request in the body of an email is not legal process.
• The precise account identifier. The Jinu username, the full profile or listing URL, or the email address on the account. A person's real name is not an identifier we can search reliably, and a partial one produces either nothing or the wrong account.
• The specific data sought, and the date range it covers. "All records" describes no record we can produce; it invites us to narrow it for you, which is slower for both of us and rarely produces what the investigation actually needed.
• A return contact for the response, and a deadline if one applies.

Jinu requires valid legal process, and reviews every request for legal sufficiency, scope and jurisdiction before producing anything. We produce only what the process properly reaches, and we object to or narrow a request that reaches further. That review is not an obstacle: a production that exceeded the process would be a problem for the investigation as much as for us.

The categories below describe how we approach a request. They are a guide to what to ask for, not a waiver of any objection and not a promise to produce.

A word on IP addresses, because the row above promises less than it looks like it does. Jinu keeps no historical login log. The IP and device string attached to a session exist only while that session is valid; when the session ends or the account is deleted they go with it, and nothing archives them first. The signup IP is the one IP record we deliberately retain, and it lasts 90 days (section 08). So a request for a member's login history over past months is a request we will usually answer with a very short list or with nothing, and the answer will not improve by rephrasing it.

Much of what an investigation wants is already public and needs no process at all. A live listing, a public profile and a public review can be read and captured by anyone, including you, and doing so does not put us on notice or alert the member.

We accept preservation requests under 18 U.S.C. 2703(f). Send them to legal@jinu.app with "Preservation request" in the subject line. Please read the rest of this section before relying on one, because what happens next at Jinu is narrower than the word "preservation" implies at a larger company, and an officer who assumes otherwise will lose records.

Jinu can place a legal hold, and a person has to place it. A preservation request is read and actioned manually, by a person: receiving one at legal@jinu.app does not by itself hold anything, and there is no automatic trigger anywhere in the product. Once a hold is recorded against an account it is enforced by the software rather than by anyone remembering it, and it stops four things. The nightly retention job leaves the held records in place instead of deleting signup IP records once they pass 90 days. The message prune leaves the held conversations instead of removing messages in conversations idle for 18 months. Stored photographs are not retired or erased. And the member's own "delete my account" control stops working for the duration, refusing with a notice that a person will be in touch.

Two things to plan around. First, the gap is the interval between your request arriving and a person recording it, so send preservation requests as early as you can and do not treat our receipt of one as the hold itself. Second, a hold protects what still exists at the moment it is placed. It cannot recover a record that has already aged out, and until a hold exists the retention schedule in section 06 is what governs.

A hold names its legal basis and its period. A preservation request under 18 U.S.C. 2703(f) is held for the statutory 90 days with a single renewal, and the system enforces that at write time rather than trusting a diary. A hold made under a court order, or in anticipation of litigation, runs for the period its instrument states. A litigation hold may have no end date at all, in which case it runs until it is released.

A preservation request must still identify the account precisely, by Jinu username, profile or listing URL, or the email address on the account. A request that names the wrong account, or names one too vaguely for us to resolve, does not simply fail: it fails quietly, while the records you wanted continue to age out on the schedule in section 08.

So the honest guidance is this: send a preservation request, but send it with expedited legal process rather than in place of it. Treat the request as notice to us and as a manual best effort, not as a freeze you can build a timeline around. Preservation discloses nothing by itself, it cannot revive a record that was already deleted when the request arrived, and it cannot stop a member from deleting their account tomorrow. Process we can act on is the only thing that reliably moves a record out of the live database and into your hands. If you can do only one thing quickly, serve the process.

Where we believe in good faith that an emergency involving a risk of death or serious bodily injury to any person requires disclosure without delay, we may disclose the information reasonably necessary to address that emergency, without legal process. Send emergency requests to legal@jinu.app with "Emergency disclosure request" in the subject line, and mark them urgent.

An emergency request is a request, not a notice, and we have to be able to form the good-faith belief ourselves. State all of the following, in the email:

• The nature of the emergency, and why the risk is of death or serious bodily injury rather than of some other serious harm.
• Why the risk is imminent, and why the delay of ordinary legal process would be too long.
• The specific person believed to be at risk, if known.
• The precise account identifier, and the specific information sought, limited to what addressing the emergency requires.
• The requesting officer's name, agency, badge or identification number, and a telephone number at which the request can be verified.

We may telephone the agency to verify an emergency request before acting on it. Where a request does not meet this bar we will say so and tell you what process we would need, rather than leaving it unanswered.

Our commitment to members is the one stated in the Reporting and moderation policy. Both pages render it from a single constant in our codebase rather than from two hand copies, so the two documents cannot drift: Where legally permitted, Jinu may make reasonable efforts to notify the affected member before disclosure. A court order, a statutory non-disclosure provision or another legal restriction can prohibit that notice, and where one applies we do not give it.

Notice is our default, and it gives way in two different ways that are worth separating. A legal prohibition removes it, and the prohibitions are listed immediately below. A practical limit narrows it: the commitment is to reasonable efforts, so we write once, before disclosure, to the address on the account, and we do not undertake to reach a member who no longer reads that mailbox, who has deleted the account, or whose current contact details we never held.

The legal prohibitions are:

• A non-disclosure order or other legal prohibition on notifying the member.
• A delayed-notice order under 18 U.S.C. 2705(b), for the period the order specifies.
• An emergency of the kind described in section 05, where notice would defeat the purpose of the disclosure.

That list is exhaustive, and nothing else removes notice. We do not reserve a general discretion to withhold notice on our own judgement that notice would be unhelpful to an investigation, and no other Jinu policy grants us one. If your concern is that notice would let evidence be destroyed or a person be reached, the instrument built for exactly that is a delayed-notice order under 18 U.S.C. 2705(b). Asking for one at the outset is faster and far more durable than asking us to exercise a discretion we have told our members we do not have.

If your request needs to be non-public, say so and attach the order or state the exception you are relying on. A request that is silent on the point is treated as one where notice is permitted, because that is the default the member is promised.

Two things are worth knowing before they are asked for, because in both cases the answer is that the record does not exist rather than that we declined to produce it. Each carries a qualification, and the qualification is the part an investigation usually needs.

• We do not hold full payment card numbers. Payments for Jinu's own paid features are processed by Stripe, and card data never reaches our systems. What we hold is payment metadata: amounts, currency, status, dates, refunds and the Stripe transaction identifiers. For the card itself, and for the billing name and address behind it, Stripe is the correct recipient of process, not us. Separately, Jinu does not process payments between buyers and sellers: money for an item moves between them off the platform, so we hold no card, bank or transfer record for a sale. We do, however, hold what the two of them agreed to. An offer carries an amount and the back-and-forth behind it, and when an offer is accepted that amount is written to a deal record alongside the buyer and seller identifiers. So the agreed price and the negotiation history are records we hold and that section 03 reaches. What a buyer's card was actually charged is not a record we hold, because no such charge exists.
• We do not hold continuous or background location history. Where a member shares device location, the reading is rounded on their device to roughly a one kilometre area before it reaches us, and we use that rounded figure to work out a city and to sort listings by distance. We do not track location in the background, we do not attach coordinates to a profile, and we do not build a location history. Section 02D of the Privacy Policy sets this out in full, and it discloses one trace worth repeating here: when a member filters a search by distance, that rounded coordinate travels in the web address, and web addresses land in our ordinary server logs. So a reading accurate to roughly a kilometre can sit in a log line next to a timestamp, inside the log-retention window. That is not a track and it is not tied to an account profile, but it is not nothing either. A request for a member's movements is still a request for a record we never created.

Some records at Jinu are pruned on a schedule, automatically, and some are not pruned at all. Both halves matter to an investigation, and the second half is the one that is usually assumed wrongly. The figures below are the live ones; they can change as the retention schedule changes, so treat an old copy of this page as out of date rather than as a commitment.

One exception to the 18-month message window deserves stating on its own. Our anti-fraud system stores a short excerpt of the text of any message it scores as risky, and those excerpts sit in the no-expiry category above. Message text can therefore still exist in that form after the message itself has been pruned from the conversation. Do not treat 18 months as a point past which message content is unrecoverable.

When a member deletes their account, we hard-delete or anonymize their personal data across the database and the storage buckets. It is member-initiated and it needs no approval from us: the member confirms with a one-time code we email them automatically, and the purge then runs at once. It is also a multi-step purge that can fail part way through, leaving some steps applied and some not. Where that happens the member is offered a request, inside the product, that a person finish the job, and is given privacy@jinu.app as the other way to ask; until one of those is actioned the account is in a partly deleted state rather than a clean one.

Deletion removes the records from the live database, and therefore from anything we are able to search or produce. It is not the same as the data ceasing to exist everywhere. Deleted rows can persist inside backup artefacts for the length of the backup window described above. A restore is an extraordinary disaster-recovery step: we do not query backups, we cannot search one for an account, and restoring one to answer legal process is not something we do in the ordinary course. Plan on the basis that once the purge has run the records are gone for your purposes, and act before it runs.

This page is operational guidance. It explains how we handle requests and what to send us so that a request can be acted on. **It does not expand or limit Section 28 of the Terms of Service**, which is the binding statement of when Jinu may access, preserve and disclose information about members, and it creates no right or obligation that Section 28 does not already create. Where this page and the Terms could be read differently, the Terms govern.

Nothing here waives any objection, privilege or requirement, and responding to one request does not commit us to responding to the next one on the same terms. Members with a privacy question should write to privacy@jinu.app; safety reports belong at safety@jinu.app; copyright notices follow Copyright and intellectual property.