PaperlayerView exact revision on arXiv

Source-linked AI summary

Decoding What iOS Location Services Send to Apple: An LLM Is an Unreliable Analyst but a Useful Toolmaker

Douglas Leith

arXiv:2610.21597v1cs.NIcs.AI

TL;DR

iOS location-service traffic contains sensitive location data, but its protobuf schemas are unpublished and reverse engineering them is slow. The paper compares direct schema reconstruction by two frontier models with a Claude-written, validated extraction tool; the direct reconstructions often contain hard-to-detect errors, while the validated tool is reliable.

  • Problem

    The contents of iOS location data sent to Apple had not been systematically decoded, and the unpublished protobuf schemas make the required reverse engineering slow and skilled.

    Source: §I · p. 1

  • Method

    The authors compare two frontier models’ schema reconstructions with a Claude-written tool validated against compiled known schemas and other evidence.

    Source: §VIII · p. 18

  • Results

    Only 3 of 17 schemas were entirely correct for each model, while their internally consistent errors were hard to detect; the validated tool was reliable and less work than hand recovery.

    Source: §VIII · p. 18

  • Takeaways & Limitations

    Reliable AI-written schema tools require ground truth that does not come from the model.

    Source: §VIII · p. 18

    The measurements use iOS 16.7.11; later releases may make different connections or send different data, which the authors could not test.

    Source: §VII · p. 18

Abstract

from arXiv · show

Reverse engineering the data formats used by mobile software is skilled and slow, and using AI to assist with it is attractive. We evaluate this for the protobuf messages that an iPhone sends to Apple's location services. Working from Apple's binaries, we use two frontier models (Claude Opus 4.8, Codex GPT Sol 5.6) to reconstruct the schemas of protobufs observed in network traffic. The great majority of the schemas contain substantial errors, and these are hard to detect because the schemas are internally consistent. Direct AI use is therefore unsuitable for forensic and privacy analysis. AI can, however, write reliable analysis tools when their output can be validated. We use Claude to write a Python tool, Extractor, that reliably recovers protobuf schemas from Apple binaries. We validate it against binaries compiled from schemas with known answers, previously published schemas, and network measurements. We demonstrate the use of Extractor to decode and analyse the location services network traffic of a jailbroken iPhone 8 (iOS 16.7.11).

I. INTRODUCTION

The paper addresses the slow, manual work required to decode iOS location-service traffic and evaluates AI for reconstructing its private protobuf schemas. It finds that direct model outputs need independent validation, while AI-written analysis tools can be checked against known schemas and binaries.

I. INTRODUCTION

  • iOS location-service traffic contains binary protobuf messages with unpublished schemas, making manual recovery from Apple’s binaries skilled, labor-intensive, and slow.The paper notes that this blocks independent scrutiny of phone traffic.Source: §I · p. 1
  • The authors report that direct AI schema recovery produced substantial, hard-to-detect errors, while a Claude-written tool could be validated and reliably recover schemas.Validation used compiled schemas with known answers, captured traffic, and previously published hand-decoded schemas.Source: §I · p. 1

II. RELATED WORK

  • Prior work covered Android apps, Apple app telemetry, or on-device location records, but the authors knew of no systematic decoded measurement of iOS location-service uploads.They also knew of no prior recovery of schemas from compiled PBCodable code checked against compiled ground truth.Source: §II · p. 2

A. Evaluation Setup

  • Two frontier models were tested blindly on 17 observed request and response protobuf seeds, with reconstructed fields graded against Extractor’s schemas.The seeds contained 7,788 fields across 1,627 message types; grading followed field-number paths from each seed and checked names and types.Source: A. Evaluation Setup · p. 2, B. Results · p. 3

B. Results

  • All 413 checked LLM–Extractor disagreements favored Extractor, and manual analysis of 50 randomly selected agreements confirmed the recovered fields.The comparison used field-by-field binary checks and an independently validated Extractor reference.Source: B. Results · p. 3

