Privacy
Moral Trade separates public profile data from private wish-profile data. Exact wishes, asks, constraints, and verification preferences should stay private unless a user chooses to share more.
This pilot uses a small set of operational data categories. The summary below is meant to make the processor, purpose, and retention story readable before users create private wishes, payment records, or evidence notes.
Purpose: Authenticate users, show opt-in public profiles, and preserve profile portability.
Processors: Supabase for authentication and database storage.
Retention: Kept while the account or review record needs it; export, correction, deletion, and restriction requests start from the dashboard or contact route.
Purpose: Support broad previews, consent-gated introductions, and manual source summaries.
Processors: Stored in Moral Trade records backed by Supabase; new sensitive wish/source text is app-level encrypted before storage.
Retention: Kept only for the consent scope or review workflow that needs it, with exact wishes and source notes excluded from public cards and analytics.
Purpose: Reconcile agreement payments, donation-route handoffs, and optional evidence records.
Processors: Stripe for participant payment objects; Every.org for off-site donation routes.
Retention: Payment identifiers, status, amount, cadence, and evidence notes may be retained for reconciliation, disputes, audit integrity, and compliance needs.
Purpose: Measure whether visitors understand the pilot and reach the right next step.
Processors: Internal funnel records; future analytics tools must follow the same redaction rules.
Retention: Uses path, event type, coarse counts, buckets, partner codes, and attribution cookies; exact wishes, contact details, report bodies, and raw source notes are excluded.
Purpose: Send account, evidence, review, background-networking, and digest updates.
Processors: Email delivery may use an external provider; in-app and web-push preferences live in Moral Trade records.
Retention: Preference rows and delivery records are retained to honor opt-outs, diagnose failed delivery, and avoid exposing private wish text by email.
Public pages may show profile names, broad cause areas, public offers, comments, recommendations, ratings, and follower counts. Private wish profiles are used for match suggestions and consent-gated introductions.
Background networking creates a real trade-off. If exact wishes are broadly visible, they can be used for surveillance, harassment, or exploitation. If everything is hidden absolutely, harmful collusion can become harder to detect. The current design aims for a middle layer: broad previews, field-level grants, manual review, and narrow disclosure tied to specific counterparties or stages.
The dashboard can record possible links to blogs, email, calendar records, chatbot history, search profiles, and other sources. For now, these records store consent scope, import mode, reviewed summaries, and approved derived profile signals only. The app does not automatically ingest, scrape, or search raw external data.
Active external connectors require a separate source permission, consent notes, one of the supported retention windows (30, 90, 180, 365days), and a field list chosen from broad matching categories.
Optional AI shadow-mode review is a separate source-level consent. It may use approved summaries only and cannot change live matching, ranking, disclosure, or outreach. Live source connectors, AI assist mode, and private-overlap computation require a DPIA, lawful-basis record, privacy-design review, and external security/privacy review before expansion. Private overlap checks are not live; any future pilot must not use free text and must not reveal raw tags.
Privacy grants let a participant decide whether a fact stays hidden, becomes broad, becomes specific, or becomes contact-level for a particular introduction workflow. The app also exposes portable profile export and import endpoints so wish data can move later if a more decentralized registry becomes preferable.
Disclosure contract
The public disclosure contract defines which fields can move from registry preview to consent and introduced stages. It names redacted fields, search privacy controls, owner approval, expiry windows, and the rule that evaluation cannot reveal private fields or change grants by itself.
registry, consent, introduced.
hidden, broad, specific, contact.
exact private wishes before consent, exact asks before consent, contact details before introduction, raw source notes, sensitive constraints in public preview, private feed payloads.
Stripe handles card and payout details. Moral Trade stores payment status, Stripe object identifiers, amount, currency, cadence, and agreement references so participants can reconcile commitments.
Moral Trade may record lightweight product events such as page views, worked-example opens, cohort interest, donation-route clicks, onboarding steps, and invite actions. The purpose is to understand whether visitors find the right pilot path, not to score moral value or automate outreach. UTM parameters, referral codes, partner cohort slugs, first path, last path, and referrer may be stored in a short-lived attribution cookie and copied into internal funnel records. Background networking events should use counts, buckets, and state labels; they should not copy exact wish text, private constraints, report bodies, source notes, or notification message text into analytics.
Optional funnel analytics can be turned off for this browser. Turning it off clears the attribution cookie, prevents middleware from recreating it, and makes optional funnel event ingestion return without storing a row. Account, safety, security, payment, abuse-prevention, and rights-request records remain governed by their own purposes and retention rules.
The app uses authentication cookies through Supabase, an attribution cookie for cohort and campaign measurement, and ordinary browser state needed for interactive forms. The public pilot should not use cookies to mine private feeds, infer exact wishes, or send surprise counterparty exposure.
Supabase supports authentication and database storage. Stripe handles card, payout, and payment objects when payment workflows are enabled. Every.org handles direct donation routes opened from the donation page. Email delivery may use an external provider for queued notifications. Those services have their own security and privacy obligations outside Moral Trade's direct control.
Signed-in participants can delete the background-networking layer without deleting the whole account by typing DELETE BACKGROUND NETWORKING in the dashboard. The action removes participant-facing matching records while retaining only redacted or anonymized safety, budget, and operator audit rows where review integrity requires it.
Pilot records are retained while they are needed for account access, safety review, evidence reconciliation, disputes, legal compliance, and abuse prevention. Participants can use the dashboard to export profile data or record export, correction, deletion, and restriction requests, with the caveat that some public records, audit events, payment references, or safety records may need to be retained to preserve review integrity.
The dashboard exposes in-app, digest email, and web-push preference rows by event type. Discovery alerts default to digest cadence with quiet hours and source cooldowns. Email copy for background networking stays generic and leaves exact wishes, contact details, private asks, source notes, and sensitive constraints in the dashboard.
Admin review should be limited to safety, abuse, payment, and delivery operations. Private wish details should not be disclosed to other participants unless the product has a consent gate for that disclosure.
For privacy, safety, or processor questions, use the contact page or email support@moraltrade.org with the relevant page, proposal, or workflow reference. Safety and coercive-baseline concerns should be routed as review issues rather than ordinary support questions.