RTBlintAlpha

Blog · Privacy

57 ad SDKs ship precise location into ad requests without manifest disclosure. OpenRTB device.geo inherits that gap.

· RTBlint

Mobile programmatic buyers treat device.geo as a field the exchange or SSP assembled from IP, registration, or an explicit consent signal. That mental model breaks the moment you remember where the bid request is born: inside an app, on a device, often inside an ad SDK that packaged the auction payload before any intermediary saw it. A September 2026 source-code audit of 698 ad and data-broker SDKs reports that 57 contain code transmitting precise geolocation without declaring that collection in their bundled privacy manifest, impacting up to 88,787 apps from 25,564 developers, and that more than 60 SDKs are built to broadcast precise location directly into the advertising bidstream without detected disclosure in policy or manifest files.

The store label is not in the bid request

Apple and Google both hold app developers responsible for the SDKs they integrate. Apple expects privacy nutrition labels assembled from each SDK's self-declared privacy manifest; Google points developers to its public SDK Index for data-safety guidance when filling out Play Store labels. Neither store verifies accuracy. Google's own data safety documentation states review is not designed to verify completeness of developer declarations, and Apple's labels carry an explicit disclaimer that Apple has not verified the information.

None of that metadata travels in OpenRTB. What travels is whatever the SDK and its mediation stack put in the JSON: app.bundle, device.ifa, device.geo.lat, device.geo.lon, and the rest. A buyer filtering on bundle allowlists or MRC invalid-traffic signals is downstream of SDK behavior they cannot see from the request alone. Independent academic work on 158 widely used Android SDKs found more than 30 percent publish no privacy policy at all, and among those that do, 37 percent collect more data than disclosed (Meng et al., 2024). The new audit scales that observation across 698 ad-facing SDKs and names a specific failure mode: precise location leaving the device in network-bound ad payloads.

The regulatory frame is not hypothetical. The FTC has pursued enforcement across the SDK-to-bidstream location pipeline against SDK operators and downstream brokers, alleging disclosure gaps and harvesting from real-time ad auctions as unfair practices. The audit separates two risk dimensions: App Store terms-of-service risk when code behavior diverges from the SDK's bundled manifest (57 SDKs, up to 88,787 apps), and FTC Section 5 risk when code diverges from the public privacy policy or no policy exists (33 SDKs combining undisclosed transmission and absent policies, up to 10,613 apps from 4,873 developers). Those are publisher-side liability buckets. For buyers, the same divergence means coordinates in the auction may not match any consent story the app displayed at install time.

What the audit actually measured

The index is built from three layers per SDK: static code analysis (does the SDK read location APIs or accept location through its own surface and package it into ad requests or event uploads), manifest inspection (does PrivacyInfo.xcprivacy or AndroidManifest.xml declare precise location collection), and privacy policy review (does a policy exist and does it disclose location). SDKs that collect flexible location, meaning precise when available and coarse otherwise, are counted as precise collectors for the rating.

The headline population is 698 ad SDKs and data brokers, not 698 apps. App impact numbers are estimates of how many published apps integrate flagged SDK versions. The 600+ billion download figure in the release subhead is cumulative reach across that app set, not a quarterly bidstream volume. Treat app counts as exposure estimates, not auction counts.

Ratings reflect the auditor's opinion from automated analysis as of May 2026 policy snapshots and May 21, 2026 code review; they are not legal determinations. That caveat matters for buyers too: you are not getting a compliance certificate in the bid, you are getting coordinates that may have been assembled by code the publisher never independently verified against manifest or policy.

Where precise location enters the auction

On mobile and in-app video, the first programmatic hop is usually an SDK ad request to a mediation layer or exchange endpoint. Location can arrive three ways buyers later see as indistinguishable in logs: the SDK reads GPS or fused location and writes device.geo, the host app passes coordinates into the SDK API surface and the SDK forwards them, or a downstream enricher infers geo from IP after the SDK fires the request. The audit focuses on the first two: code paths that package precise location into ad-bound payloads without disclosure.

OpenRTB does not include a field for SDK manifest accuracy or privacy policy URL validation at bid time. A syntactically valid request from a real Android phone can include high-precision coordinates whether or not the Play Store data safety form mentioned location. Buyers who block lat/lon below a precision threshold reduce exposure but do not learn which SDK sourced the signal or whether the publisher's label claimed collection.

{
  "id": "req-9f2a",
  "app": {
    "bundle": "com.example.weather.free",
    "name": "Example Weather",
    "storeurl": "https://play.google.com/store/apps/details?id=com.example.weather.free"
  },
  "device": {
    "ua": "Mozilla/5.0 (Linux; Android 14; …)",
    "devicetype": 4,
    "ifa": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "geo": {
      "lat": 37.7749,
      "lon": -122.4194,
      "type": 1,
      "accuracy": 5
    }
  },
  "imp": [{ "id": "1", "banner": { "w": 320, "h": 50 } }]
}

Nothing in that skeleton proves undisclosed collection. Everything looks like a normal in-app banner call from a weather utility. If the integrating ad SDK transmits precise location without declaring it in manifest or policy, the buyer's geo bid modifier, frequency cap, and consent audit trail inherit the gap. SSPs that operate their own ad SDKs face a compounded version of the same problem: a critical SDK rating is also a statement about supply the exchange may be sourcing from its own embedded code paths.

Google's public SDK Index shows Android permissions an SDK requests but, as independent researchers note, does not close the loop on which data categories are actually collected or whether declarations match behavior (Khandelwal et al., USENIX Security 2024). Relying on permission lists or self-attested checkmarks at integration time does not substitute for code-level verification before the SDK ever joins the mediation waterfall that produces your bidstream rows.

What buyers and sellers can do

Exchange-side validation cannot fix upstream SDK omission. These checks reduce how often undisclosed signals become priced impressions without pretending to detect fraud intent.

  • Strip or coarse-grain device.geo on mobile app traffic unless a documented consent path ties the impression to declared collection; log when precision exceeds your policy threshold.
  • Segment reporting by app.bundle and seller, not only campaign line, so geo anomalies trace back to integrating apps when post-auction review flags a cluster.
  • Require publishers to maintain an SDK inventory with manifest snapshots and policy URLs for each ad SDK in the waterfall; refresh when SDK versions change.
  • Treat first-party SDK requests differently from resold SDK traffic in supply path review; an SSP-owned SDK with undisclosed location code is both a compliance risk and a supply quality signal.
  • When investigating a bundle, paste raw requests into RTBlint validate to confirm OpenRTB shape, required app and device fields, and inconsistencies between declared device type and geo precision before you adjust blocklists or deal floors.

Field validation catches malformed IDs and impossible device blocks. It does not read SDK bytecode. The honest workflow pairs bid-request lint with publisher SDK due diligence, not one or the other.

The honest limit

Not every high-precision device.geo is misconduct. Many apps legitimately disclose location and use it for weather, maps, or local offers. The argument is narrower: when self-attestation is the only gate, undisclosed SDK behavior scales across tens of thousands of apps and shows up in the same OpenRTB fields your bidder already trusts.

CTV and SSAI paths have different location stories; this audit is mobile SDK source code, not living-room IP-only defaults. The bidstream lesson still generalizes: the request is assembled below the exchange, and labels visible in app stores do not ride along to help you reconcile what you bought.

Sources

Field names refer to OpenRTB as published by IAB Tech Lab. SDK counts and app exposure figures come from the September 9, 2026 audit release cited below. RTBlint is independent and not affiliated with the auditor, Apple, Google, the FTC, or IAB Tech Lab.