1) Analysis Of The Errors:

LLM schema errors ranged from incorrect field details to mistaken references and cut-off subtrees, yet most produced plausible decodes. Errors were concentrated and varied across seeds; captured traffic exercised only a small share of fields, allowing silent data loss and wrong values to go undetected.

1) Analysis Of The Errors:

  • A few upstream errors caused extensive cutoffs: Claude’s PDPlace.requestData placeholder cut off 697 fields, while Codex’s PDPlaceRequest field numbers cut off 1,725.Most errors still decoded without complaint, according to Table II.Source: 1) Analysis Of The Errors · p. 3, Table II · p. 3
  • Claude left 29 message fields as bytes and had 52 unresolved enum types; Codex treated 90 enum fields as integers and omitted 50, while both misnumbered enum values.Within otherwise correctly identified enums, Claude misnumbered 224 values in 11 enums and Codex misnumbered 197 in 7.Source: 1) Analysis Of The Errors · p. 3

2) Errors Tend To Concentrate:

  • Half the errors fell in message types containing about a tenth of the fields—roughly twice random concentration—yet errors touched about 200 message types.Most touched message types had a single error, and a single error could invalidate every message above it.Source: 2) Errors Tend To Concentrate · p. 4, Figure 1 · p. 4

3) Variance Across Seed Protobufs:

  • Reconstruction rates generally ranged from about 85% to 100% across seeds, but Claude got GEOTileGroup entirely wrong.Its nine uint32 fields were typed as int32, and its three sub-message types were replaced with placeholders.Source: 3) Variance Across Seed Protobufs · p. 4

4) Decoding Real Traffic:

  • 94.2% of traffic-observed fields were correct for Claude and 95.9% for Codex, versus 85.8% and 73.7% across all fields; captures exercised only 10.9% of fields.Traffic-based testing would miss almost 90% of the fields the models got wrong.Source: 4) Decoding Real Traffic · p. 4
  • Claude’s wrong message references silently lost 70% of decoded values in eight Resources payloads and left 6% as undecoded bytes; Codex’s field-number error prevented all 34 captured PDPlaceRequest messages from parsing.Other live-traffic errors could also yield wrong values without a decoder warning.Source: 4) Decoding Real Traffic · p. 4

5) Compute Cost:

Direct LLM reconstruction is costly and error-prone, while Extractor recovers schemas quickly from binaries. The section explains the sources of LLM cost and error, and how Extractor identifies protobuf fields in compiled code.

5) Compute Cost:

  • Each sub-agent incurs a fixed cost of about 0.48 million tokens for Claude and 0.28 million for Codex, plus a cost that grows roughly with the square root of field count.The fitted slopes are 0.46 for Claude and 0.51 for Codex; doubling field count raises cost by about 40%.Source: 5) Compute Cost · p. 4, Figure 3 · p. 6

1) Direct AI Analysis Is Too Unreliable:

  • Despite 12 Claude and 14 Codex seeds being at least 90% correct, substantial errors are hard to detect because the reconstructed schemas remain internally consistent.Almost 90% of wrongly recovered fields never occur in the captured traffic, and detecting errors requires an external reference or other independent evidence.Source: Figure 2 · p. 5, 1) Direct AI Analysis Is Too Unreliable · p. 5

5) Compute Cost:

  • Seed recovery costs rise almost proportionally with reachable message and enum types, at median costs of 0.82 million tokens per type for Claude and 0.52 million for Codex.The two largest seeds account for 80% of Claude’s tokens and 85% of Codex’s.Source: 5) Compute Cost · p. 5, Figure 3 · p. 6
  • Wrong type references can add unrelated subtrees, increasing recovery cost as well as lowering accuracy.For GEOWiFiQualityServiceResponse, 29 of Claude’s 51 sub-agents recovered types outside the seed.Source: 5) Compute Cost · p. 5
  • Roughly five days of wall-clock time for 17 seed protobufs contrasts with 130 seconds for Extractor to recover 1,805 message types, with output identical to the reference schemas.Extractor took 126 seconds for GeoServices and 4 seconds for CoreLocationProtobuf on one Apple M3 Max core, without model calls.Source: 5) Compute Cost · p. 5

