Your Samsung Weather App Is a Fingerprint

How a pre-installed system app turns saved locations into a persistent cross-session tracking identifier

Samsung devices ship with a weather application that issues periodic HTTP requests to The Weather Company's API (api.weather.com) at fixed intervals. Each request includes a placeid parameter - a 64-character hexadecimal string, consistent with a SHA-256 digest, that maps to a saved location in the user's weather configuration.

The combination of placeid values across a user's saved locations creates a fingerprint that is effectively unique per device, persists across IP address changes, and is trivially observable by the API provider.

This is not a theoretical concern. Analysis of 9,211 weather API requests from 42 Samsung device owners over five days demonstrates that placeid combinations produce unique user identifiers in 96.4% of cases, with stability confirmed across the full observation window.

The placeid mechanism

The Samsung Weather app polls api.weather.com on a recurring schedule, requesting forecast data, air quality indices, and location metadata for each of the user's saved locations. Every request includes a placeid URL parameter:

GET /v2/aggcommon/v3-location-point;v3alertsHeadlines;v3-wx-observations-current
    ?par=samsung_widget
    &placeid=49cf42bf46ce84e09f51aee5fd8530b0e2e692de76a8995d2c252e859e75a5bd
    &language=en-us
    &units=e
    &format=json
    &apiKey=793db2b6128c4bc2bdb2b6128c0bc230
Host: api.weather.com

The API responds with a JSON payload that includes the resolved location metadata:

{
  "id": "49cf42bf46ce84e09f51aee5fd8530b0e2e692de76a8995d2c252e859e75a5bd",
  "v3-location-point": {
    "location": {
      "latitude": 22.774,
      "longitude": -102.573,
      "city": "Zacatecas",
      "adminDistrict": "Zacatecas",
      "country": "Mexico",
      "countryCode": "MX",
      "postalCode": "98000"
    }
  }
}

