JetLag: Wear OS Weather & Time Privacy Policy

# Privacy Policy for JetLag: Wear OS Weather & Time **Last Updated:** September 28, 2026 This Privacy Policy explains how the JetLag: Wear OS Weather & Time application handles information. JetLag: Wear OS Weather & Time is a weather, city-time, and travel-planning app for Android phones and Wear OS smartwatches. ## 1. Core Privacy Principles - **No JetLag: Wear OS Weather & Time account:** JetLag: Wear OS Weather & Time does not require a developer-operated account, login, or registration. - **Local-first app data:** Saved locations, resolved coordinates, preferences, cached weather/forecasts, travel settings, synchronization state, and local entitlement caches are stored in app-private storage. - **Developer-operated weather gateway:** JetLag: Wear OS Weather & Time uses the Google Play backend Supabase project as the primary remote gateway for coordinate-based current weather and as a shared geographic cache. - **Encrypted transport:** Supabase, weather-provider, Google Play, RevenueCat, Google Mobile Ads/UMP, and Wear Data Layer traffic use the relevant services' secure network transport. - **Optional rewarded advertising on phone:** JetLag: Wear OS Weather & Time 1.10.0 can offer a user-initiated rewarded ad in exchange for 12 hours of temporary JetLag: Wear OS Weather & Time Pro. JetLag: Wear OS Weather & Time does not use banner, interstitial, app-open, forced, or Wear OS ads. - **No unrelated analytics SDK:** This change does not add a separate product-analytics SDK. - **No Android backup:** Phone and Wear app backup/device transfer remain disabled for JetLag: Wear OS Weather & Time app data. Advertising is a distinct privacy-footprint change from earlier JetLag: Wear OS Weather & Time versions. Users can continue using the Free tier or purchase permanent Lifetime Pro without watching an ad. ## 2. Information Used for Weather JetLag: Wear OS Weather & Time does not request approximate, precise, or background **device location** permission. You choose city names manually. JetLag: Wear OS Weather & Time can resolve a selected city to latitude and longitude and save those coordinates locally. For a saved city with coordinates, current-weather refresh normally follows: 1. Fresh local Room weather cache. 2. Developer-operated Supabase `jetlag-weather` gateway. 3. Direct-device weather-provider emergency fallback only when Supabase is unavailable, times out, returns an invalid contract, or otherwise cannot service the request. 4. Existing local stale/offline behavior when remote recovery fails. The Supabase request contains the selected city's latitude, longitude, and weather schema version. JetLag: Wear OS Weather & Time does not intentionally attach your name, email address, contacts, payment-card details, purchase token, or a developer-created account identifier to the weather request. A selected city's coordinates are not claimed to be your physical device location. Standard network services can necessarily process transport metadata such as source IP address, request time, and connection information while handling a request. ## 3. Supabase Shared Weather Gateway and Cache Supabase is JetLag: Wear OS Weather & Time's first remote source for coordinate-based current weather. It first checks a shared city-area cache. On a cache miss, trusted server-side code selects an enabled upstream weather provider, normalizes the response into JetLag: Wear OS Weather & Time's canonical weather contract, stores the result, and returns it. Android/Wear clients never upload arbitrary weather payloads into the shared cache. The shared cache can contain: - a versioned geographic cache key based on rounded latitude/longitude; - normalized bucket latitude and longitude; - normalized current-weather values required by JetLag: Wear OS Weather & Time; - weather provider and source/freshness metadata; - optional upstream HTTP revalidation metadata. The shared weather cache deliberately does not contain JetLag: Wear OS Weather & Time account IDs, names, email addresses, contacts, purchase tokens, a user's saved-city list, or per-user behavioral history. Fresh current-weather cache entries normally remain fresh for about 30 minutes. Provider-specific cache rules and stale retention are documented in `docs/weather-backend.md`. Short-lived refresh leases and aggregate request-budget counters are used for coordination and are not designed as per-user tracking records. To limit abuse of the public gateway, the gateway may derive a short-lived abuse-prevention key from the connecting network address. The address is combined with a server-side secret and the current hour through a keyed one-way hash (HMAC-SHA-256); the raw address is not stored or logged, the key cannot be linked across hours, and the per-minute counters keyed by it are deleted within about 15 minutes. It is used only to cap refresh requests per connection and is not an account, device, or advertising identifier. Gateway diagnostic logs identify geographic cache buckets only by a keyed hash, never by raw latitude/longitude. The mobile app cannot directly read or write Supabase cache tables. Row Level Security and restricted table privileges are used; server-side code performs cache writes. Private provider credentials remain server-side where the migrated gateway path supports that architecture. The previous `jetlag-weather-fallback` endpoint remains for compatibility with already released JetLag: Wear OS Weather & Time versions. ## 4. Upstream Weather Providers The server-side current-weather provider order is designed to avoid duplicate calls: 1. **MET Norway Locationforecast** — preferred zero-key source. 2. **WeatherAPI.com** — optional fallback when configured. 3. **OpenWeather** — optional server fallback only when explicitly enabled under an appropriate plan/license. A successful provider ends the failover sequence. During migration, direct Android provider support remains for legacy geocoding, forecast recovery, and emergency Supabase-outage resilience. Existing client-side OpenWeather/WeatherAPI credentials are technical debt and are not expanded to new providers. JetLag: Wear OS Weather & Time does not use the public Open-Meteo free API in production. ## 5. Local Storage JetLag: Wear OS Weather & Time may store locally: - saved cities, canonical names, country codes, resolved coordinates, and existing persisted order; - current conditions and hourly/daily forecast caches; - temperature, time-format, refresh, display, active-hours, and travel preferences; - Travel Day configuration/state; - provider-failure and stale-data state; - Wear OS Tile and complication state; - phone/watch synchronization state; - a local cache of Google Play Lifetime ownership reconciliation state; - RevenueCat temporary-entitlement status and server-reported expiration metadata used for revalidation; - bounded HTTP cache entries used for direct-provider emergency/forecast paths. When temporary Pro expires, JetLag: Wear OS Weather & Time does not delete saved cities, forecast caches, city metadata, travel configuration, active hours, or watch configuration. Free mode exposes only the deterministic active Free subset while preserving the rest for a future Pro entitlement. ## 6. Permanent Google Play Lifetime Pro JetLag: Wear OS Weather & Time may offer the permanent one-time Google Play product `jetlag_pro`. It does not offer a subscription. Google Play processes purchases and payment information under Google's terms. JetLag: Wear OS Weather & Time receives purchase status and related Billing metadata so it can unlock, restore, acknowledge, or reconcile permanent Pro. JetLag: Wear OS Weather & Time does not receive or store payment-card details. The existing Google Play BillingClient path remains the permanent authority. RevenueCat temporary access does not replace it and is not required to recognize historical `jetlag_pro` purchasers. A pending Google Play purchase does not unlock Lifetime Pro. Current ownership is reconciled through Google Play when available. A temporary RevenueCat or advertising outage cannot remove a legitimate Lifetime entitlement. ## 7. Optional Rewarded Ads and Temporary Pro On the **phone app only**, a non-Lifetime user can choose **Watch an ad for 12 hours of Pro**. This is optional. JetLag: Wear OS Weather & Time does not automatically show rewarded ads and does not require an ad before the permanent purchase option. The rewarded flow uses: - **Google User Messaging Platform (UMP)** for applicable consent/privacy choices; - **Google Mobile Ads / AdMob** to load and display a rewarded ad after the user requests it; - **RevenueCat** to verify the rewarded event through AdMob server-side verification and expose temporary entitlement `jetlag_pro_12h`. AdMob's local "user earned reward" callback is **not sufficient to grant Pro**. JetLag: Wear OS Weather & Time waits until RevenueCat reports verified temporary access. The app does not create a locally authoritative "12 hours from now" grant. Server-reported expiration metadata is used to schedule/recheck entitlement state. Depending on region, consent choices, device/service configuration, and the current SDK policies, Google Mobile Ads/UMP may process information such as advertising/device identifiers, IP address/network information, app interactions related to requesting/viewing an ad, consent state, diagnostics, and fraud/security signals. RevenueCat may process an app-user/customer identifier generated/managed by its SDK, entitlement/reward-verification information, device/app metadata, IP/network information, and diagnostics needed to provide the temporary entitlement service. Exact production disclosures must be reconciled against the current Google and RevenueCat documentation and JetLag: Wear OS Weather & Time's actual SDK configuration before each release. JetLag: Wear OS Weather & Time does not use rewarded advertising on Wear OS. The Wear release runtime is checked to prevent Google Mobile Ads, UMP, or RevenueCat dependencies from leaking into the watch module. ## 8. UMP Privacy Choices When required by Google's consent framework and the user's region/configuration, JetLag: Wear OS Weather & Time requests UMP consent information before requesting a rewarded ad. If privacy choices prevent an ad request, JetLag: Wear OS Weather & Time does not grant temporary Pro and leaves existing Free or Lifetime access unchanged. When UMP reports that privacy options are required, JetLag: Wear OS Weather & Time exposes an **Ad privacy choices** action on the phone Pro screen. Availability and wording of consent choices are controlled by the UMP/AdMob configuration and applicable law/policy. ## 9. Android Backup and Device Transfer Android backup/device transfer is disabled for the JetLag: Wear OS Weather & Time phone and Wear apps. JetLag: Wear OS Weather & Time does not intentionally back up saved cities, coordinates, weather caches, preferences, travel settings, or local entitlement caches through Android backup. A reinstall can restore an active permanent `jetlag_pro` purchase by querying Google Play with the same purchasing account. Temporary rewarded access is restored only if RevenueCat still reports the verified entitlement active; JetLag: Wear OS Weather & Time does not manufacture it from local storage. ## 10. Phone and Wear OS Synchronization If you use both apps, saved cities, resolved city metadata, settings, cached weather/forecasts, refresh status, travel state, and a **derived effective Pro capability** may synchronize between devices through Google Play services Wear OS Data Layer APIs. The watch does not run Google Play Billing, RevenueCat, AdMob, or UMP. It does not receive purchase tokens or ad-reward callbacks. The phone computes effective capability and sends the derived state to Wear. Watch-originated city additions are sent to the phone, which applies the same Free/Pro city policy and returns the canonical result. Phone/watch Data Layer payloads are not routed through Supabase. ## 11. Data Deletion JetLag: Wear OS Weather & Time does not maintain a developer-side JetLag: Wear OS Weather & Time login/account keyed to you. You can delete local JetLag: Wear OS Weather & Time data by: - removing saved cities in the app; - clearing JetLag: Wear OS Weather & Time storage in Android or Wear OS system settings; - uninstalling JetLag: Wear OS Weather & Time from the phone and/or watch. Shared weather-cache entries are removed under the gateway's retention rules. Google Play purchase records and third-party provider, advertising, consent, entitlement-verification, or network logs are controlled by those services under their own policies and legal obligations. If a third-party service provides user-access/deletion mechanisms, requests involving its service must follow that provider's process. ## 12. Third-Party Services - **Supabase:** primary current-weather gateway, shared geographic weather cache, refresh coordination, and aggregate quota-protection state. - **MET Norway:** preferred weather source for supported paths. - **WeatherAPI.com:** optional fallback and legacy direct geocoding/forecast support during migration. - **OpenWeather:** optional/legacy weather and geocoding support under configured provider policy. - **Google Play / Google Play services:** distribution, updates, security, permanent one-time purchases, and Wear OS Data Layer functionality. - **Google User Messaging Platform:** advertising consent/privacy choices when applicable. - **Google Mobile Ads / AdMob:** optional user-initiated rewarded advertising on phone only. - **RevenueCat:** server-verified temporary rewarded entitlement for the optional 12-hour Pro path. JetLag: Wear OS Weather & Time does not add a separate analytics or developer crash-reporting SDK as part of this rewarded-Pro feature. ## 13. Weather Accuracy and Safety Weather information displayed in JetLag: Wear OS Weather & Time is for general informational purposes only. Forecasts and conditions are probabilistic and may not be accurate for your specific location or time. Do not use JetLag: Wear OS Weather & Time as the sole basis for safety-critical, aviation, marine, emergency, or similar decisions; consult official meteorological services and authorities. ## 14. Google Play Disclosures Before each release, the developer must make the live privacy policy, Google Play **Data Safety**, **Contains ads** declaration, app-content declarations, SDK behavior, and actual production configuration agree. Adding rewarded advertising means prior "no ads" Play declarations must not be carried forward unchanged. Repository documentation does not itself change Google Play Console, AdMob, UMP, or RevenueCat dashboard settings. ## 15. Changes This policy may be updated as features, providers, SDKs, or legal obligations change. The current version and update date should be published on JetLag: Wear OS Weather & Time's canonical privacy-policy URL before the corresponding production rollout. ## 16. Contact For privacy questions or requests, contact Quazmoz@vivaldi.net.