6) Choice Of Prompt:

  • A single-agent prompt recovered only 696 of 7,788 fields correctly (8.9%), largely because it stopped before reaching most nested messages.Of the fields it reached, only 59% were correct; 6,360 fields were never recovered.Source: 6) Choice Of Prompt · p. 5

2) Fair Comparison:

  • Apple ground-truth schemas are unavailable, and creating them through Extractor development would give direct-AI agents its output rather than a fair comparison.Network measurements were reserved for subsequent validation, and their field coverage is limited.Source: 2) Fair Comparison · p. 6

IV. PROTOBUF EXTRACTOR TOOL

  • Claude wrote Extractor, a 21,000-line Python tool with a similarly sized test suite, showing that AI can produce analysis tools whose output can be validated.None of the code or tests was human-authored.Source: §IV · p. 6

B. Complications Beyond The Simple Case

Extractor handles complications in compiled protobuf code by following control flow and resolving field types and enum values through multiple code patterns. Its architecture separates general binary analysis from protobuf recovery, and its tests combine known-answer binaries with regression checks.

1) A Full Control-Flow-Graph Walk Is Needed:

  • A control-flow-graph walk from a method’s entry point ensures recovered field writes are reachable, unlike a textual scan that can misread reordered or dead code.The walk also supports later analyses that depend on which basic block contains a load.Source: 1) A Full Control-Flow-Graph Walk Is… · p. 7

2) Repeated (Message-Typed) Fields:

  • Repeated message fields store elements in untyped arrays, so Extractor infers element types from a helper method, readFrom: routing, or, more rarely, array-adding methods.The helper-method route is easy; inferring the type through readFrom: is harder but less common in practice.Source: 2) Repeated (Message-Typed) Fields · p. 7

3) Distinguishing Plain Ints From Sint/Fixed Variants:

  • To distinguish plain integers from sint or fixed-width variants, Extractor reads the writer selector in standalone binaries or follows the C call in the shared cache to inspect its instructions.A zigzag encoder, for example, shifts the value left before other operations.Source: 3) Distinguishing Plain Ints From… · p. 7

4) Enum Values: Another Lookup, In One Of Several Shapes:

  • Enum names are recovered from companion methods using jump tables, compare chains, or both; when no companion method exists, Extractor reads the class’s debugging method.Dense and sparse value ranges require different decoding patterns.Source: 4) Enum Values: Another Lookup, In One… · p. 7

C. Program Architecture

  • The codebase separates a general-purpose Mach-O and ARM64 analysis layer from the protobuf-specific recovery layer built on top of it.The general layer handles binary loading, instruction decoding, disassembly, and Objective-C metadata; the protobuf layer contains recovery logic.Source: C. Program Architecture · p. 8

D. Code Development

  • The development record includes session transcripts, commit history, and AI-authored process artefacts; the development process and reliability of AI claims are analysed separately [31].The process analysis also covers errors made during Extractor development.Source: D. Code Development · p. 8

1) Using Ground Truth From A Reverse-Engineered Template:

  • Because Apple schemas are unavailable, ground-truth tests compile binaries from authored schemas, while Apple-binary tests are regression checks rather than proof of correctness.The protobuf-specific code exercised by ground-truth tests achieved 83% statement coverage and 71% branch coverage.Source: 1) Using Ground Truth From A… · p. 8

2) Using Manually Reverse-Engineered Descriptors:

Extractor’s validation combines comparisons with previously published descriptors, checks against observed network messages, and testing across Apple operating-system binaries. These checks support its output while respecting the absence of publicly available Apple ground-truth schemas.

