Law Enforcement and Legal Requests

Just Chicken In takes user privacy seriously, particularly because the service is used by people in situations where disclosure of personal information can have real safety consequences — including domestic-violence survivors, stalking victims, human-rights defenders, and people served by community-safety organizations. This page explains how we respond to law-enforcement and other legal requests for user data.

1. Our general posture

• We do not voluntarily disclose user data to law enforcement or other third parties.
• We require valid legal process — a subpoena, court order, search warrant, or equivalent — before disclosing any non-public user data.
• We narrowly interpret the scope of each request and disclose only what we are legally required to produce.
• Where a request concerns a user for whom we have a reachable contact method and where notice is not legally prohibited, we provide advance notice so they have an opportunity to contest.
• We challenge requests that are overbroad, facially deficient, or that we believe are likely to cause harm to the people the service is designed to protect.

2. What legal process is required

We respond to the following forms of process from U.S. authorities:

• Subpoena: We may produce basic subscriber information (Member ID, associated email, coarse account-creation date) in response to a valid subpoena.
• Court order under 18 U.S.C. § 2703(d) or equivalent: May be required to compel non-content transactional records.
• Search warrant: Required to compel disclosure of content, including emergency packet contents (which are encrypted at rest and may not be recoverable by us in all cases), and for any sensitive personal information stored on the organization portal.

For requests from outside the United States, we generally require process issued under an applicable Mutual Legal Assistance Treaty or letter rogatory, in addition to compliance with U.S. law.

3. Emergency disclosure requests

In genuine emergencies involving a risk of death or serious physical injury, we may consider a voluntary disclosure under 18 U.S.C. § 2702(b)(8) or equivalent. Requests must be submitted in writing on official letterhead, identify the nature of the emergency, describe the information sought and its relevance, and include a call-back contact for verification. We evaluate each emergency request on its own facts and reserve the right to decline or limit disclosure.

4. User notification

Our notification posture depends on the type of account the request concerns and on what contact information we actually have. In all cases we will not notify where notice is legally prohibited (for example, by a non-disclosure order), where we reasonably believe notice would create an imminent risk of serious physical injury to the user or another person, where notice would substantially prejudice an ongoing law-enforcement investigation into serious harm, or where the user has asked in advance not to be notified.

Individual app users (no server-side contact info)

For individual users of the mobile app, we typically do not hold an email address, phone number, or other method to contact the user outside the app itself. We cannot promise direct notification we have no way to deliver. Where feasible — for example, where a user has voluntarily provided a contact email in their account settings — we will attempt to notify that email address before producing data. Otherwise, the user's best protection is the combination of High Privacy Mode (which minimizes what we retain), auto-delete-after-alert (which removes data 48 hours after an alert if no check-in follows), and the user's own judgment about the alias and contacts they choose to store.

Organization portal accounts

For organizations that hold an account in the organization portal, we have the organization's contact email on file. If a request concerns an organization's account data, we will notify the organization's contact email in advance unless an exception above applies.

Organization members

When a request concerns Member-profile information stored by an organization about a Member, the organization — not Just Chicken In — is the data controller under our Data Processing Addendum. In most cases we will forward the request to the organization as controller and allow it to respond, including to decide whether and how to notify the Member. This is the same posture we would take for any organization's data held under a processor relationship.

Retrospective notification

Where a non-disclosure order later expires or is lifted and we still have a way to reach the affected user or organization, we may notify retrospectively.

5. What identifiers we typically hold

Because we store only what the service needs to operate, our ability to respond to a request depends heavily on which identifier the requester provides:

• Member ID (format owner_ or org_xxxx:nnn for org members) — this is the primary key for all user data. If a request provides a Member ID, we can locate the corresponding account.
• Phone number — we do not store a phone number for the user themself, but phone numbers appear in our database when other users have listed that number as an emergency contact, and when an organization has stored it in a Member-profile record. A subpoena citing a phone number will match against those secondary uses, not against the user whose phone it is.
• Email address — same as phone: stored only where someone listed it as an emergency contact, where an organization stored it in a Member-profile record, or where the requester is an organization-portal admin (we have the org admin's email).
• Real name — not stored for individual users. Stored only where an organization has chosen to collect it in the Member-profile table; that table is the organization's data, not ours.
• IP address — not stored long-term by the application. Our hosting provider (Cloudflare) maintains standard edge access logs under its own retention policy.

Requests that cannot be narrowed to a Member ID, to a specific phone/email known to appear in our database, or to an organization-portal account are likely to receive a "we have no responsive records" response.

6. What we can and cannot produce

Within the scope of a properly served and reasonably narrowed request, we may be able to produce:

• The fact that a given Member ID exists and its creation date;
• The user's last successful check-in timestamp and current escalation state;
• The alias the user chose (if any);
• The phone numbers or email addresses saved as that user's emergency contacts;
• The existence (but not plaintext contents) of an encrypted emergency packet;
• Recent entries in the alert-delivery log relating to that Member ID (see Privacy Policy retention).

By design, there is information we simply do not have or cannot reconstruct:

• Location data: None. We do not collect it.
• Continuous monitoring data: None. We do not collect it.
• AI profiles or risk scores: None. We do not generate them.
• Emergency packet plaintext: Encrypted at rest with a server-side key. We do not maintain an administrative UI for browsing packets. For high-privacy users past the 48-hour auto-delete window, the entire record may already be permanently deleted.
• Reasons for a missed check-in or any narrative content: None stored.
• Deleted user data: Once a user's high-privacy auto-delete runs, or once a user deletes their account, the data is removed from active systems. Limited operational logs (see the Privacy Policy) may remain for a bounded period.

7. Data preservation

We respond to preservation requests that cite specific account identifiers (Member ID, associated email, or phone number) under 18 U.S.C. § 2703(f) or equivalent. Preservation does not compel disclosure; disclosure still requires appropriate legal process as described above.

8. Reimbursement

We may seek reimbursement for costs of responding to legal process as permitted by law.

9. Requests from survivors and at-risk users

Users who are concerned that they, or a third party, may attempt to obtain data about them through legal process, law-enforcement referral, or a dispute (for example, in a family-court or custody context) may contact hello@justchickenin.org. We will discuss options that are available within the service, including:

• Enabling High Privacy Mode and auto-delete-after-alert, which reduces the window in which data exists to be disclosed at all;
• Auditing the emergency-contact list and optional alias to ensure no at-risk identifying information is present;
• Considering account deletion if that is preferable to continued use.

10. Transparency

We do not currently publish a periodic transparency report. If we receive sufficient volume of legal requests to make one meaningful, we will begin publishing one and announce it here.

11. How to submit a request

Law-enforcement officials and attorneys may submit legal process by email to hello@justchickenin.org with the subject line Legal Request. We may require the request to be re-served by a method that produces a verifiable original (for example, certified mail or a court-supervised service platform).

Requests are reviewed by the company's legal designee. Because Just Chicken In is a small operation, response times may be longer than for larger providers. Urgent emergency requests should clearly identify themselves as such.

12. Changes to this policy

We may update this policy. Material changes will be reflected in the "Last updated" date above. This policy does not create any rights in any third party.