who_need_help/docs/trust-safety.md

# Trust, safety, and abuse model

Status: MVP policy and implementation requirements. This document does not
claim that the system can eliminate bad actors.

## Safety boundary

Who Need Help is a coordination tool for adults. It is not an emergency service.
Every urgent screen must tell users to contact local emergency services when
life, health, fire, violence, or immediate danger is involved.

The medicine category permits a requester to ask whether a volunteer is willing
to purchase, pick up, and deliver a lawful medicine. Accepting a request never
obliges a volunteer to spend money. The matched people arrange pharmacy or
prescription requirements, payment, reimbursement, storage, and handover
directly in private chat. The platform does not prescribe, recommend, sell,
process payment, extend credit, or guarantee reimbursement. Requests for medical
advice, controlled substances, unlawful supply, payment credentials, public
prescription disclosure, or suspicious repackaging are reportable and removable.

Social activities are a separate product mode. They do not use handover codes,
helper reviews, live movement evidence, or the helper leaderboard. The
organizer approves participants individually. Public viewers see only an
approximate or hidden meeting location; exact coordinates and group chat are
available only to approved participants. Users are told to use a suitable
public first meeting point and to keep home addresses, access codes, travel
documents, and other sensitive details out of public text.

## Verified completion

A completion is counted as verified only when all of these occur:

1. A helper accepted the request.
2. Both parties confirmed the completion.
3. The requester shared the one-time handover code with the helper.

Optional location proximity is supporting evidence, never a mandatory
prerequisite. This avoids excluding users who deny geolocation permission,
while making simple remote rating rings less useful.

The public reputation summary separates:

- completed requests;
- unique people helped;
- verified handovers.
- optional location-supported interactions.

The helper leaderboard ranks unique counterparts with optional proximity plus
helper-movement evidence first, then unique handover-verified counterparts,
then unique counterparts, and only then raw completions. Repeated work with the
same person cannot increase the primary unique counters.

## Reviews

Reviews are double-blind. A review becomes visible only after both participants
submit. There is no automatic reveal timeout in the MVP. Reviews are allowed
only for completed matched requests.

## Identity and social links

Email ownership can be confirmed through a magic link. Manually attached
GitHub, Instagram, Facebook, Telegram, Google, or other URLs are labelled
“unverified.” If the operator configures a GitHub OAuth App, a user can instead
complete a state- and PKCE-protected authorization flow and receive a verified
GitHub badge. The flow is bound to the initiating signed-in user, each GitHub
account can belong to at most one local account, and the provider access token
is discarded after the public profile is read.

No other social provider is currently verified. A verified GitHub profile is
one trust signal, not government identity verification or proof of real-world
safety.

The MVP uses 18+ self-attestation. It does not imply government identity
verification.

## Implemented abuse controls

- Completion requires both confirmations plus a request-specific handover code.
- Public reputation separates completed work, unique people, and handover-code
  verification.
- Reviews require a completed assignment and remain hidden until both parties
  submit.
- Blocks remove discovery in both directions, prevent acceptance/new chat, and
  delete the pair's active exact positions.
- Reports target exactly one request, assignment, or message. A moderator can
  load chat only through an assignment/message report.
- Missing optional proximity/movement, repeated pairs, reciprocal direction,
  and configured action velocity create review signals. They do not
  automatically punish an account.
- PostgreSQL action buckets enforce the compiled pilot policy or an explicit
  operator replacement across all replicas. Registration, password login,
  magic-link delivery, and email
  changes can each be limited by both normalized email and client IP in one
  atomic database statement.
- No public exact location by default.

The initial pilot policy enables only public authentication, email change, and
anonymous support/content-removal intake. Its account/email ceilings are lower
than its IP ceilings so a shared network is not treated as one person. The
values are product policy rather than universal security or capacity
thresholds. Authentication action pairs are
`registration_email`/`registration_ip`,
`magic_link_email`/`magic_link_ip`,
`password_login_email`/`password_login_ip`, and
`email_change_email`/`email_change_ip`. Other supported action names include
`create_request`, `accept_request`, `start`, `confirm`, `verify_handover`,
`cancel_request`, `withdraw_assignment`, `send_message`, `start_tracking`,
`tracking_position`, `review`, `report`, `block`, `category_proposal`, and
`category_vote`. Activity actions additionally include `create_activity`,
`join_activity`, and `send_activity_message`.