2) Using Manually Reverse-Engineered Descriptors:

  • Against published descriptors for iCloud, iMessage, and iOS location services, field numbers agree wherever both define a field, and Apple binaries support Extractor where types, meanings, or structures differ.Source: 2) Using Manually Reverse-Engineered… · p. 8

3) Using Network Measurements:

  • Extractor flags no uncertainty among 889 transmitted message-field pairs; 15 fields are unknown, but none is an Extractor miss.Of 889 observed pairs, 297 numeric or string fields, 98 enums, and 76 booleans had values consistent with their names or expected ranges; 313 were sub-message containers and 105 had no applicable check.Source: 3) Using Network Measurements · pp. 8–9

4) iOS And macOS Versions Tested:

F. Other Protobuf Implementations

  • Beyond Apple’s Objective-C PBCodable, Extractor recovers schemas for swift-protobuf and full C++ libprotobuf, and detects—but does not decode—three other protobuf implementations.The three detected but undecoded implementations are Google’s Objective-C GPBMessage, C++ libprotobuf-lite, and protobuf-c.Source: F. Other Protobuf Implementations · p. 9

1) Hardware And Software Used:

  • Network measurements used a jailbroken iPhone 8 running iOS 16.7.118, with traffic intercepted using mitmdump and certificate pinning bypassed within handset processes.Source: 1) Hardware And Software Used · p. 9

2) Test Protocol:

The measurements decrypt and decode traffic from a jailbroken iPhone 8 under a staged test protocol, then characterize the location-services architecture and observed connections. The study describes both the daemons’ roles and the system clients that use them.

2) Test Protocol:

  • The test protocol records traffic across three stages: location off and no Apple account, location on with an account, then VPN-routed commuter journeys with active data connectivity.The journeys were four car commutes over two days, and Maps was briefly opened to confirm reported location accuracy.Source: 2) Test Protocol · pp. 9–10

3) Decrypting HTTPS Connections:

  • The researchers used a mitmproxy intermediary to decrypt HTTPS traffic, and bypassed handset certificate-pinning checks with a jailbreak-installed injection script.Source: 3) Decrypting HTTPS Connections · p. 10

4) ios_decoder:

  • ios_decoder maps each connection’s host and URL path to a payload format and message name, then uses Extractor descriptors and the specified framing to decode protobuf bodies.It also decodes other formats, HTTP headers, and URL parameters, converting coordinates or tile numbers into the areas they denote.Source: 4) ios_decoder · p. 10

5) Measurement Data & Additional Material:

  • Protobuf bodies appear in 42% of the 1,500 observed geod and locationd connections, including location uploads, telemetry, lookups, and experiment exchanges.Most remaining connections are tile and resource downloads.Source: 4) ios_decoder · p. 10

B. Architecture Of Apple Location Services

  • geod acts as a caching gateway and logging funnel for clients, while locationd hosts location providers and can download or transmit location-related data and sensor reports.Most network connections analysed are made by geod and locationd, which both link to the GeoServices framework.Source: B. Architecture Of Apple Location… · pp. 10–11
  • Some processes bypass geod and connect directly to Apple’s geo servers: photoanalysisd sends precise-location reverse-geocoding and point-of-interest requests, while mapspushd sends no location.Source: B. Architecture Of Apple Location… · p. 11, Figure 7 · p. 11

C. Analysis Of Location Data Sent

The measurements show that location data reaches Apple through several paths, from coarse tile requests to precise locations and identifiers. Turning Location Services off limits most location data, but does not prevent Wi-Fi quality lookups from sending the connected access point’s MAC address.

C. Analysis Of Location Data Sent

1) Coarse Location:

  • Tiles downloaded by locationd reveal tile coordinates, while geod’s smallest tiles can locate the handset to about 1 km or more accurately when several are centered on it.Source: 1) Coarse Location · p. 12

2) Location Sent For geod Clients:

3) Locations Identified By Wi-Fi Or Cell Identifiers:

4) Precise Location:

