> For the complete documentation index, see [llms.txt](https://docs.hbwrapper.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hbwrapper.com/privacy.md). # Privacy Disclaimer **Version:** 1.0 — July 2026 **Applies to:** the header-bidding wrapper built from this repository (a customized Prebid.js build, "the Wrapper") **Audience:** companies deploying the Wrapper on their websites ("Deploying Companies") and their legal/privacy teams > **Purpose of this document.** This document is a privacy disclaimer and technical disclosure: an inventory of the device storage and network requests performed by the Wrapper itself, with a legal categorization of each. It exists so that Deploying Companies can meet their own obligations under the GDPR, the ePrivacy Directive, and US state privacy laws. It is technical documentation, **not legal advice** — see the Disclaimer at the end of this document. *** ## 1. Roles and allocation of responsibility **The Deploying Company is the data controller** (GDPR Art. 4(7)) for all personal data processed on its websites through the Wrapper. It decides to use the Wrapper, selects and configures the demand partners, identity modules, RTD modules, and tags, hosts the analytics backend, and operates the Consent Management Platform (CMP). **The Wrapper is software executing the Deploying Company's configuration.** It does not process data for its own purposes. Data collected by the Wrapper's analytics module is transmitted exclusively to an endpoint operated by (or for) each Deploying Company; datasets are not pooled or shared across companies, and no cross-site profiles are built. For any data processed on behalf of a Deploying Company, that company's own privacy policy governs how the data is used. **Third parties configured into the Wrapper — bidders/demand partners, user ID modules, RTD modules, user-sync endpoints, and page tags (e.g., Google Publisher Tag, Google Tag Manager, Microsoft Clarity) — are independent controllers** of the processing they perform once they receive data or execute on the page. Their processing is governed by their own privacy policies and, where applicable, by the IAB Europe Transparency & Consent Framework (TCF) responsibility allocation. See Section 5. **Caveat that Deploying Companies must understand:** under CJEU case law (*Fashion ID*, C-40/17; *Wirtschaftsakademie*, C-210/16), a website operator that embeds third-party technology is a **joint controller for the collection and transmission phase** of that third party's processing. Responsibility for what third parties do with data afterwards lies with those third parties, but the decision to send them data in the first place belongs to the Deploying Company. This is why consent gating via the CMP (Section 6) is the load-bearing safeguard. *** ## 2. Technical inventory — device storage used by the Wrapper itself All keys are namespaced with the per-site global variable (`` below), so every identifier is **first-party and scoped to the individual website**. None of these values are shared across sites or with third parties, except as expressly noted. | Key | Type | Lifetime | Contents & purpose | Legal categorization | | ------------------------------------------- | -------------------------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | `__sid` | Cookie (SameSite=Lax) + sessionStorage | 60 minutes | Random UUID session identifier. Correlates events within a browsing session for monitoring, debugging, and detection of anomalous behavior (e.g., abusive click/reload patterns). | Security / fraud prevention / debugging — TCF **Special Purpose 1**; strictly-necessary exemption claimed under ePrivacy Art. 5(3). | | `__uid` | Cookie (SameSite=Lax) | 30 days | Random UUID browser identifier. Used to recognize recurrence of technical faults and to identify similar behavior patterns originating from apparently different devices/browsers that may be malicious (spoofing, invalid traffic). Consumed only by the per-company analytics module; **never** added to bid requests. | Security monitoring / troubleshooting — TCF **Special Purpose 1**. See risk note in Section 7.1. | | `__sesdepth` | sessionStorage | Session | Integer page-depth counter (pages viewed this session). Used as reporting/auction context. | Strictly necessary auction context / measurement support. | | `__anep` | localStorage | Until cleared / failover reset | Which analytics endpoint URL is in use (failover selection). No personal data. | Strictly necessary technical setting. | | `__trackbids` | localStorage | 24 h (self-expiring timestamp) | Debug flag enabling verbose bid logging. No personal data. | Debugging — Special Purpose 1. | | `__hbWrapperFpd` | localStorage | Until overwritten | Cached first-party context from the CDN edge or fallback lookup: coarse IP-derived geolocation (country) and the IP observed at lookup time. | Technical cache supporting geo context & troubleshooting. See risk note in Section 7.2. | | `__userInfo` | localStorage | Until overwritten | Derived user-info cache (IP at lookup time, country). Same source and purpose as above. | Same as above. | | `__bc__`, `__bc_idx_` | localStorage | Expiring; evicted on quota | Cached winning/unused bid objects (ad markup, price metadata, ad unit) for re-use across pages. Contains **no user identifiers**. | Strictly necessary for the ad-delivery function requested by the publisher. | | `__console` | localStorage | 1 h (self-expiring timestamp) | Enables the on-page debugging console for operators. No personal data. | Debugging tool state. | The Wrapper does **not** use IndexedDB, does not read or write third-party cookies, and does not employ fingerprinting techniques to generate identifiers (identifiers are random UUIDs; device signals read for bot detection are described in Section 3.1). *** ## 3. Technical inventory — network requests made by the Wrapper itself ### 3.1 Per-company analytics endpoint Configured per Deploying Company; operated by or for that company (data hosted per company, not pooled). **Data transmitted:** page URL and referrer (truncated to 1024 chars), site/environment identifiers, pageview ID, session ID (`__sid`), browser ID (`__uid`), browser and device characteristics (user agent, screen/device class), network quality (rounded downlink, RTT), coarse IP-derived geolocation received from the CDN edge (country, city, region, postal code), Core Web Vitals metrics, A/B variant assignments, auction lifecycle events (ad units, bidders, bid prices, latencies, errors), and bot-detection signals (`navigator.webdriver` flag, absence of language list, user-agent anomalies). The visitor's IP address is inherently visible to the receiving server at the transport level; the Wrapper does not add it to the payload. **Purposes:** monitoring, performance measurement, debugging, security/invalid-traffic analysis. **Not used for:** cross-site profiling, ad targeting, audience building, or sale/sharing. **Legal categorization:** first-party measurement and security telemetry processed under the Deploying Company's controllership; GDPR legal basis legitimate interests (Art. 6(1)(f)) for security, fraud prevention, debugging and aggregate performance analytics. Where the endpoint is hosted by a party other than the Deploying Company, that party acts as a processor (Art. 28) and a DPA is required. ### 3.2 CDN (Cloudflare) — bundle delivery and edge context The Wrapper bundle is served from a CDN (Cloudflare). The CDN edge may derive coarse geolocation from the connecting IP (standard CDN functionality) and inject it as `window.hbWrapperFpd`, including an A/B bucket assignment. When the CDN edge did not provide this context (`window.hbWrapperFpd` absent), the Wrapper calls `https://cloudflare.com/cdn-cgi/trace` as a fallback, which returns the visitor's IP and country code; these are cached locally (Section 2). In both cases Cloudflare receives standard HTTP requests (IP, user agent) as a technical consequence of content delivery. **The Deploying Company should verify Cloudflare's privacy policy and terms** and list Cloudflare as a recipient/processor in its own disclosures where applicable. ### 3.3 Data injected into bid requests (optional `firstPartyData` feature) When a Deploying Company enables `wrapper.firstPartyData` in its configuration, the Wrapper merges the following into the OpenRTB (`ortb2`) object sent to **all configured bidders**: * **Coarse IP-derived geolocation** — country, city, region, postal code, IP-lookup lat/lon, UTC offset. This is derived at the CDN edge from the IP address; it is not GPS and does not meet the TCF "precise geolocation" threshold (< 500 m). * **IP address (`device.ip`/`device.ipv6`)** — passed through for troubleshooting and malware/invalid-traffic detection by the receiving networks. The Wrapper does not itself store this value beyond the local caches in Section 2. Note that bidders contacted client-side observe the visitor's IP at the HTTP layer regardless. * **Context signals** — device class (mobile flag), A/B bucket, and similar non-identifying auction context. The Wrapper **never** injects its own `__sid`/`__uid` identifiers into bid requests. Third-party user IDs (EIDs) are handled exclusively by Prebid's consent-gated user ID modules configured by the Deploying Company. **Legal categorization:** transmission of personal data (IP, coarse geo) to configured demand partners, initiated on the Deploying Company's instruction; purposes limited to ad delivery, troubleshooting, and fraud/malware detection (TCF Special Purpose 1 and applicable purposes signaled via the TC string). The Deploying Company is responsible for enabling this feature only where its CMP establishes an adequate lawful basis for the transmission. ### 3.4 What the Wrapper does not request The Wrapper itself makes no other network calls. All further requests observed on a page — bid requests, user syncs (pixels/iframes), identity resolution calls, RTD lookups, ad creatives, GPT/GTM/Clarity and other tags — belong to third parties or to company-configured integrations (Section 5). *** ## 4. Consent handling behavior The Wrapper detects the page CMP automatically (`__tcfapi` for TCF/GDPR, `__gpp` for GPP/US state laws) at initialization and configures Prebid's consent management accordingly, **before** user-sync and user ID module initialization, so that: * when the CMP provides a consent string (TC string / GPP string), the Wrapper **passes it to the third parties** it contacts — bidders, user ID modules, and user-sync endpoints — with each request; * when no CMP is present, or the CMP does not provide a consent string, requests are sent without one, and **each third party decides how to process such a request** under its own legal obligations; * **user syncs** are deferred until after the auction and triggered only per configuration, with the same consent-string pass-through; * for GDPR, TCF v2 signals are re-checked at each auction; for the US, GPP sections (including US National/state strings) are passed through to bidders. If no CMP is present on the page, the Wrapper cannot obtain a consent string. **Deploying a CMP — and ensuring it functions correctly — is the Deploying Company's responsibility** wherever consent-based processing occurs (EU/EEA/UK, and opt-out signal handling in US states). The Wrapper's own storage (Section 2) is initialized at load time under the security/debugging categorization stated there, independent of CMP state. See Section 7.1. *** ## 5. Third parties — independent responsibility This section covers all endpoints and scripts that the Wrapper contacts or loads **because the Deploying Company configured them**: demand partners / bidders (client- and server-side), user ID / identity modules, RTD modules, user-sync endpoints, and page tags the Wrapper can inject when configured (Google Publisher Tag, Google Tag Manager, Microsoft Clarity, Amazon TAM/A9, and similar). 1. **Independent controllership.** Each such third party determines its own purposes and means for the data it receives (bid requests, sync pixels, script execution context) and is an independent controller under GDPR Art. 4(7), and/or a "third party"/"business" under CCPA/CPRA. Its processing is governed by its own privacy policy and — for TCF-registered vendors — by its Global Vendor List registration. 2. **Consent transmission.** The Wrapper transmits the TC string / GPP string with bid requests and syncs. Acting on those signals (including honoring refusals and opt-outs) is each vendor's own legal obligation under TCF Policies and applicable law. 3. **Due diligence.** The Deploying Company selects these vendors in its configuration and must perform its own due diligence: verify GVL registration, review vendor privacy policies, ensure vendor disclosure in its CMP and cookie notice, and maintain contracts where required. No representation or warranty is made as to any third party's practices; the authoritative source is each vendor's own current legal documentation. 4. **Storage by third parties.** Cookies and storage set by bid adapters, ID systems, sync pixels, or tags (including any storage written by adapter code bundled in this repository on behalf of a vendor) belong to the respective vendor's controllership and must appear in the Deploying Company's cookie notice under that vendor's name. 5. **Custom scripts.** Any custom script deployed or configured by the Deploying Company that loads third-party assets (tags, pixels, libraries, creatives, or any other external resource) is the Deploying Company's sole responsibility, including compliance of those assets and their providers with applicable legislation. *** ## 6. Obligations checklist for Deploying Companies 1. Operate a compliant **CMP** (TCF-registered for EU/EEA traffic; GPP-capable for US traffic) on every page running the Wrapper. 2. List the Wrapper's first-party storage (Section 2) in your **cookie notice**, under "strictly necessary / security" and "performance" as categorized, including the 30-day `__uid` with its purpose and duration. 3. List your configured **vendors** (bidders, ID modules, RTD providers, tags) in the CMP and privacy policy; keep the list current with your wrapper configuration. 4. Ensure a **DPA (Art. 28)** exists with whoever hosts your analytics endpoint and CDN, if not you. 5. Define **retention** for your analytics dataset (recommendation: define a fixed window aligned with your troubleshooting cycle, e.g., 13 months maximum, and document it). 6. Route **data subject requests** concerning wrapper data to your own DPO/privacy contact; the identifiers are yours (first-party), so access/erasure is executed in your analytics store and by cookie deletion. 7. If you enable `wrapper.firstPartyData`, confirm your CMP disclosures cover transmission of IP and coarse geolocation to your configured demand partners. 8. Conduct a **legitimate interests assessment (LIA)** — and where appropriate a DPIA — for the security/debugging telemetry, referencing this document's inventory. *** ## 7. Residual risk notes (read before relying on this document) ### 7.1 Ungated first-party identifiers The `__sid` (60 min) and `__uid` (30 days) identifiers are written before CMP interaction, on the categorization that they are strictly necessary for security monitoring, fraud/anomaly detection, and troubleshooting (ePrivacy Art. 5(3) exemption; TCF Special Purpose 1). This position is **defensible but not risk-free**: EU regulators construe the strictly-necessary exemption narrowly (WP29 Opinion 04/2012; EDPB Guidelines 2/2023), and a 30-day identifier used for security monitoring where systematic invalid-traffic analysis is not continuously operated may be challenged, in particular by the French CNIL and German DSK. Mitigations available to Deploying Companies: (a) operate and document an actual recurring security/IVT analysis over this data; (b) alternatively, configure or request consent-gating of the 30-day identifier and rely on the session identifier alone for non-consenting users. The 30-day duration reflects the operator's documented need for month-on-month troubleshooting analysis. ### 7.2 IP addresses in localStorage caches The `__hbWrapperFpd` and `__userInfo` caches persist the IP observed at lookup time until overwritten. IP addresses are personal data (*Breyer*, C-582/14). Recommendation: treat these caches as part of the security/troubleshooting categorization above, and prefer country-only caching in a future revision. *** ## 8. Disclaimer — not legal advice This document is a technical disclosure and privacy disclaimer provided to Deploying Companies for information purposes only. It does not constitute legal advice, does not create any advisory relationship, and no warranty is given as to its completeness or its sufficiency for compliance in any jurisdiction. Each Deploying Company remains solely responsible for its own compliance with applicable data protection and privacy legislation, including its choice and configuration of third parties, its CMP, and its own disclosures. **Please obtain your own independent legal advice before relying on anything in this document.** *This document describes the code in this repository as of the version date. Regenerate after material changes to storage keys, endpoints, or data flows.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.hbwrapper.com/privacy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.