WristExposure: UV Index & Cold Privacy Policy

# WristExposure: UV Index & Cold Privacy Policy Last updated: September 25, 2026 WristExposure provides environmental UV, temperature, wind, outdoor-context, and local exposure-session information on Wear OS. It is not a medical device and does not diagnose or predict sunburn, frostbite, hypothermia, or any medical condition. Weather data can be incomplete, delayed, unavailable, or inaccurate and must not be the sole basis for decisions involving personal safety. ## Approximate location WristExposure requests `ACCESS_COARSE_LOCATION` only when the user asks for local conditions. It does not request precise location or background location. For the production release path, a user-initiated weather check sends the approximate coordinates supplied by Android over HTTPS to the WristExposure weather gateway hosted on Supabase. The Edge Function validates the request, reduces latitude/longitude to two decimal places before shared caching and upstream weather requests, and does not log the raw coordinate pair. The production gateway currently obtains weather from WeatherAPI.com with MET Norway as its provider fallback. The provider that supplied the returned weather remains part of the response provenance shown by WristExposure. If the gateway itself is unavailable, the signed release can still fall back directly to the keyless MET Norway path. Release builds deliberately package empty OpenWeather and WeatherAPI.com direct-provider API-key fields, so keyed direct fallback is not a production credential path. Development/debug builds may use locally configured direct-provider keys. The Edge Function necessarily processes the Android-supplied approximate coordinates long enough to validate and normalize the request. Its shared weather cache stores only the two-decimal location bucket, weather payload/provenance, and cache timestamps. Cache entries are not associated with a WristExposure account, device identifier, advertising identifier, or user profile. An hourly cleanup job removes weather-cache rows after they have been beyond their stale-retention deadline for an additional 24 hours. WristExposure's on-device normalized weather cache does not persist exact request coordinates, a readable rounded coordinate token, or location accuracy. Its lookup key uses a one-way SHA-256-derived value calculated from a rounded coarse-location token, and the persisted normalized snapshot contains environmental values, provider provenance, and timestamps. Outdoor-context code may retain one previous coarse coordinate in process memory to calculate displacement between user-initiated checks. That coordinate is not persisted by the outdoor-context layer and resets on process death. The direct MET Norway fallback uses a separate bounded OkHttp disk cache. Before a MET request URL can enter that cache, WristExposure reduces latitude/longitude to two decimal places. The cache can therefore retain a request URL containing kilometre-scale coordinates until cache eviction, Android cache cleanup, app-data clearing, or uninstall. Third-party handling and retention of weather-provider requests is governed by the applicable provider terms and privacy policies. ## Watch sensor signals and manual corrections While the app is foreground-started, WristExposure may read supported on-device ambient-light, accelerometer, and low-latency off-body signals for conservative outdoor-context inference. Raw sensor observations stay on the device and are not sent to the weather gateway/providers or stored as a raw history. Ambient-light lux is not UV radiation and is never converted into or labeled as a UV measurement. WristExposure does not treat watch temperature as body/core temperature. Outdoor context is an estimate. Even if the internal classifier reaches high confidence, the user-facing app does not claim that watch context proves the wearer is outdoors. `I'm outside` and `I'm inside` are local classifier corrections. They are not transmitted to the weather gateway or provider and are not stored as a correction history. To prevent an explicit `I'm inside` action from being lost if Android kills the process before foreground classifier collection resumes, WristExposure stores one small app-private pending-correction recovery record containing only issue timestamps and the bounded suppression duration. It expires with the original suppression window and is superseded by a later `I'm outside` correction. Persistent ordinary sensor-flow failures are converted to unavailable-source state and retried only while the foreground classifier is active, using capped backoff. This does not add background sensing. ## Exposure sessions and alerts WristExposure can maintain an aggregate exposure-session checkpoint so a foreground session does not silently gain time after process death. The checkpoint contains aggregate session state/timing metadata, not a raw sensor history or location history. User-enabled UV/cold alerts are evaluated locally from accepted environmental state, freshness, outdoor context, and session state. Notification arbitration persists only the preferences and deduplication/cooldown state needed to avoid replay. Enabling alerts does not create continuous GPS, a foreground service, or background weather polling. On Android 13 and newer, `POST_NOTIFICATIONS` is requested only after the user explicitly enables alerts. `VIBRATE` is used for brief notification-channel haptics and does not collect data. ## Tile and complication WristExposure includes a Wear OS Tile and a watch-face complication data source. Rendering them does not request location, start a weather refresh, start continuous sensors, or bind to Google Play Billing. Because Wear OS can request these surfaces while the main Activity is not alive, WristExposure stores one small app-private no-backup presentation snapshot. It contains accepted provider/fetch timestamps, conservative freshness state, UV when available, normalized air temperature and wind, evaluator-produced UV/cold severity, and evaluator version identifiers. The snapshot does not contain location coordinates/tokens, raw sensor samples/history, API keys, outdoor-classifier confidence/history, billing tokens, or a persisted monotonic origin. Corrupt, unsupported, or obsolete snapshot data is rejected rather than converted to a reassuring default. ## Samsung enhanced-temperature foundation The current production release does **not** bundle or operate the Samsung Health Sensor SDK, request a Samsung/body/health sensor permission, or collect wrist-skin/around-watch temperature measurements. The source tree contains a vendor-neutral optional contract and temperature-trend foundation for future enhanced sensing. Its production fallback reports the integration unavailable and starts no measurement. If a concrete Samsung adapter is later introduced, this policy, permissions documentation, Play Data Safety answers, and store claims must be updated before release. ## Developer calibration builds Internal/debug builds can enable a bounded local aggregate calibration journal for evaluating the outdoor classifier on real watches. It is enabled only when `BuildConfig.DEBUG` is true; production release builds use `OutdoorDiagnosticsSink.NoOp`. The debug journal excludes raw sensor sample streams, latitude/longitude, weather response bodies, API keys, account identifiers, and user-entered notes. It is app-private under `noBackupFilesDir`, size-bounded, and has no automatic upload path. ## Google Play Billing / Pro entitlement WristExposure bundles the Google Play Billing Library for its one-time Pro entitlement. Google Play handles the purchase transaction and payment instrument. WristExposure does not receive or store card, bank-account, or other payment-instrument details. The app receives Google Play product/purchase state required to launch, verify, restore, and acknowledge the entitlement. Purchase tokens are used transiently with Google Play for acknowledgement and are not persisted by WristExposure. The app persists only a local boolean representing the last-known owned Pro entitlement so an already verified purchase can remain usable when temporarily offline. A later successful Google Play ownership query is authoritative and can remove that cached entitlement after refund or revocation. Billing is started from the foreground app UI; a Tile or complication process launch does not connect to Google Play merely to render a surface. ## Capability information The app may check whether hardware sensors, onboard GPS, and Health Services APIs are available. Capability discovery does not mean WristExposure reads all supported health/activity data. The current runtime does not request Activity Recognition or body-sensor permissions and does not subscribe to Health Services activity data. Health Services is optional. Client creation/capability failures are treated as unavailable capability state rather than a startup failure. ## Network security and logging Weather traffic uses HTTPS and Android cleartext traffic is disabled. Production weather-provider secrets are server-side Edge Function secrets. Release builds intentionally set direct OpenWeather and WeatherAPI.com BuildConfig key fields to empty strings, preventing those provider credentials from being recovered from the Play artifact. The Supabase publishable key embedded in the client is a public client credential, not a provider/database secret; database access remains server-side and service-key protected. The production Android weather client does not install an HTTP logging interceptor. API keys, precise request URLs, and coordinates are therefore not emitted by WristExposure network logging. The gateway logs only non-coordinate operational events and a short hash derived from the normalized cache bucket. The Supabase weather cache tables use Row Level Security and revoke direct `anon`/`authenticated` table access. Edge Function database operations use server credentials. Request-size limits, validation, shared refresh leases, stale serving, timeouts, and rate budgets constrain gateway abuse and provider fan-out. ## Analytics, advertising, accounts, and server-side profiles The current production app includes no analytics SDK, advertising SDK, advertising identifier integration, WristExposure account system, or WristExposure authentication flow. The shared weather gateway is a backend service, but it does not create a per-user profile. Its weather cache is keyed by a normalized geographic bucket and is shared across requests for that bucket. ## Local storage and deletion WristExposure stores small app-private caches/checkpoints needed for weather freshness, exposure/session continuity, alert replay prevention, onboarding, manual-correction recovery, Tile/complication presentation, and the last-known Pro entitlement boolean described above. Raw ambient-light, motion, and off-body samples are not persisted. Clearing app data or uninstalling removes WristExposure's local app data and caches. It does not selectively delete a shared Supabase weather-cache bucket because that row is not keyed to a user/device/account; server cache rows age out automatically under the backend cleanup policy. There is no WristExposure account or server-side user profile to delete. If account-linked storage is later introduced, an appropriate user deletion mechanism and updated policy are required before release. ## Weather sources and safety information The app includes a `Weather data & safety` surface identifying weather sources, provenance, attribution/terms links, and limitations. Missing or malformed UV remains unavailable rather than being converted to zero. ## Changes This policy must be updated whenever data collection, backend/provider routing, third-party SDKs, permissions, background behavior, analytics, advertising, billing, accounts, or persistence changes. ## Contact For privacy questions, contact Quazmoz@vivaldi.net.