5) Location Off:

  • With Location Services off, geod still made 97 Wi-Fi quality lookups carrying the connected access-point MAC address, while other observed location traffic was limited to city-level weather and broad tiles.Source: 1) Coarse Location · p. 12, 5) Location Off · p. 13

D. Apple’s “Harvesting” Of Phone Sensor Data

The study finds broad sensor-data collection and uploads, alongside telemetry and experiment assignments that persist across records. The observations are bounded by the tested drive and handset settings, and the authors did not establish what triggers each upload or whether other opt-outs exist.

D. Apple’s “Harvesting” Of Phone Sensor Data

1) Telemetry:

2) A/B Experiments:

  • The A/B assignment service returns a shared bucket identifier for four experiment namespaces, refreshed every four hours with a 30-day branch expiration.Source: 2) A/B Experiments · pp. 14–15

1) Direct Identifiers:

  • No direct identifiers were observed in geod or locationd connections, even when the user was logged in to an Apple account.Source: 1) Direct Identifiers · p. 15

2) Session Identifiers:

The observed identifiers differ in type and persistence: some connect records over days or months, while others are brief or network-derived. The comparison with Apple’s documentation finds omissions and unaddressed claims, but the study could not test several service controls or server-side handling.

2) Session Identifiers:

  • Telemetry session IDs from several processes persist for days to months, including daily-record IDs still in use 106 days after creation.Source: 2) Session Identifiers · p. 15
  • Dispatcher session IDs were shared across nearby requests but not observed for more than 10 seconds; a tripId links related uploads, while telemetry IDs can potentially link location-bearing requests across days.Source: 2) Session Identifiers · pp. 15–16

3) Network Identifiers:

  • Network identifiers link records across connections: the connected access-point MAC appeared across four endpoints over 108 days, and nearby access-point MACs recurred across uploads and fingerprint lookups.Source: 3) Network Identifiers · p. 16

G. Comparison With Apple’s Public Documentation

VI. AI USE

Direct LLM schema reconstruction was unreliable, while Claude-written Extractor was reliable when validated against independent ground truth. The conclusion reports sensitive location and telemetry data, but bounds the measurements to one older, jailbroken handset and recommends clearer disclosure and limits.

VI. AI USE

  • Claude was used to develop Extractor, while Claude Opus 4.8 and Codex GPT Sol 5.6 attempted direct schema recovery.Claude Sonnet 5 also assisted with binary-code analysis of identifier lifecycles, URL location encoding, and tile headers; the work was checked by human review or measurements.Source: §VI · p. 17

VII. LIMITATIONS

  • The tests used a jailbroken handset to decrypt HTTPS traffic; its behavior may differ from a non-jailbroken handset, though the authors saw no evidence of a difference.Source: §VII · p. 18
  • Extractor’s validation binaries use a reverse-engineered Objective-C template, sharing assumptions about Apple’s code; Apple’s true schemas remain unknown.The authors cross-check decoded messages against field names and the handset’s known position.Source: §VII · p. 18
  • Measurements used iOS 16.7.11, and later versions may make different connections or send different data, which the authors could not test.All 739 observed fields across 188 messages remained unchanged in iOS 27, though later releases added fields.Source: §VII · p. 18

VIII. CONCLUSION

  • Only 3 of 17 schemas were entirely correct for each frontier model; their internally consistent errors were hard to detect without an independent reference.By contrast, Extractor was reliable and required less work than manual recovery when ground truth did not come from the model.Source: §VIII · p. 18
  • The decoded traffic contained no direct user or handset identifier, but included precise locations, visit times, long-lived telemetry session identifiers, and an access-point MAC address sent with location off.The session identifiers persisted for at least 106 days; Apple’s documentation did not mention the session identifiers or the access-point MAC address.Source: §VIII · p. 18
  • The authors recommend documenting telemetry session identifiers and limiting their lifetime, disclosing or stopping data sent when location is off, clarifying precise-location requests, and asking before sensor-data collection.Source: §VIII · p. 18

A. Comparison With Published Protobuf Descriptors

