Footprints
Privacy PolicyTerms of Service
한국어日本語English繁體中文

Footprints 2.0.0 Privacy Policy

Published: 2026-10-12 Scope: features actually provided in iOS 2.0.0. Accounts, country-pack purchases, guestbooks and account backup apply only when the relevant service has completed its pre-release checks. Publishing this notice does not launch the app or those online services. Earlier documents are available in the history below. This policy applies when the initially public 2.0 account and purchase services are provided with verified deletion and recovery procedures. Purchase recovery is offered only where the necessary Apple, device and server verification is ready; this notice does not mean a feature awaiting activation is already operational.

1. Operator, contact and age

Operated by individual developer Shin Dongnyeok (Nyeok), based in the Republic of Korea. Privacy contact for access, correction, copies, erasure and restriction requests: contact@nyeok.co. The service is intended for people aged 14 or older.

2. Information processed on your device

Walk records can include time, precise locations and routes, movement/step information and recording state. Notes and drafts, selected places, profile/settings, photo-derived visits, representative-photo references/crops/colors and imported visits can be stored locally. Location, photo and motion access follows your chosen features and granted permissions. The app does not arbitrarily delete photo-library originals. Selected Google Timeline JSON visits, timestamps, coordinates and administrative-area associations are analyzed on-device; they are not added to analytics error events.

3. Accounts, guestbooks and optional backup

Account IDs, display names/handles, installation/device-verification information, authentication/session state and consent purposes/versions/times may be processed for sign-in, account management and abuse prevention. Guestbooks process post text, selected publication locations, neighborhood/visit eligibility and moderation state. Selected public posts and locations may be visible to other eligible members; this is different from publishing your entire walk route. Optional account backup can send encrypted records, precise routes, saved notes and walk-note drafts including their text, place scopes and update times, settings and selected-photo restoration material to the server. If account recovery is chosen, the server may also process recovery-key material; we do not make a blanket promise that the operator cannot decrypt it. Optional iCloud backup uses your private CloudKit area and its own archive scope. Signing out is not account deletion or record erasure. Account-owned records and drafts are hidden and isolated from other accounts while retained on your device. An unverified backup is not described as a reason for permanently deleting local records.

4. Purchases, advertising and Google's processing

Apple in-app purchase handles payment for extra country packs and ad removal. Product/transaction identifiers, purchase environment, verification/revocation times and account-binding information may be processed to verify the original account's rights, restore purchases and reflect refunds or revocations.

The policy separately processes a minimal ownership marker to verify purchase-account binding, actual deletion completion, recovery eligibility and duplicate recovery. The deletion marker has six items: purchase environment (Sandbox or Production), app ID (bundle ID), SHA-256 hash of the original transaction ID, product ID, SHA-256 hash of the UUID linking the account that owned the purchase before deletion, and the actual deletion-completion time verified by the server deletion job. A deletion request or replay of a deletion event during backup recovery does not populate that time; purchase recovery requires verified actual completion. The marker does not retain raw original/current transaction IDs, account UUID or appAccountToken, a separate appAccountToken hash, purchase/signature/refund timestamps, a transaction-body hash or raw JWS, names, email addresses, payment methods or amounts. Walks, routes, photos, notes, posts and raw diagnostics are also excluded. Purpose-separated SHA-256 hashes are pseudonymised personal information, not secret-key encryption or anonymisation.

If you request post-deletion purchase-right recovery, the policy checks Apple signatures on the app-download proof (AppTransaction) and purchase transaction, their matching app/purchaser binding, current validity and cancellation state of a directly purchased non-consumable product, and one-time proof tied to the current signed-in account and registered device. The server re-fetches the current transaction from Apple. A transaction number or a client claim of ownership alone grants no rights. Older transactions lacking required evidence are held for insufficient proof rather than bypassing verification.

A short-lived challenge row stores only its challenge ID, references to the new active account, session, device and registered App Attest key, purchase environment/app/product/original transaction hash, nonce hash and creation/expiry times. Raw Apple JWS and the device-verification identifier are used for verification but not stored in the deletion marker or challenge row. Challenges are valid for ten minutes, consumed and deleted on success, and expired rows are deleted by the existing maintenance process. Account deletion and product support end also clear them. Expiry does not mean every copy is erased at that instant. Following successful recovery, operational transaction data needed for the new active account’s rights, restoration and refund handling follows the existing purchase-verification scope.

In 2.0.0, country or original-installation date does not exempt a user from advertising. Verified ad-removal purchases remove ads. Ads are placed only at the bottom of guestbooks in all countries, not on recording or map screens. Purchase state and UMP privacy permission are checked before requesting an ad. The app disables advertising personalization and publisher first-party ID; these settings alone do not guarantee that all SDK identification, combination or tracking is absent. Google Mobile Ads SDK may process IP/general location, device identifiers, app/device information, advertising/interactions and performance/diagnostic data for ad delivery, frequency limits, fraud prevention and measurement. App restrictions on adding precise routes, photos, notes, account or transaction identifiers to an ad request are separate from the SDK's own collection. When UMP requires a privacy-options entry, reopen Advertising privacy settings from the Ad removal screen in Settings. Analytics consent and advertising privacy choices are separate.

