145 lines
6.9 KiB
Markdown
145 lines
6.9 KiB
Markdown
# 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 is limited to pickup/delivery of an already purchased or
|
|
reserved legal item. Requests for medical advice, prescriptions, cash advances,
|
|
controlled substances, 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 only operator-supplied policies across all
|
|
replicas. Registration and magic-link email scopes can also be configured.
|
|
- No public exact location by default.
|
|
|
|
No numeric rate policy is enabled by default because no threshold has been
|
|
approved or measured for this deployment. Supported action names currently
|
|
include `registration_email`, `magic_link_email`, `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 role
|
|
protected. 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 administrator cannot demote themselves.
|
|
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.
|