Across location services, CloudKit, and iMessage, the iPhone binaries generally support Extractor’s recovered descriptors where published descriptors disagree. The comparisons show that traffic alone cannot resolve some schema differences, while binary code supplies evidence about types, meanings, and structure.

A. Comparison With Published Protobuf Descriptors

  • Where published descriptors differed from Extractor on field type, meaning, or structure, the iPhone binaries agreed with Extractor.The comparison covers Apple location-service descriptors and hand-written CloudKit and iMessage descriptors.Source: A. Comparison With Published Protobuf… · p. 20

1) Location Protobuf Descriptors:

  • Every captured location-service body decoded under Extractor’s descriptors without unknown fields, while published descriptors left unknown fields across every message type.Omitted fields included cell towers, Wi-Fi band and altitude scale, access-point channel and harvest count, and pbcwloc app bundle identifiers.Source: 1) Location Protobuf Descriptors · p. 20
  • For location-service type disagreements, the iPhone binaries agreed with Extractor; traffic alone could not resolve several type differences because protobuf wire encoding does not distinguish some integer types.For Wi-Fi tiles, the binary-supported quality field is a repeated message structure, unlike the published descriptor’s two integer fields; all 226 captured tiles decoded without unknown fields.Source: 1) Location Protobuf Descriptors · p. 20, Table IX · p. 21

2) CloudKit Protobuf Descriptors:

  • Of 592 shared CloudKit fields, 387 agreed in number, name, type, and label; the binary supported Extractor in all 74 declared-type disagreements.Most published types were less specific or differed in integer width or sign; one repeated-string definition could not decode the field contents.Source: 2) CloudKit Protobuf Descriptors · p. 21, Table XI · p. 22
  • Extractor recovered 184 CloudKit fields absent from rustpush, while rustpush defined 31 absent from iOS 16.7.11 binaries; 27 of those 31 appeared in iOS 27.Seven published names were unnamed placeholders that Extractor resolved, and four were spelling errors.Source: 2) CloudKit Protobuf Descriptors · p. 21

3) iMessage Protobuf Descriptors:

  • The four paired iMessage descriptor sets shared 12 fields with matching field numbers, wire types, and declared types; their differences were limited to six field names.The binary names described field roles more specifically, such as encryptedPayload rather than payload.Source: 3) iMessage Protobuf Descriptors · p. 22

B. Access Key And Maps-Auth-Token Generation

Resource and tile authentication values are derived from shared inputs rather than handset-specific identifiers. Gloria tile IDs encode Web Mercator coordinates and zoom, which are recovered through sentinel detection and Morton-code de-interleaving.

B. Access Key And Maps-Auth-Token Generation

  • The same Maps-Auth-Token values are sent by different iPhones, so neither that token nor T acts as an individual device identifier.The accessKey additionally depends on the requested resource path, current time, and a random nonce; the Maps-Auth-Token depends on map-style version.Source: B. Access Key And Maps-Auth-Token… · pp. 22–23

C. X-tilekey Header Decoding

  • A Gloria tile ID is a 64-bit unsigned integer encoding Web Mercator tile coordinates (x, y) and zoom level z.Its tile space has 2^z rows and columns; x increases west to east and y north to south.Source: C. X-tilekey Header Decoding · p. 23

1) Zoom Recovery:

  • The most-significant set bit of E identifies the sentinel at bit position 2z, enabling recovery of zoom level z.The Morton code occupies only bits below 2z, so its sentinel is the highest set bit.Source: 1) Zoom Recovery · p. 23

2) Sentinel Removal:

  • Once z is known, XOR-clearing the sentinel bit recovers the raw Morton code without masking its lower bits.The Morton code has no information at or above position 2z.Source: 2) Sentinel Removal · p. 23

3) Morton Code De-Interleaving:

  • The Morton code interleaves x and y bits, and inverse compact operations gather the even- and odd-positioned bits into the coordinates.The spread operation places each bit of a 32-bit integer in an even-indexed position.Source: 3) Morton Code De-Interleaving · p. 23

