PaceLink Go - Privacy Policy

PaceLink Go is a group travel companion for iPhone and Android, developed by Daniel Szlaski ("we", "us", or "our"), the controller of the personal data described here. It shows distance and time gaps between people who choose to join the same trip. This policy covers both platforms; platform-specific processing is labelled below.

No account is required, but the App does process personal data: your chosen display name, precise location during a trip, temporary trip identifiers, a persistent pseudonymous device record, and purchase, usage, and diagnostic information. We do not use advertising SDKs, advertising identifiers, or cross-app tracking, and we do not sell your personal data. We keep both aggregate daily usage counts and separate trip counts associated with a verified device record. Pseudonymous means associated with a code instead of your name; it does not mean anonymous.

1. Information Used During a Trip

• Display name: a name or nickname you enter, remembered on your phone and sent to our service when you create or join a trip. You do not need to provide your legal name, email address, telephone number, or contacts.
• Precise location: latitude, longitude, timestamp, accuracy, speed, and direction of travel. Recent location samples are sent to our service to calculate relative positions, distance gaps, and estimated time gaps.
• Trip and participant information: randomly generated trip and participant IDs, invitation links and codes, host status, join/leave times, trip start/end/expiry times, and session credentials used to control access.
• iOS Live Activity information: Apple push tokens and the most recent activity state, including participant names, IDs, relative positions, gaps, and speed information, so updates can reach your devices.

Location collection runs during an active trip, including in the background when permitted. A host waiting alone for the first guest does not start live location sharing. You can leave a trip, end it as the host, or revoke location access in your phone’s Settings. Disabling access prevents the location features from working.

Android: during an active trip, a location foreground service sends precise location to our backend so participants can see relative positions and gaps, including while you use another app or the screen is off. An ongoing trip notification accompanies this service. Leaving or ending the trip stops local location sharing; an offline departure request is saved for retry. You can also revoke location permission in Android Settings. Notification and battery settings can affect updates.

2. Who Can See Your Trip Information

Other participants in the same trip receive your display name and live trip information. The trip service also makes current locations and recent location trails available to authenticated participants. An invitation link or valid code lets someone join, subject to the trip's capacity and expiry. Share invitations only with people you trust.

On iOS, Live Activities can show trip information on the Lock Screen, Dynamic Island, and supported connected displays such as CarPlay. People who can see those displays may see that information. On Android, ongoing notifications and supported Live Updates can show trip information, including on the Lock Screen depending on your settings. We cannot erase screenshots or copies made by other participants, including the companion details in their local trip summaries.

3. Storage, Retention, and Deletion

Temporary GPS data: each server location record is assigned an expiry time no later than 45 minutes after its sample timestamp, capped at the trip's scheduled expiry. Ending a trip requests deletion of its GPS records; leaving requests deletion of that participant's GPS records. These are cleanup requests, not a guarantee that every copy is erased instantly.

If a request fails, the phone is offline, a write is already in progress, or database cleanup is incomplete, records can remain pending automatic deletion. Database expiry is asynchronous: physical removal can take a few days after the expiry timestamp, as described in AWS's expiry documentation. The service rejects live location access once the trip has ended or expired, and rejects a participant's access once their departure is recorded by the server.

Trip metadata: names, membership records, credentials, push tokens, and cached activity state are not all deleted when the host taps End. Most temporary trip records are assigned expiry at the scheduled trip end plus five minutes, followed by the database's deletion delay. Extending a trip extends the relevant records' expiry. Invitation-code lookups have a shorter expiry; ending a trip also requests deletion of its invitation lookups.

Local trip history: the App clears its in-memory GPS trail when a trip stops. It saves summaries on your phone containing dates, duration, distance, moving/stopped time, speed statistics, participant count, companion names and participant IDs, and aggregate/final gaps. These summaries contain no coordinates or route history and are not uploaded as a history archive. They have no automatic expiry. On Android, use Delete summary or Clear history in Past trips to remove local summaries. The iOS version has no in-app history deletion control. Deleting the App (rather than offloading it) removes its local app data; device backups may retain copies according to your Apple settings on iOS. Android trip storage is excluded from cloud backup and device transfer.

Other local storage on iOS: your display name, a legacy hosting counter used for aggregate statistics, and an installation marker are saved in app preferences. The server determines your free-trip balance; resetting preferences does not reset it. Random device credentials and a recovery secret are kept in this device's Keychain, together with verification state and any unfinished free-trip request (including its display name and retry identifier). These allow secure re-registration and recovery after an interrupted request. They are not synchronized through iCloud Keychain and may survive uninstalling the App. An active host credential is kept in the device's Keychain to recover the trip. It is cleared on a confirmed end or expiry; a failed end request may leave it available for recovery.

