Walking to the Moon — Privacy Policy

Effective date: 2026-08-01

Last updated: 2026-08-24

Operator: Joonwoo Park, individual developer

Available in: United States and South Korea

Minimum age of use: 14

이 방침의 한국어판: 개인정보처리방침 (한국어) (https://joonwoopark.me/walking-to-the-moon/privacy-ko)

Walking to the Moon turns the steps you already take into progress toward the Moon. This policy explains exactly what the app reads, what stays on your iPhone, what is sent anywhere, and how to remove it.

The short version: your journey and Health data stay on your iPhone unless you separately turn Social on. In solo mode, the app can send an empty, account-free request for anonymous worldwide Atlas reach counts; Firebase App Check and the network service may process attestation, IP, and diagnostic metadata, but the request contains no steps, Health data, local profile, or journey position.

Overview

Walking to the Moon turns steps into progress toward the Moon, Earth-equator equivalents, and a fictional World Trail. A person can start fresh or optionally bring an aggregate snapshot of the walking history Apple Health makes available through the journey’s activation boundary.

Total steps are the source of journey progress. The app converts steps into a standardized step-equivalent distance using steps × 0.75 m; personal height, stride, and recorded walking distance do not affect rank. Apple Health’s recorded Walking + Running Distance remains a private informational metric.

The solo journey is account-free. The local player profile, daily movement history, display-only Today cache, aggregate historical snapshot, recorded distance, and private recaps stay on the iPhone. Social features are optional. After consent, a person can create a Firebase guest profile without a provider login and may later link Apple or Google for recovery. Sharing imported aggregate steps requires an additional, separate consent that is off by default. Global visibility is a further opt-in.

Apple Health data

Walking to the Moon requests read-only access to:

• Steps

• Walking + Running Distance

The app never writes to Apple Health. It does not request workouts, heart rate, calories, Contacts, or real location.

The app captures an exact activation timestamp and uses two nonoverlapping intervals. Optional history is strictly before that boundary, and post-activation collection begins at the boundary. If a person chooses Bring available Apple Health history, the app previews the aggregate before saving it. Activity at or after the boundary is post-activation progress even if it occurs while the preview is open.

Walking to the Moon describes the result as available Apple Health history, not an entire-life history. Apple Health may expose only limited history, and Apple does not reliably reveal denied read access to apps. An empty result may mean no activity exists or that access is unavailable.

The history preview may show imported steps, recorded or resolved distance, estimation status, and the first and last observed activity dates. The dates identify observed activity only; they do not describe the beginning or end of an authorized window.

For private informational distance, recorded Walking + Running Distance is used when available for an interval. If steps exist without recorded distance, the app may resolve that interval as steps multiplied by 0.75 meters and marks it estimated. It does not add recorded and estimated distance for the same interval.

The Today screen separately queries the complete locally available Apple Health step total for the current calendar day. On the activation day, this can include steps taken before the activation boundary. A protected display cache stores only the local day, aggregate steps, and refresh time. That complete-day value never enters post-activation movement, all-time journey progress, Atlas crossings, recaps, Social Day, analytics, or uploads.

Core Motion live display

While Today is visible, the app may use the iPhone motion coprocessor through Core Motion to make the displayed step number rise between Apple Health refreshes. This foreground-only live delta begins at the latest Health refresh time, remains in memory, and is discarded when Today closes or a new Health snapshot arrives. It is not saved, uploaded, added to journey progress, or used for Social. Steps detected only by Apple Watch appear after they reach Apple Health rather than through this live layer.

Motion & Fitness access is separate from Apple Health access and can be changed in iPhone Settings. If it is denied or unavailable, the stored journey still uses Apple Health; only the between-refresh live display is absent.

Data kept on the iPhone

The following information may be stored locally:

• journey activation time, home time zone, and selected route revision;

• post-activation daily step and recorded/resolved-distance aggregates;

• whether a daily distance includes an estimate;

• an optional HistoricalImportSummary containing aggregate imported steps, recorded/resolved distance, estimation status, first and last observed activity days, activation boundary, import date, and revision;

• a TodayHealthSnapshot containing only the current local day, aggregate steps, and refresh time;

• a local PlayerProfile containing a username, modular AvatarDescriptorV2, revision, and timestamps;

• private weekly and monthly recaps;

• local preferences, consent records, and pending aggregate sync operations;

• an account-scoped deletion-recovery journal containing the private Firebase account ID, optional random public ID, linked-provider types, recovery phase, and a Boolean recording whether the exact Google account was freshly confirmed. A separate Boolean may record that Google cleanup is still pending. These records contain no provider credential, raw provider identifier, email, name, photo, Health value, or movement data.

Walking to the Moon does not store historical Health samples, workouts, device or source-app identities, real locations, or fabricated daily history for the imported baseline.

The local movement store is excluded from ordinary device backups and is not synchronized through CloudKit. Local journey data remains until the person removes imported history, resets the journey, or removes the app, subject to iOS storage behavior.

Refreshing imported history can preview a higher or lower corrected aggregate. A new nonempty snapshot is stored only after confirmation. An empty refresh does not erase an existing snapshot. Removing imported history does not move the activation boundary or delete post-activation movement.

Anonymous Atlas reach statistics

The app can request worldwide aggregate counts showing how many opted-in Social profiles have reached each numbered Atlas stage. This works without a Firebase account so solo walkers can see the aggregate. The callable request has an empty app payload and does not include steps, a stage number, journey position, Apple Health data, the local profile, or a device-created user identifier. The response contains only the catalog revision and one aggregate count per stage. The app caches a successful response for up to one hour and falls back to local copy if the request fails.

Turning Social on also contributes the profile’s current Atlas stage anonymously to those worldwide counts, whether or not the person separately appears by name on the Global leaderboard. The server derives that stage from post-activation steps plus imported aggregate steps only while separate history sharing is active. It stores one internal account-linked numeric stage mark so it can move or remove the anonymous bucket contribution when progress or consent changes. The mark is not returned in the public aggregate response or a leaderboard row; it is included in the account holder’s Social export and removed when sharing is paused or the Social account is deleted. A consent-v3 record counts as current only after the person checks a self-attestation that they are 14 or older. The app does not verify age or infer it from Apple, Google, Health, or other provider profile data.

Firebase Cloud Functions and Firebase App Check with App Attest process this request in the United States. As with an ordinary network request, Google and Apple may process service metadata needed to deliver and protect it, including IP address, app and device integrity signals, and request or diagnostic metadata under their policies. Walking to the Moon does not write that service metadata into its Social database or combine it with local Health or journey data.

Optional social data

Post-activation sharing

After social consent v3 and creation of a Firebase anonymous guest, Walking to the Moon may send a mission aggregate containing:

• total post-activation steps;

• current-day post-activation steps;

• current-week post-activation steps;

• current-month post-activation steps;

• current-year post-activation steps;

• the calendar day the journey started, shared once and never changed afterward, and not sent when a restored device does not know it;

• fictional World Trail route ID and revision;

• a monotonic mission revision;

• freshness rounded to a calendar day;

• a server-claimed public username and validated modular character descriptor;

• invitation, friendship, block, pause, and Global-visibility state.

Imported-history sharing

History consent v1 is separate and off by default. If enabled, Walking to the Moon may send a separate baseline containing only:

• imported aggregate steps;

• a monotonic history revision.

The server stores mission and history baselines separately and derives combined totals for authorized leaderboard projections and the anonymous Atlas stage count. Withdrawing history consent removes only the remote history baseline and the imported contribution to projections and may move the anonymous Atlas stage mark downward. It does not remove post-activation mission progress.

Walking to the Moon does not send the complete-day Today cache, recorded or resolved distance, estimation status, observed dates, raw Apple Health samples, workouts, source devices or apps, routes, GPS location, granular activity timestamps, height, stride, private recaps, bios, chat, or Contacts to its Social database or other walkers. If you link Google, Google Sign-In and Firebase Authentication receive and retain the provider account identifier and basic profile data, which can include name, email address, phone number, and profile-photo URL depending on the provider account and authentication flow. The app does not offer phone authentication or request extra Google scopes. Those provider fields are never copied into public Social documents.

Friends, Global, and leaderboard periods

Friends receive private aggregate leaderboard summaries after an invitation is accepted. The Global leaderboard is separately opt-in and exposes only an opaque public ID, claimed username, validated modular avatar, authorized aggregate progress (including the daily-average inputs: period step totals and the journey start day), virtual checkpoint, rank, and day-rounded freshness. Firebase user IDs are not returned in leaderboard rows.

• Day, Week, and Month compare post-activation steps only.

• Total compares post-activation steps plus imported steps only when separate history sharing is active.

• Total profiles can show the imported and post-activation aggregate split.

• Equal step values share rank.

• A first Day, Week, or Month may be labeled partial because it begins at activation.

• Walker profiles show a daily average derived from the shared aggregates above, and the shared journey start day makes how long someone has been walking visible to other walkers, displayed as a month and year.

Walking to the Moon does not disclose whether a zero imported value means the person did not import history or chose not to share it.

Public usernames are 3–20 lowercase ASCII characters, begin with a letter, and permit digits or single underscores. The server claims usernames case-insensitively, filters reserved and profane terms, and limits public username changes to once every 30 days. Public avatars use only bundled allowlisted parts; uploaded photos are not supported. People can block another user immediately or submit a fixed-reason report. A report stores the reporter and target account identifiers, the target’s random public ID, one fixed reason, status, and timestamps. Privileged review uses an IAM-private moderation service deployed for this app. It is reachable only by individually granted reviewer identities and is never public. It shows the target’s current public username and voyager plus sharing, Global-visibility, and moderation state, and can add a compact case reference, operator identity, fixed decision code, before-and-after moderation state, and projection-verification result. It can temporarily suspend leaderboard projections. A qualifying removal proposal temporarily holds the target’s linked-identity fingerprints while a different allowlisted reviewer decides whether to confirm or reject removal. Independent rejection or cancellation releases those holds; if the profile still exists, its projections can be restored. If the person voluntarily deleted the profile while review was pending, releasing the holds does not recreate deleted data. Confirmed removal reuses the complete Social cleanup, deletes the app-side Firebase Authentication account, verifies removal, and promotes the applicable holds into blocks. That removal path does not reset public identity and cannot revoke the provider’s own Apple or Google grant because the operator does not have the user’s fresh authorization. Restricted identity records retain only a SHA-256 fingerprint and provider type, not the raw provider identifier, email, name, photo, or token. These records do not contain raw Health data, walking totals, daily charts, screenshots, or free-form report text. The workflow requires two different allowlisted reviewers: one proposes removal, and one independently confirms or rejects it. Until a second reviewer is named, the developer moderates alone: suspensions, restorations, and appeals take effect immediately, while a permanent removal remains a pending, suspended state until a different reviewer independently confirms it. Support and moderation questions can be sent to doldorijw@gmail.com.

Service providers and processing location

Network features use:

• Cloud Functions and Firebase App Check with App Attest for the account-free, read-only Atlas aggregate described above;

• Firebase Authentication for durable anonymous guest sessions and optional Apple or Google account linking;

• Cloud Firestore and Cloud Functions configured in us-west2;

• Firebase App Check with App Attest.

Firebase Authentication is a United States-hosted service. Google processes service data under its Firebase terms and privacy documentation. Walking to the Moon does not integrate the Firebase Analytics or Crashlytics products for this revision. Firebase SDKs and App Check can still process limited request, attestation, and service-quality metadata, including during the account-free Atlas request. Their bundled privacy manifests declare unlinked other diagnostic data for analytics purposes.

Apple processes Apple Health and optional Sign in with Apple information under Apple’s terms. Google Sign-In and Firebase Authentication can process the provider account identifier and basic profile fields supplied by Google for optional account linking and recovery. Google documents that Google Sign-In may process an IP address to estimate coarse location for fraud prevention. The Google Sign-In SDK privacy manifest also declares linked name, email address, phone number, user ID, device ID, coarse location, other usage data, and other data types for app-functionality and/or analytics purposes. These declarations do not mean the app requests iOS location access, accesses the advertising identifier, enables advertising, or uses cross-app tracking. Walking to the Moon uses provider credentials only to authenticate or protect the Firebase account and does not copy provider name, email, phone number, profile-photo URL, device information, location, or SDK usage metadata into public Social or leaderboard documents.

Linking Apple or Google preserves the guest Firebase account identifier and its social data. If a provider credential is already attached to another profile, Walking to the Moon does not automatically merge the profiles. The person can keep the guest profile or explicitly delete its remote social account before opening the provider-protected profile. This choice does not alter local Apple Health steps or the local journey on this iPhone.

On a new iPhone, signing in with a previously linked Apple or Google account can recover only the same Social profile and data still held for it: public identity, friends, consent state, post-activation aggregate progress, and an imported-step aggregate only while its separate sharing consent is active. It does not recover daily charts, recaps, the Today cache, private recorded or resolved Health distance, observed activity dates, or device settings. The local movement store remains outside CloudKit and ordinary backups.

Retention

• Pausing sharing deletes both canonical remote aggregate records and their friend and Global projections. Resuming requires republication from local storage after current consent is confirmed, and Global visibility must be explicitly enabled again.

• Withdrawing imported-history sharing deletes the history baseline and removes imported progress from projections while retaining authorized post-activation mission progress.

• Turning off Global visibility deletes the Global projection.

• An unlinked guest Social profile cannot be recovered after reinstalling or loss of its local Firebase credential. Firebase automatic anonymous-account cleanup is disabled because guest profiles are intended to remain durable until the account holder deletes them. A moderation projection suspension does not delete the profile. The two-reviewer operator-removal workflow is deployed for this app; until a second reviewer is named, a proposed removal remains a pending, suspended state. A guest has no stable linked-provider identity, so removal can delete the current guest Social account but cannot reliably recognize the same person behind a later anonymous account.

• Invitation records expire after 1 to 14 days and are eligible for Firestore time-to-live deletion after expiration. One invitation can be redeemed by more than one walker until it expires, and each redeemer is recorded on it so that walker’s own account deletion can remove their entry.

• Deleting the social account revokes or disconnects linked provider access as applicable and deletes the Firebase Authentication account, username claim, social profile, mission and history aggregates, invitations, blocks, report relationships, friendships, leaderboard projections, and any active projection-suspension ownership record.

• Restricted moderation case, audit, removal-approval, and linked-identity hold and block records created during privileged review are not automatically deleted with the Social account. They may retain pseudonymous account identifiers, report and case references, fixed reasons and decisions, operator identity, timestamps, cleanup-verification state, and a SHA-256 fingerprint plus provider type for a linked identity whose removal is pending or confirmed. They do not retain the raw provider identifier, provider email, name, photo, token, Apple Health values, or daily history. A valid independent rejection or cancellation releases the applicable temporary identity hold. If the profile still exists, suspended projections can then be restored; data the person already deleted is not recreated. Under the approved retention schedule, decided moderation cases and their audit events are retained for 12 months from the decision and then de-identified, keeping only the fixed reason, decision code, and timestamps for aggregate statistics. Restricted identity blocks created by a confirmed removal are retained indefinitely so a removed account cannot return, are reviewed annually, and are released only by a recorded two-reviewer decision. Appeal correspondence is deleted 12 months after the final decision on that appeal.

• An unfinished deletion keeps a durable server job until the same operation safely resumes and verified cleanup removes it. The job can retain a pseudonymous account reference, operation and cleanup phase, provider types and SHA-256 provider fingerprints, relationship or projection cleanup targets, and provider-revocation state. It contains no Health data, credentials, raw OAuth tokens, raw provider identifiers, email, name, or photo. It has no automatic expiry, because expiry could let a stale device or request recreate account data before deletion finishes. Contact support if deletion remains unfinished.

• Deleting the social account does not delete the account-free local journey unless the person separately resets it.

Cloud provider operational logs and SDK service-quality systems may retain request, usage, or diagnostic metadata under provider policies. Walking to the Moon does not intentionally place health values in application logs, SDK analytics, diagnostic reports, support tickets, or push-notification payloads.

Controls

The app provides controls to:

• keep using the app without an account;

• create and edit a local username and modular avatar without enabling Social;

• import, preview a refresh of, or remove the local aggregate Apple Health history;

• consent separately to post-activation sharing and imported-history sharing;

• withdraw imported-history sharing without removing post-activation sharing;

• opt into or out of the Global leaderboard;

• pause all social sharing and delete shared progress;

• remove or block a friend;

• report a public user for one of the available reasons;

• link Apple or Google to protect a guest Social profile;

• export the in-app package containing the current Social profile, circle memberships, outgoing blocks, mission and history aggregate records, created invitation IDs, submitted reports, and linked provider types;

• delete the social account and revoke or disconnect linked provider access as applicable;

• reset the local journey separately.

Health access can be changed in iOS Settings or Apple Health. Motion & Fitness access for the foreground Today live display can be changed separately in iPhone Settings. Apple does not reveal Health read-access denial directly to apps, so Walking to the Moon cannot always distinguish no data from unavailable access.

Security and integrity

Walking to the Moon uses transport encryption, provider encryption at rest, App Check, App Attest, server-only writes, strict Firestore rules, transactional username claims, strict modular-avatar allowlists, reserved-name and profanity filtering, hashed expiring invitations, fixed-reason reporting, suspension-aware projections, deletion fencing, and exact payload allowlists.

Implausible-jump filtering applies only to post-activation mission steps. Imported-history replacements may move up or down to reflect Health corrections, but require an active history consent, App Check, a higher revision, bounds checking, and a 24-hour server-side replacement cooldown. Health-derived totals can still be edited in Apple Health and are not represented as cheat-proof.

Children

Walking to the Moon is not intended for anyone under 14, and the operator does not seek to collect personal information from anyone under 14.

Fourteen rather than thirteen: COPPA sets the United States threshold at 13, and PIPA requires a legal guardian’s consent below 14. The higher number satisfies both launch regions.

If you believe someone under 14 has created a Social account, write to doldorijw@gmail.com. The workflow immediately suspends that account’s leaderboard projections, and the app-side Social account is removed only after a second, different allowlisted reviewer confirms the proposal. Until a second reviewer is named, the account remains suspended with its linked-identity holds in place, and removal completes once independent review is available. Restricted-record retention follows the approved schedule in the Retention section.

Overseas transfer of personal information

This section is provided for users in South Korea, where transferring personal information abroad must be disclosed.

With Social off, Health-derived walking aggregates, the solo journey, the local profile, and local progress do not leave the iPhone. However, the empty Atlas aggregate request and its App Check protection can still transfer network, attestation, and diagnostic metadata to the providers below. Turning Social on additionally transfers only the consented aggregate and Social data described earlier; raw Health samples and private Health distance remain on the iPhone.

• Transferred to: Google LLC, through Firebase Authentication, Cloud Firestore, Cloud Functions, and Firebase App Check.

• Country and location: United States, in the us-west2 region (Los Angeles).

• When and how: when the app refreshes the anonymous Atlas aggregate, and when consented Social progress or actions are sent, over encrypted HTTPS connections.

• What is transferred: with Social off, the Atlas request has an empty app payload, while Firebase App Check, Apple App Attest, and the network service can process IP address, app and device integrity signals, and request or diagnostic metadata. With Social on, database transfers additionally include the aggregates listed above plus the public username and character descriptor. Social processing in the United States also includes invitation, friendship, and block state; internal and random public account identifiers; fixed-reason report data; and, after deployment of the private moderation function, restricted case, audit, removal-approval, cleanup-verification, and linked-identity hold and block data derived during privileged review. Optional Apple, Google, and Firebase Authentication separately process the provider account identifier and any basic profile fields supplied by that provider. Google Sign-In and Firebase SDK service processing can additionally include coarse location inferred from IP address and the usage, device, other-data, and unlinked diagnostic categories described under “Service providers and processing location.” None of those provider profile or service-metadata fields enter public or leaderboard records.

• Purpose: operating and protecting the optional Social and account-recovery features, preventing abuse, and maintaining SDK/service quality. The data is not used for advertising or cross-app tracking.

• Retention: as described under “Retention” above. Deleting the social account deletes the active authentication, profile, relationship, aggregate, and projection data. Restricted moderation case, audit, approval, and linked-identity hold and block records follow the separate rule above.

Leaving Social off, or turning it off later, prevents transfer of walking aggregates and Social profile data. It does not disable the read-only Atlas aggregate request; using the app without a network connection prevents that request and leaves the core journey usable with local Atlas fallback copy.

Privacy officer

PIPA requires a named person responsible for personal information. For Walking to the Moon that is the operator:

• Name: Joonwoo Park

• Role: operator and privacy officer

• Contact: doldorijw@gmail.com

Enquiries, access requests, correction requests, and deletion requests all go to that address. Settings can delete the active Social account and separately reset the local journey without writing to anyone. Requests concerning restricted moderation case, audit, removal-approval, or linked-identity hold or block records must use the contact address and remain subject to the approved legal-retention rule.

Your rights

In both launch regions you may ask what is held about you, ask for it to be corrected, and ask for it to be deleted.

Most active account data does not require asking. The app exports the package listed under Controls, deletes the active Social account from Settings, and can reset the local journey there too. The in-app export does not include reports submitted about you or restricted moderation case, audit, removal-approval, or linked-identity hold or block records. Contact the privacy officer for requests involving records the app cannot expose or delete directly.

Changes and contact

Material policy or upload-scope changes require an updated in-app consent version before affected publication resumes. Social consent v3 and history consent v1 are independent.

Questions about this policy: doldorijw@gmail.com

Reference material

• Apple Health authorization behavior (https://developer.apple.com/documentation/healthkit/authorizing-access-to-health-data)

• Apple Health privacy (https://developer.apple.com/documentation/healthkit/protecting-user-privacy)

• Apple App Review Guidelines (https://developer.apple.com/app-store/review/guidelines/)

• Firebase privacy and security (https://firebase.google.com/support/privacy/)

• Firebase Authentication with Apple (https://firebase.google.com/docs/auth/ios/apple)

• Firebase anonymous authentication (https://firebase.google.com/docs/auth/ios/anonymous-auth)

• Firebase Authentication with Google (https://firebase.google.com/docs/auth/ios/google-signin)

• Firebase Apple-platform data collection (https://firebase.google.com/docs/ios/app-store-data-collection)

• Google Sign-In for iOS privacy (https://developers.google.com/identity/sign-in/ios/app-privacy)