4) The Compact Operation:

The compact operation progressively packs selected Morton-code bits into 32-bit coordinates. The decoded result is a Web Mercator tile column, row, and zoom level.

4) The Compact Operation:

  • Compact isolates the target bits, then five mask-and-fold stages progressively pack them into the low 32 bits.The final mask discards the upper 32 bits; even-indexed bits yield x, while shifted odd-indexed bits yield y.Source: 4) The Compact Operation · p. 23

5) Result:

  • The decoded tile coordinates are x, y, and z: zoom level z defines the tile grid, x is the west-to-east column, and y the north-to-south row.Both x and y range from 0 to 2^z.Source: 5) Result · p. 23

D. Connections Made By geod And locationd

The authors compare decoded /hvr/v3/use records with earlier claims about that endpoint and show examples of location-related traffic. The supplied passages also identify the tile sizes downloaded by locationd and the transmissions illustrated in further figures.

E. Third-Party Claims About /hvr/v3/use

  • Decoded /hvr/v3/use records explain most observations in a technical report, but the study did not observe a home location.The report's “open apps” are triggering app or daemon identifiers, its IP addresses and ports identify Apple servers, and apparently encrypted ARPC bodies are LZ4-compressed; homeCountryCode and homeMetroRegion were UNKNOWN for the test user.Source: E. Third-Party Claims About /hvr/v3/use · p. 24

G. Further Figures

  • Figure 12 depicts smaller tiles, about 3–11 km across, downloaded by locationd, with a star marking the handset location.The accompanying text identifies these as the smaller tiles discussed in Section V-C.Source: Figure 12 · p. 24, G. Further Figures · p. 24
  • The further-figures examples show a cell tower identifier sent to wloc and a geod real-time traffic probe carrying the same GPS fixes as the /pds/pd upload.Figure 14 depicts the GPS locations in a serialized CoreLocationProtobuf message.Source: G. Further Figures · p. 24, Figure 13 · p. 24

I. HTTP Headers And Query Parameters In geod Connections

The supplied material catalogs geod query parameters and non-standard headers but gives few table contents. It identifies several global or regional location-service datasets and describes examples of traffic to location-service endpoints.

I. HTTP Headers And Query Parameters In geod Connections

  • The listed geod and locationd connections include examples of GPS locations sent to /hvr/v2/rtloc and telemetry sent to /hvr/v3/use.The /hvr/v2/rtloc example carries serialized CoreLocationProtobuf data; separate examples show an A/B experiment endpoint and a cell-tower identifier sent to wloc.Source: Figure 14 · p. 25, Figure 16 · p. 25, Figure 15 · p. 25
  • Global cellular tile downloads use a single tile path covering all coordinates, so the path itself conveys no location, while the tiles list cellular identifiers and corresponding coordinates.The listed tile types cover GSM, CDMA, LTE, and 5G NR cell identifiers.Source: §I · p. 27
  • A global raster map records RF signal environment at 0.05° resolution, approximately 5.5 km per cell at the equator.The signal environment categories include Rural, Urban, DenseUrban, DenseUrbanCanyon, Marine, and Foliage.Source: §I · p. 27
  • Indoor positioning venue availability is represented by bounding boxes for regions with indoor map tiles, while availability indexes mark geographic tiles with server-side data.The indexes cover DEM, HRSE, and barometric-pressure tile sets.Source: §I · p. 27
  • The Bluetooth hands-free vehicle allowlist includes device-name patterns and MAC-address prefixes in a gzip plist.A separate XML plist contains only version integer 15.Source: §I · p. 27
  • The report includes tables of HTTP query parameters and non-standard headers observed in geod traffic, but the supplied passages do not state their individual entries.The captions identify Table XVI as query parameters and Table XVII as non-standard headers, excluding standard headers.Source: Table XVI · p. 28, Table XVII · p. 28

Related papers

Loading 2610.21597v1…