Other local storage on Android: your display name, session credentials, pending trip/departure and purchase requests, and trip summaries are stored in an encrypted local journal protected by Android Keystore. No coordinates are saved in that journal. Clearing app storage or uninstalling removes this local data, but does not delete our server records or reset the allowance for the same recognized device.

Device records: the pseudonymous identity, free-trip allocation and used-credit counts, and verification/recovery records described below currently have no automatic expiry. They remain after trips end and after uninstalling so the same allowance cannot be claimed repeatedly. This includes records associating verification keys with the same device identity. Separate per-device usage counts are assigned expiry 730 days after the last recorded creation or activation; physical deletion follows the database's asynchronous cleanup. Verification challenges expire after five minutes and are consumed on use or queued for automatic deletion.

The device database uses recovery backups, so deleting a live record does not immediately remove it from existing backups. Apple's DeviceCheck marker is held by Apple separately; deleting local app data or our database record does not itself clear that marker. Contact us about deletion or a device you acquired from someone else.

Other longer-lived data: the purchase records and daily usage counters described below have no automatic expiry. Configured server diagnostic logs have a 14-day retention period. If you contact us, we receive your email address and message and retain the correspondence as needed to resolve the request and meet applicable obligations.

Security records: rate limiting uses a hash of the request IP address, route, and minute with a short expiry (approximately two minutes), followed by asynchronous deletion. Failed GPS cleanup jobs retain trip/participant references until cleanup succeeds; they do not contain coordinates.

4. Purchases

On iOS, optional Trip Pass purchases use Apple's App Store and StoreKit. The App sends a signed Apple transaction to our backend for verification. We retain the transaction ID, product ID, purchase time, consumption time, and associated trip ID to prevent a purchase from being reused. These records currently have no automatic deletion date and remain after the trip ends; they contain no GPS coordinates. We do not receive your payment-card details from Apple.

Android purchases: Google Play Billing processes Trip Pass payments. The App sends the purchase token, product ID, and package name to our backend, which verifies the purchase with Google. Our consumed-purchase record uses a hash derived from the token and package name as its transaction identifier, together with the product, purchase and consumption times, and trip ID. It has the same retention described above. Pending purchase tokens may be kept in the encrypted local journal to finish a purchase. We do not receive payment-card details from Google.

5. Device Verification and Free Trips

The two welcome trips are an allowance per recognized device, not per installation or account. We verify eligibility and keep the used balance on our server to prevent repeated claims, tampered requests, and duplicate spending. Creating a free-trip invitation uses a credit even if nobody joins. Reinstalling does not grant a new allowance.

iOS: App Attest and DeviceCheck

• What the iOS App sends to us: an app-generated random identifier, a recovery secret, Apple's App Attest key identifier and cryptographic proofs, and an Apple DeviceCheck token when checking the allowance. They are sent over HTTPS to verify the App and authorize requests. We do not collect an advertising ID, hardware serial number, or IMEI for this purpose.
• What we retain for iOS: a keyed hash of that random identifier (HMAC), a hash of the recovery secret, platform, verification key identifier and public key, proof fingerprint and replay-prevention counter, allocation status, and credits granted and used. We do not retain the raw random identifier, recovery secret, DeviceCheck token, or full attestation proof in the device database. Private App Attest signing keys remain on the device.
• What Apple processes: App Attest verifies an app-generated key on your device. We send the DeviceCheck token to Apple to check and record a yes/no marker that the welcome allowance has already been allocated. That marker can survive reinstall and is scoped to our Apple developer account. It is used for allowance protection, not to send Apple your route or per-device trip counts. Apple does not give us a universal hardware identifier through these services.

Android: Android ID and Play Integrity

The App reads Android ID, which is scoped to the device, Android user, and app signing key. It sends a SHA-256-derived value, not the raw Android ID, together with a one-use challenge and Google Play Integrity token to our backend over HTTPS. We store a further keyed hash as the pseudonymous device identifier, platform, verification identifier, allowance status, and granted/used counts. The Android allowance record does not store the raw Android ID or full Integrity token.

Google processes app and device integrity information to produce the token; our backend asks Google to verify it and checks app recognition, licensing, device integrity, and its binding to the request. Play Integrity verifies the app/request; it does not provide us with a universal hardware identity. The request binding uses hashes, rather than sending Google your trip’s raw location history.

The derived Android identifier normally remains the same after reinstalling under the same Android user and signing key, so the server can recover the allowance. A factory reset, different Android user, or signing-key change can change it. Android does not use Apple's DeviceCheck marker or iOS recovery-secret mechanism. We do not collect an advertising ID, hardware serial number, or IMEI for this purpose.