The system does not claim to be bot-proof. Email confirmation, database
uniqueness, unique-counterpart ranking, location evidence, velocity policies,
signals, and human review raise the cost of simple rating farms but cannot prove
identity or eliminate coordinated abuse.

## Moderator access

A moderator can access private chat only from a specific assignment or message
report. Every access records the moderator, report, linked assignment, message
count, and timestamp. The report itself contains the reason. Browsing private
conversations without a qualifying report is not a product capability.

The same boundary applies to Activity group chat. Reporting an Activity itself
does not reveal its private chat. Only a report targeting a specific Activity
message permits the moderator to load that Activity's group conversation, and
the evidence access audit records the Activity and message count.

Report, request, signal, category, role, and account moderation are protected by
the multi-role permission matrix described in `docs/staff-operations.md`.
Support, moderation, legal, and analytics access can be combined on one
account; administrators receive every permission. The local Codex
batch receives proposal text and aggregate vote counts only. It receives no
private messages, email addresses, OAuth tokens, exact coordinates, or raw
tracking routes.

## Money

Help is free. A helper may add an external voluntary tip link. It appears after
completion, is labelled optional, and routes directly to the helper. The
platform does not calculate, collect, split, refund, guarantee, or report the
payment. The legal and tax treatment remains dependent on the users'
jurisdiction and is not represented by the product.

## Operational response

Reports have `open`, `reviewing`, `resolved`, and `dismissed` states. A severe
report can hide a request and temporarily restrict an account pending review.
Suspension invalidates that account's login sessions. The first administrator
requires an explicit one-time operational bootstrap, and later role changes are
audited; the last active administrator cannot remove their own admin access or
be restricted.
The operator must publish jurisdiction-specific emergency contacts, privacy
notice, prohibited-items policy, and data-retention policy before public launch.

Public support and legal removal are separate from in-product reports. Support,
moderation appeals, privacy/data requests, general electronic removal notices,
and a dedicated TAKE IT DOWN intake are described in
`docs/support-and-content-removal.md`. Public contacts are verified through an
emailed private status link; moderator/admin decisions and access remain
audited. The removal forms never accept intimate-media uploads.

### Child sexual abuse and exploitation

The public `/child-safety` standards explicitly prohibit child sexual abuse
and exploitation (CSAE), including child sexual abuse material (CSAM), grooming,
sextortion, sexualization, and child trafficking for sexual exploitation. This
policy applies even though registration is limited to adults and the current
product does not accept user media uploads.

Users can report the relevant request, activity, profile, or message in the
product using the dedicated `child_safety` reason. This in-product moderation
report is deliberately separate from the public `/legal/content-removal` route,
which also accepts an anonymous `child_sexual_abuse_material` report without
accepting a file upload. Reporters are instructed not to reproduce, forward,
download, or email suspected CSAM.

The category enters the restricted legal queue as `urgent_review`. The assigned
operator must immediately assess whether access should be restricted, content
disabled, or an account suspended; preserve only information necessary for the
review and applicable reporting duties; and record the decision in the audited
case. After actual knowledge of confirmed CSAM, the responsible operator must
report it to NCMEC or the relevant regional authority where applicable law
requires that report. The operator must not mark Google Play's child-safety
self-certification complete until all of the following are true:

- a named, monitored child-safety point of contact has been selected;
- that person can access the urgent queue and understands this procedure;
- inbound contact from Google Play to the selected address has been tested;
- the applicable reporting authority and escalation path for the launch
  jurisdiction have been reviewed by the operator; and
- the public standards and in-app reporting path have been verified against the
  deployed release.

This is an operational policy and implementation record, not a claim that code
alone establishes legal compliance in every jurisdiction.