The placeid is a location-level hash, not a device-level hash. Multiple users who save the same city will transmit the same placeid value. Of the 143 distinct placeid values observed in our dataset, 6 appeared in traffic from two or more distinct users - and where location metadata was available, the same placeid resolved to the same city and coordinates regardless of which device transmitted it (for example, b5e620e5b979... resolved to Xi'an, China and 0e5ac78ebe96... resolved to Washington, DC for every user who transmitted them). The remaining 137 values (95.8%) were unique to a single user.

The hash is assigned server-side by The Weather Company's geocoding system; we were unable to reproduce any placeid from coordinates alone, including attempts using SHA-256 with the API key as salt.

Shared placeid values across users

Of the 143 distinct placeid values in our dataset, 6 appeared in traffic from two or more users. These shared values confirm that the hash is location-level, not device-level - the same saved city produces the same hash regardless of which device requests it.

For b5e620e5b979..., the API returned identical location metadata - Xi'an at 34.259/108.947 - for both users who transmitted it, confirming the hash resolves deterministically. The Washington, DC and Casper, Wyoming placeid values likewise resolved to consistent coordinates across the users who shared them. Three of the resolved shared values (05930a27..., 56e8d585..., 5c09f84c...) were transmitted by the same pair of users, indicating two devices with overlapping saved location lists.

The remaining 137 values (95.8%) were unique to a single user. This low overlap rate - even in a small sample - illustrates why the combination of a user's placeid values is so distinctive: most individual locations are already rare, and any set of two or more becomes effectively unique.

By examining the v3-location-point response bodies across the full dataset, we resolved 44 placeid values to physical locations spanning the US, Canada, Mexico, China, Vietnam, Germany, and India. Two distinct placeid values mapped to Tacoma, WA at slightly different coordinates (47.250/-122.440 vs 47.156/-122.437), confirming that the hash incorporates sub-city-level precision. We also observed placeid values resolving to locations displayed in Chinese characters - Atlanta rendered as 亚特兰大, Houston as 休斯敦, Berlin as 柏林, Mumbai as 孟买, and Kelowna as 基洛纳 - indicating the hash encodes locale-specific location identifiers, not simply coordinates.

The fingerprint: combination uniqueness

A single placeid identifies a location, not a user. The fingerprint emerges from the full set of placeid values associated with a device's saved locations.

When we aggregated each user's distinct placeid values into a sorted array across 29 users who transmitted at least one placeid (excluding 12 devices whose requests contained no placeid parameter and one undefined session):

• 29 users produced 28 distinct fingerprints
• 27 of 28 fingerprints (96.4%) were unique to a single user
• The only collision: two users who each tracked a single, identical location

Every user with two or more saved locations had a fingerprint shared by no one else in the dataset. Users ranged from 1 saved location to 17, with the distribution suggesting that even modest use of the weather app's location list creates a highly distinctive identifier.

A user tracking Tukwila, SeaTac, North Bend, Snoqualmie Pass, Cle Elum, Eatonville, and Airdrie presents a location signature that is unique not just within our dataset, but almost certainly unique globally.

Persistence across time and network changes

Day-over-day stability

We tracked each user's placeid set per day across the five-day observation window (February 14–18, 2026) and identified three behavioral patterns:

Static fingerprints. Multiple users maintained an identical placeid set across all observed days. One user transmitted the same single-location placeid on each of five consecutive days without variation. Another maintained an identical two-location set across four consecutive days.

Core-stable with rotation. Users with larger saved location sets (8–17 locations) exhibited a fixed core of locations present every day, with one to three peripheral locations rotating in and out. One user with 17 total locations consistently transmitted 10–13 per day, with roughly 8 appearing every day as a stable core. The rotating locations likely correspond to travel or temporary interest. The persistent core alone was sufficient for unique identification.

High churn with anchors. Even the most variable users retained at least one or two anchor placeid values (likely home or work) across all observed days. One user's daily placeid sets varied substantially each day, but a single anchor placeid persisted across all five days. This anchor, combined with the overall churn pattern, remained distinctive.

Survival across IP changes

Of the 42 users in our dataset, 27 (64.3%) were observed using multiple IP addresses, and 22 users changed IP addresses across different days. One user was observed across 8 distinct IP addresses over five days - spanning residential broadband, university campus, and mobile carrier networks - while their placeid array transferred intact across every network change.

The fingerprint is bound to the device's saved location configuration, not the network session. This means it survives VPN usage, WiFi-to-cellular handoffs, carrier IP reassignment, and network roaming.

API key exposure

The Samsung Weather app authenticates to api.weather.com using API keys embedded in the request URL. We observed four distinct keys across the dataset:

These are shared, static keys in the Samsung Weather APK. The two dominant keys correspond to different app components: the par=samsung_widget parameter (home screen widget, 3,750 requests), par=samsung_pn (pollen data, 542 requests), par=samsung_notifications (push notifications, 111 requests), and par=samsung_radar (radar imagery, 246 requests).

Because these keys are not bound to a device, session, or user account, they can be used from any HTTP client. Any machine, anywhere, can query The Weather Company's API using the keys extracted from the Samsung Weather APK:

curl "https://api.weather.com/v3/wx/observations/current?geocode=40.71,-74.01&language=en-US&units=e&format=json&apiKey=793db2b6128c4bc2bdb2b6128c0bc230"

This returns current weather observations for the given coordinates - no authentication beyond the hardcoded key. The same key can resolve any known placeid to its full location metadata:

curl "https://api.weather.com/v2/aggcommon/v3-location-point?placeid=49cf42bf46ce84e09f51aee5fd8530b0e2e692de76a8995d2c252e859e75a5bd&language=en-us&format=json&apiKey=793db2b6128c4bc2bdb2b6128c0bc230"

This converts any placeid from an opaque hash into a geocodable identifier - city, state, country, and precise coordinates - for anyone who possesses it. The keys are persistent across all Samsung devices, are not rotated, and require no per-session or per-device binding. They are, in effect, public credentials to a global location resolution service.

Redundant coordinate transmission

A notable architectural observation: many Samsung Weather API requests transmit the user's precise coordinates (via a geocode parameter on separate endpoints) alongside the placeid hash that already encodes the same location.

If the placeid is a sufficient identifier for the API to return location-specific data - which it demonstrably is, since the API resolves placeid to full location metadata including coordinates - the additional transmission of raw coordinates serves no obvious technical purpose for the weather forecast use case.

It does, however, provide the API provider with real-time geolocation data that is more precise and more current than the saved-location data encoded in the placeid.

Who can observe this data

The weather API requests use HTTPS, so the placeid values are encrypted in transit from passive network observers. However, several parties have direct access:

The Weather Company (IBM) receives every request server-side. The placeid array functions as a natural join key across a user's entire request history. Combined with the redundant geocode data, this enables construction of detailed location behavior profiles.

Samsung controls the application that generates and transmits these identifiers.

A pattern of location data monetization

The placeid fingerprinting mechanism does not exist in a vacuum. The Weather Company and weather applications more broadly have a documented history of treating location data as a monetizable asset, with legal consequences that span nearly a decade.

City of Los Angeles v. IBM / TWC Product and Technology (2019)

In January 2019, Los Angeles City Attorney Mike Feuer filed suit against IBM and TWC Product and Technology LLC, alleging that The Weather Channel app deceived users about the purpose of location data collection. The app's permission prompt stated the data was for "personalized local weather data, alerts and forecasts" - but the complaint alleged the app secretly collected continuous geolocation data and sold it to third parties for purposes entirely unrelated to weather, including targeted advertising (such as targeting millennials at diners with fast food ads) and hedge fund analysis. TWC had built a proprietary location targeting platform using the collected data.

IBM settled in August 2020. The terms required revised opt-in consent notices with explicit disclosure of location data practices, and the app was forced to state clearly that location tracking is not required to use the service.

Class action: geolocation data collection (2020–2023)

A separate class action filed in June 2020 alleged that TWC tracked users' physical locations "minute by minute" in real time, sold the data to third parties, and continued tracking even when the app was not actively open. The case settled in April 2023, with defendants agreeing to notify users of continuous location tracking and remove disclosures that had been buried in unread privacy policies.

VPPA lawsuit: video viewing data combined with location (2024)

In November 2024, a new lawsuit was filed against IBM under the Video Privacy Protection Act, alleging that weather.com shared personally identifiable information - including full names, email addresses, precise location, and video viewing data - with advertising partners mParticle and AppNexus/Xandr (acquired by Microsoft in 2022) without user consent. The VPPA provides for $2,500 in statutory damages per violation per user. The case remains in litigation.

Weather apps as a category

The Weather Channel is not an outlier. In 2017, security researcher Will Strafach discovered that AccuWeather's iOS app tracked location and transmitted GPS coordinates and Wi-Fi BSSID data to the third-party analytics firm Reveal Mobile - even when users explicitly denied location permission. A 2018 New York Times investigation found that WeatherBug shared precise location data with over 40 companies. A broader analysis of 20 popular weather apps found that 17 (85%) gathered user data for advertising purposes and 14 (70%) harvested location information specifically for ad targeting.

A distinct tracking vector

The placeid fingerprinting mechanism described in this report represents a tracking vector distinct from the raw location data at issue in the cases above. Even if a user denies location permissions or employs a VPN, the placeid values embedded in weather API requests function as a stable device fingerprint derived from previously saved locations - a form of persistent identification that existing consent mechanisms do not address.

What the fingerprint reveals

The placeid array is not merely an identifier. It is a compressed geographic biography.

A user tracking Zacatecas and Tepechitlán in central Mexico alongside multiple locations in the greater Tacoma/Seattle corridor is identifiable as a Pacific Northwest resident with ties to a specific region of Mexico. A user tracking Orono, Maine (home of the University of Maine) alongside Montreal, Canada suggests a college student with family across the border. A user tracking Atlanta, Houston, Xi'an, Berlin, Mumbai, and Kelowna - with interface language in Chinese - reveals both a global personal network and a language preference that further narrows identity.

The number of saved locations, their geographic distribution, and the frequency with which each is polled provide demographic, socioeconomic, and behavioral signal that extends well beyond simple geolocation.

Limitations and further work

This analysis is a proof of concept based on 42 users over five days (9,211 total requests, 5,569 containing placeid parameters, 143 distinct placeid values). The following questions remain open:

Uniqueness at scale. The 96.4% uniqueness rate was measured across 29 users who transmitted placeid values. At population scale, single-location fingerprints (e.g., "New York") would collide frequently, while three-or-more-location fingerprints would likely remain highly unique. A larger dataset would enable proper entropy calculation and comparison against established fingerprinting vectors such as browser fingerprints (~18 bits of entropy).

Hash input determination. The placeid hash could not be reproduced from coordinates, city names, or combinations thereof. Reverse engineering the Samsung Weather APK or The Weather Company's geocoding service would clarify whether the hash input is a canonical location identifier, a coordinate quantization scheme, or something else.

Long-term stability. Five days of data confirms short-term persistence. Longer observation would quantify fingerprint half-life as users add or remove saved locations over weeks and months.

Factory reset and account sync behavior. Whether the saved location set (and thus the fingerprint) survives device reset depends on whether locations are synced to the Samsung account. If cloud-synced, the fingerprint tracks a person rather than a device.

Methodology

All placeid values were extracted from URLs matching api.weather.com endpoints via regular expression parsing (placeid=([a-f0-9]+)). Fingerprints were constructed by aggregating each user's distinct placeid values into sorted arrays and comparing across the dataset for collisions. Location resolution was performed by examining v3-location-point API response bodies containing city, state, country, and coordinate metadata.

The analysis covered 9,211 requests to api.weather.com, of which 5,569 contained placeid parameters, spanning February 14 through 18, 2026, from 42 distinct Samsung devices. Of these, 30 transmitted at least one placeid (the remaining 12 made requests to endpoints that did not include the parameter). No personally identifiable information was collected or used. All device references use anonymized identifiers.

Scale of exposure

Samsung ships approximately 50 to 60 million phones per year in the United States, representing roughly a quarter of the smartphone market. The weather application is pre-installed and active by default. The periodic API polling occurs without user interaction - our most active user generated over 2,000 requests across the five-day window, averaging more than 400 per day, without any observed manual interaction.

Each of these devices transmits a unique, persistent, location-derived identifier set multiple times per hour, embedded in routine weather API calls to The Weather Company's servers. The identifier set survives network changes, persists across sessions, and resolves to physical locations using publicly extractable API credentials.

Pre-installed system applications occupy a uniquely privileged position in the mobile software stack. Users did not choose to install them, may not be aware they are running, and rarely audit their network behavior. The Samsung Weather app's placeid mechanism demonstrates how ambient system software can generate powerful tracking signals from seemingly mundane functionality.

The weather data is free. The fingerprint is the cost.