5. Optional analytics and API error measurement

Usage analytics is collected only with consent, which can be withdrawn in Settings. Collection is not allowed before consent; withdrawal stops new collection and requests a local analytics reset. It does not immediately erase all previously transmitted information. Firebase/Google Analytics may process an app-instance identifier, app/device information, IP-based general region and limited usage events. API error measurement classifies failures, cancellations, recovery and completion in account, backup, purchase and advertising-consent operations to assess reliability. App-added error fields are predefined operation/error-class/error/server codes, HTTP status, retryability/retry-count band, latency band, outcome, environment, app version/build and schema version. Raw error messages, request URLs/headers/bodies, tokens, account/user/transaction identifiers, precise location/routes, place names, photos and note text are excluded from these fields. This restriction is not a blanket no-collection claim about separate Google SDK processing.

6. Storage, retention and erasure

The policy atomically consumes and deletes a deletion marker when valid purchase-right recovery succeeds, or deletes it when a legitimate permanent end of purchase-right support is confirmed through a separate ledger and its administrative process completes. No finite end date or automatic deletion schedule is currently defined for unrecovered markers. Stopping sales, a refund or account deletion alone does not end support or introduce a new expiry for an existing permanent non-consumable purchase. If ledger confirmation fails during support closure, purchase intake for the product is closed while markers remain for retry using the same support-end event. Legitimate end conditions and procedures require separate review; this text authorises neither automatic/periodic erasure nor arbitrary termination of paid rights. The same product ID is not reactivated after support end to reassign rights. This retention is distinct from statutory transaction records and does not justify long-term retention of complete transactions, ordinary records or raw diagnostics.

You may request access, correction, erasure or restriction of processing at contact@nyeok.co; requests are handled under the applicable legal requirements. We do not reject privacy rights wholesale merely because data is a purchase marker. Data no longer necessary for its purpose or required by law to be erased is erased without delay. Items subject to an actual legal preservation obligation are separately identified with their basis and period.

When an account service applies this policy, ordinary account data follows the existing deletion process; operational purchase transactions and intents, free-country selections, preserved installation-right grants and account-specific preservation registrations are also included in erasure. The ownership marker does not extend retention of ordinary account data or raw diagnostics. Transaction records subject to an actual separate legal retention obligation must be separated into a system with verified necessary items, legal basis and period; the minimal marker itself is not a statutory transaction ledger. Where operational purchase records include genuinely required statutory items, only those items are separately retained with restrictions and other deletion data follows the deletion process. Lack of preparation of a retention system is not itself a basis to deny privacy rights. If erased data was already included in existing disaster-recovery backups, their separate expiry limit of up to seven days may apply. This does not guarantee deletion of every device, iCloud or provider copy, or completed backup/restore validation for the new marker.

Local information may remain until you erase it or remove app data, including hidden information retained after sign-out. Uninstalling does not automatically delete iCloud or account-server copies. Optional analytics follows Google's information-specific retention settings; an earlier notice's two-month statement is not a deadline for deleting all aggregates or all provider information. When account services are provided, request acceptance, active-data erasure, recovery-copy expiry and erasure-evidence removal are distinct stages. The existing target for ordinary active data, excluding the minimal purchase ownership marker, is erasure within seven days of the request; evidence expires at the later of seven days after actual erasure and fourteen days after the request. The existing seven-day disaster-recovery snapshot expiry is not seven-day deletion of every datum or token. Report retention expiry is set to fourteen days after submission; this does not guarantee deletion of provider copies at that time. Individual job success or immediate complete deletion of every replica is not guaranteed.

7. Providers, overseas processing and report notifications

Apple processes payments/StoreKit and optional iCloud; Google processes optional analytics and advertising/consent tools. The website uses AWS static hosting; optional account/backup/guestbook processing is a separate service. The links below describe provider roles and privacy practices. Countries and periods can differ by service/settings; an unverified country or obtained transfer consent is not asserted. If external report notifications are offered, Telegram may receive report ID/reason, author display name, neighborhood, reported public text, status and moderation buttons, not the entire account or walking archive. The code uses protected group notifications and disables previews, with an attempt to edit out text after about twenty-four hours and retry failures; it does not guarantee erasure of every provider replica. Recipient, processing country, retention, transfer basis and choices must be defined and disclosed before this public feature is provided. The unresolved public feature is not provided. Ask contact@nyeok.co about refusal/options, separately from other service consent.

8. Rights, choices and changes

Device permissions, analytics consent, advertising choices, account backup and post publication have different purposes/effects. You can refuse or withdraw each applicable choice; refusing analytics does not prevent basic local recording. Request access, correction, copies, erasure/restriction and status through available app features or contact@nyeok.co. Copies received by other readers and information retained by providers may require separate erasure procedures. Changes are published here and in the dated history; material changes are notified by reasonable means before application.

Provider privacy information

  • Apple Privacy · Apple refunds
  • Google Privacy · Google Mobile Ads data disclosure · Google Analytics retention
  • AWS Privacy · Supabase Privacy · Telegram Privacy

Existing Android notice · outside this iOS 2.0.0 correction

Previous version · 1.3.1 release documents

  • 1.3.1 released document · build 354

contact@nyeok.co · © 2026 Nyeok