Privacy
Version: ppld-2026-11-17-v2. Effective date: November 17, 2026.
Ppld operates ppl’d. George is the privacy contact. For privacy questions, access or correction requests, withdrawal requests or complaints, email georgehinin@gmail.com.
Hosted phone sign-up and pilot processing are enabled. This notice describes the account and matching features, the current internal validation configuration and what those features process.
Information used for the pilot
The account system is designed to hold your phone number, account identifier, birth date, username, display name, setup progress and terms acceptance version and time. The birth date supports the adults-only admission check. A verified session does not grant social access until required setup is complete.
The service also stores authentication/session records and, where notifications are enabled, a device push token associated with your sign-in session. Phone verification needs Auth and an SMS delivery provider, Twilio; final provider retention is unresolved.
For matching, the service uses the availability you provide, selected-calendar busy ranges, sync coverage and freshness, time zone, rounded home area, preferences, relationships and blocks. It records proposals, answers, locked plans and optional attendance answers to operate the service and understand outcomes. Busy times, rounded areas and preferences can reveal patterns about your routine. They are personal information, not anonymous data. Availability is an estimate, not a guarantee of attendance. The first pilot is a two-person, in-person service.
Calendar event titles, notes, addresses and attendee details stay on your phone. The upload contains busy intervals, a coverage interval, selected calendar count and sync metadata. Your phone can show a conflicting event title locally before you accept a plan. The first pilot excludes address-book import, continuous location tracking, photo uploads and consumer web accounts.
Email correspondence
If you email the public contact address, Ppld receives your sender email address, the message contents and any attachments you choose to send. These can contain personal information even if you do not have an app account. The purpose of this correspondence is to understand and respond to your support, privacy or deletion question or request. Do not include sign-in codes, passwords, raw calendar contents or unnecessary information about another person. Government ID is not requested by default.
George is the sole human request owner under Ppld's correspondence policy. That policy prohibits automatic forwarding, routine exports and shared handling of Ppld correspondence. These are handling requirements; the inbox's actual access, forwarding and device-copy settings have not yet been verified.
What others see
The design hides participant identities before a plan locks and keeps declines, opt-outs and private priorities out of other people's views. Locked participants can see the confirmed plan and the other participant's identity. Phone-number sharing is a separate choice. The service still processes private responses to operate matching and lifecycle transitions; hidden from other users does not mean absent from the server.
Reports contain a reason and optional text and are visible only to authorised operators through the private report system. The reported person is not told who reported them. Your name or other personal details may remain in a reporter's text or an operator's note after account links are removed.
Service providers and coordination
The public contact address uses Gmail, provided by Google. Google handles email contents through that service under its Privacy Policy. The inbox's access, forwarding, retention and erasure settings have not been verified.
Supabase supplies the account/database platform. Notification delivery, once enabled, uses Expo and Apple's notification service; the sender processes device tokens and notification content. Phone verification uses an SMS provider. The final hosted database, SMS and push settings, processing regions and retained records have not yet been verified. Sentry and PostHog are described below.
When you deliberately open a text composer or WhatsApp link from a locked plan, the chosen app receives the shared number and starter message needed for that action. That action does not establish that a message was sent, delivered or read. Copies shared with another person or messaging service are outside the application's account-row deletion transaction.
Diagnostics and usage data
The ordinary build sends no vendor telemetry. Deliberately marked internal validation builds can send reviewed usage events to PostHog US Cloud and native errors and crash information to Sentry's US region. Preview and production vendor sending are not enabled by the present configuration. Any activation of vendor sending requires a fresh disclosure matched to the actual approved configuration.
The existing usage-data choice defaults to on and can be turned off in settings. An unreadable saved choice counts as off. Events use a random installation identifier after the signup adult check or a keyed pseudonymous account identifier after sign-in. This is pseudonymous data, not a promise of anonymity. Event schemas exclude free-text fields; events include bounded actions, results, counts, app version, environment and timing. Some events also carry app-generated session IDs or proposal IDs. A proposal ID can be linked to its corresponding service record by an operator with access. Events remain linked to the pseudonymous installation or account ID. Opting out clears queued usage events, but does not establish deletion of previously sent vendor records.
Sentry native reports can contain a random installation identifier and system and crash information. JavaScript filtering removes reviewed sensitive fields, but native reports bypass that filter. Native IP inference can produce city-level location at ingestion; disabling default personal information in the SDK does not guarantee that connection IP data is discarded. Only internal validation sending is currently permitted pending the provider setting review. Performance tracing, session replay, screenshots and view-hierarchy capture are off. PostHog autocapture and replay are not used by this explicit-event client.
PostHog receives the connection address when events are sent. Discarding an IP address can happen after location enrichment; the actual project setting and enrichment behavior still need verification. The current source does not establish that no IP-derived information is processed.
US processing involves handling information outside Canada, where foreign authorities may be able to access it under their laws. The final vendor inventory, contracts, actual settings, access risks, retention and erasure procedures still need review. The database, SMS and push providers' final hosted regions and retention are not verified.
How long information is kept
These are the current database retention rules, not verified promises about the hosted service or all provider copies. The nightly purge must be operating for scheduled removal to occur.
| Information | Current application database rule |
|---|---|
| Account phone, birth date, profile, rounded home area and account-owned settings | Removed with current account rows when deletion processing succeeds; a changed home area replaces its current value |
| Busy times | Past portions removed by the nightly purge |
| Hangout history | Purged after the slot has been over for more than 12 months |
| Lifecycle events and person/calendar activity records | Generally purged after more than 12 months; notifications linked to a hangout or match run leave with that parent |
| Match runs and candidate/supply records | Purged after more than 365 Toronto calendar days only when no hangout still depends on the run; a retained newer hangout can extend this |
| Reports and operator report events | Purged after more than 2 years, with each event measured from its own time; this period remains subject to legal review |
| Deletion processing receipts without person or request identifiers | Purged after more than 30 days |
| Banned-number keyed hashes | No age-based expiry; retained to enforce the ban after deletion |
Email messages and attachments are held separately from app account rows. Deleting an app account does not automatically remove that correspondence. The following operator policy applies to inbox messages and other copies under Ppld's control:
- Routine support correspondence is kept for up to 90 days after documented case closure, and removed earlier when no longer needed. This limit includes recoverable Gmail Trash.
- A minimal record of an access, correction, privacy or deletion request is normally kept for one year after closure, including time in recoverable Gmail Trash. Necessary underlying information is preserved for available rights and recourse, even if that requires longer retention.
- Attachments and verification material are removed earlier once no longer needed. A justified legal or safety hold can extend retention. Every extension beyond a normal period needs a recorded purpose and review date.
By the applicable normal deadline, operator-controlled inbox, sent, recoverable Trash and identified downloaded/mail-client/device copies must be permanently removed unless a recorded necessary rights/recourse preservation or justified hold extends retention. Moving a message to Trash on the due date does not add another 30 days. These periods are operator policy choices, not statutory time limits or an automatic deletion system. Actual inbox handling and removal have not yet been verified.
Gmail moves deleted messages to Trash; Google's deletion guidance explains its up-to-30-day Trash period and earlier permanent deletion option. Operator-controlled Trash is included in the deadlines above. Google-managed copies and backups have a separate lifecycle; this policy does not establish their complete-erasure timing. You can ask the privacy contact about correspondence relating to you.
Calendar source choices and session information also exist on the device. App cleanup is separate from erasure of server, backup and vendor copies.
Deletion and remaining copies
A confirmed deletion request restricts social access and queues processing. Successful processing removes current application and Auth primary rows in one transaction. Some random ledger pseudonyms remain after their account mapping is removed. Reports lose account links but can retain identifying free text. A ban's keyed phone hash remains personal data because a key holder can test a guessed number.
Managed Auth audit entries can retain the deleted account's actor identifier and phone number. Database-row deletion does not prove erasure from external Auth logs, Sentry, PostHog, Expo, an SMS provider or backups. Their actual retention and deletion procedures remain unresolved. No complete-erasure claim or deadline is made here.
Matching replay storage is off by default. If separately approved and enabled, its implementation encrypts a matching-input snapshot for 1 to 30 days, default 30 pending review, and removes current snapshot content when any included account is deleted. Backups can retain the encrypted content and key material or the means to recover it. A restore can also bring back deleted accounts. Key custody and a procedure to reapply deletions remain unresolved; encryption alone does not establish irrecoverable erasure.
Questions and requests
Email georgehinin@gmail.com to ask about your information, request access or correction, ask to withdraw consent or make a privacy complaint. Describe the request without sending passwords, sign-in codes, calendar contents or another person's private information. Account ownership must be verified before private information can be disclosed or changed. To verify ownership, George sends a one-time reference to the account's phone number and asks you to quote it in your email. It is not a sign-in code. No response or completion deadline is promised here.
You can turn off Share usage data in settings. That controls optional analytics; it does not revoke device permissions, provider grants or processing needed to operate your account. You can manage device permissions in your phone's settings. Ask the privacy contact about withdrawing other consent and the effect on your account. Processing needed to provide an account may require you to stop using that feature or request deletion; legally justified retention may continue. The final handling process and applicable requirements remain to be settled.
Read account deletion for the current limitations and support for help.