The persistent device record contains no display name, coordinates, route history, or IP address. However, temporary hosted-trip metadata links to it for usage counting; while that metadata exists, it can associate the record with that trip and its host. It is therefore not anonymous. Other participants are not given your device credentials or persistent device identifier.

On iOS, if recovery credentials survive reinstall, the App can reconnect to the same record. If they are lost, Apple's marker may still prevent another allowance, but we may be unable to recover unused credits or connect the replacement identity to the old one. A device record is not a reliable count of unique people or a complete lifetime device history.

If verification is unavailable, the App cannot confirm or allocate free trips. Joining and independently verified paid hosting remain available. Contact support if you believe eligibility is incorrect, including after buying a used device.

6. Usage Counts and Diagnostics

We keep daily totals of events such as trips created, repeat hosting, invitations shared, guests joining, trip-duration milestones, host-ended trips, paywall views, and purchases after the welcome allowance. The statistics table stores daily integer counters, not individual event histories, names, coordinates, device IDs, participant IDs, trip IDs, or IP addresses. The host's previous-trip count is sent when creating a trip only to calculate legacy aggregate counts; it does not authorize free trips.

Separate per-device counts: for hosting requests associated with a verified device record, we count free trips created, paid trips created, and trips activated when the first guest joins. We use these counts to understand hosting usage and operate the service. They are linked to the pseudonymous identifier, not stored as a list of routes or individual location events. Paid hosting without device verification is not attributed to a device record. These counts are separate from the aggregate statistics table and have the retention period in section 3.

Operational logs are separate from these counters. They can contain error messages, request-route information, temporary participant IDs, and reasons a location sample was rejected. The code does not intentionally log GPS coordinates or payment-card details, device recovery secrets, DeviceCheck tokens, or request proofs. Our hosting providers necessarily process network information, including IP addresses, to deliver and protect the service. Android and iOS also maintain system diagnostics; their handling and sharing depend on your operating-system settings.

7. Service Providers and Security

Our backend uses Amazon Web Services, with trip databases configured in the Frankfurt, Germany region, along with the device and usage databases. Connections use HTTPS and the databases use encryption at rest. Session credentials restrict trip access. These measures reduce risk but cannot guarantee absolute security.

On iOS, Apple provides DeviceCheck and App Attest for device verification, processes App Store purchases, and delivers Live Activity updates through Apple Push Notification service. Push payloads contain activity information such as names, speed, and relative gaps, rather than raw GPS coordinates. Apple's services and provider operations may involve processing outside your country. See Apple's Privacy Policy and AWS's Privacy Notice for their handling of information. Your separate navigation app handles data under its own policy; PaceLink Go does not need access to its saved destinations.

On Android, Google provides Play Integrity and Google Play Billing. Android trip notifications are generated on the device from trip updates, rather than delivered through Apple's push service. Google’s services may process information outside your country; see Google's Privacy Policy.

8. Purposes, Choices, and Your Rights

We process trip and purchase information necessary to deliver the service you request. Location sharing is optional and controlled by your participation and your phone’s permissions. We use device verification, allowance records, and necessary diagnostics for our legitimate interests in securing the service and preventing repeated free claims or purchase reuse. We use aggregate and pseudonymous device usage counts for our legitimate interest in understanding service usage and improving its operation. You may object to processing based on legitimate interests by contacting us. We retain information where required by law. We do not use your data for advertising profiles or automated decisions with legal or similarly significant effects.

Depending on applicable law, you may request access, correction, deletion, restriction, or portability of your personal data, object to processing based on legitimate interests, or withdraw consent where processing relies on consent. You may complain to your local data-protection authority, including Poland's President of the Personal Data Protection Office (UODO). Learn more about EU data rights.

Request deletion of your data

Email [email protected] with the subject “PaceLink Go data deletion” and tell us whether you use Android or iOS. No PaceLink Go account needs to be created or deleted. Contact us here to exercise your rights. Since the App has no account directory, we may need enough information to locate the relevant device record, trip, or purchase and verify the request. The current App has no self-service device-record deletion control; contact us for assistance. We will explain any lawful need to retain limited records for fraud prevention or other obligations. Deletion is not a promise of a renewed free allowance. Do not send private keys, recovery secrets, session tokens, or precise location history by email. We cannot retrieve already-deleted GPS records or identify you from aggregate daily counters.

9. Children and Updates

The App is a travel companion, not a child-monitoring service. If you believe a child has provided personal data without appropriate authorization, contact us so we can address it. We may update this policy as the App changes and will show the revision date above.

10. Contact

Daniel Szlaski
Pileckiego 9, 05-250 Radzymin, Poland
Email: [email protected]
VAT ID (NIP): PL1251270430