bGuru

bGuru Cookie & Ad-Tech Policy

Version 0.1.12published

Last updated: 2026-08-17

§0 Plain-language summary

bGuru is built to do the bare minimum tracking. What tracking we actually use at this version of the Service: essential cookies on the mini-site, a push token (only if you opt in), and crash reporting (Sentry, EU region).

We do not show ads. No advertising SDK is active in the app. bGuru briefly activated a Google AdMob non-personalized (NPA) advertising integration on 2026-06-02 and removed it from the codebase entirely on 2026-06-08 — nothing was live for more than a few days, and nothing is live now. If bGuru reintroduces advertising in a future version, the plan (not yet scheduled) is two phases: Phase 1 would be non-personalized contextual ads served through Google AdMob — matched to the app's content category, not to a profile of you, with no IDFA or GAID read and no behavioral profiling — and Phase 2, a further future step that may never happen, would be personalized advertising. Whichever phase (if any) is reached first, bGuru commits to: (a) updating this Policy and giving you 30 days' advance notice before any ad serves, (b) blocking gambling, sportsbook, casino, and fantasy-sports ad categories at the ad-network console with an internal kill-switch, and (c) never showing profiling-based or behavioral advertising to any user under 18, at any version of the Service, permanently.

What we never do: no cross-app tracking, no behavioral analytics, no IDFA or GAID read, no profiling-based ads to anyone, no behavioral ads to users under 18 at any version.

If you're in the EU, UK, or Israel, our mini-site shows a consent banner where you can accept or reject non-essential cookies. The "Reject all" button is as prominent as the "Accept all" button on the first layer (no dark patterns).

If advertising is reintroduced in a future version, before any ad of any kind serves we will: (a) update this Policy via the 30-day material-change notice flow described in §9, (b) update the Privacy Policy and Sub-processor list, and (c) if the reintroduction is Phase 2 (personalized rather than non-personalized), additionally add the Apple ATT prompt, add a "Do Not Sell or Share My Personal Information" link for US users, honour the Global Privacy Control (GPC) signal, and wire a registered IAB TCF v2.2 CMP (Google UMP) for EU/UK users.

§1 Definitions

  • Cookie — a small data file stored by your browser when you visit a website (the bGuru mini-site at bguru.app). The mobile app does not use cookies; it uses tokens.
  • Identifier — any data point that uniquely tags a device or session (a session JWT, OneSignal player_id, IDFA, GAID, IDFV, etc.). Identifiers are the mobile-app equivalent of cookies. (Sentry does not receive any such identifier from bGuru — see §2.2.)
  • Strictly necessary — cookies or identifiers without which the Service cannot function as you requested (e.g., authentication session). No consent required under PECR reg. 6(4) (UK), ePrivacy Directive Art. 5(3) (EU), or PPL equivalents (IL).
  • Functional / analytics / advertising — cookies or identifiers that improve, measure, or monetise the Service but are not strictly necessary. Consent required under PECR, ePrivacy, and most equivalent regimes.
  • NPA (Non-Personalized Ads) — an advertising mode in which the ad server (Google AdMob) does not use behavioral data, device identifiers (IDFA/GAID), or a user profile to select ads. Instead, ads are matched to the app's content category (contextual targeting). No interest graph is built. No cross-app tracking occurs. No advertising SDK is active at this version of the Service; NPA mode is the mode bGuru plans to use, via the npa=1 request parameter, if and when advertising is reintroduced (see §3).
  • Contextual advertising — ads matched to the content or sport being viewed, without using any personal identifier or behavioral history. Distinct from "behavioral" or "interest-based" advertising, which relies on profiling. Not currently in use — see §3.
  • CMP (Consent Management Platform) — software that collects, records, and signals your cookie choices to bGuru and any third-party sub-processors. At this version of the Service, bGuru uses a bespoke first-party consent banner on the mini-site (no third-party CMP SDK) — see §4.1. No advertising SDK exists at this version to signal consent to, so no consent-signalling question for advertising currently arises. If and when bGuru introduces advertising, the CMP question will be reassessed as part of the pre-activation checklist in §9; if that advertising is personalized, the consent architecture will be upgraded to a registered IAB TCF v2.2 CMP (Google UMP) before any personalized ad serves.
  • IAB TCF v2.2 — the Interactive Advertising Bureau Europe Transparency and Consent Framework version 2.2, the industry standard for capturing and signalling EU/UK cookie consent in a machine-readable format. bGuru does not implement IAB TCF v2.2 at this version of the Service — there is no advertising vendor to signal consent to; see §4.1 for detail on when this would be reassessed.
  • GPC (Global Privacy Control) — a browser-level signal indicating a consumer's universal opt-out of sale/sharing of personal information. Required to be honoured under CPRA (CA), CPA (CO), and certain other US state laws.
  • ATT (App Tracking Transparency) — Apple's framework requiring an explicit user grant before an iOS app may read the device IDFA (Identifier for Advertisers).
  • IDFA / GAID / IDFV — Apple Identifier for Advertisers / Google Advertising ID / Apple Identifier for Vendor (vendor-scoped, no third-party access). bGuru reads NONE of these at this version of the Service.

Cross-reference: see Privacy Policy, §1 Definitions, for terms used in both documents.

§2 Cookies and similar technologies we use

§2.1 Mini-site cookies (bguru.app) — at this version of the Service

At this version of the Service, bGuru's mini-site uses only strictly necessary cookies. No analytics cookies. No advertising cookies. No fingerprinting.

Cookie / identifier Set by Purpose Retention Consent required?
__cf_bm, cf_clearance Cloudflare (CDN + bot-detection) Distinguish human visitors from automated bots; required for DDoS protection and basic availability Session / up to 30 min / up to 24 hours No — strictly necessary; PECR reg. 6(4) + ePrivacy Art. 5(3) exemptions apply
Session JWT (sb-* if served via cookie) bGuru (first-party) Maintains your login state Session; cleared on sign-out No — strictly necessary
bg_consent (consent-state cookie) bGuru (first-party) Records your cookie choice (accepted or rejected) so the banner is not re-shown on every page load 6 months No — strictly necessary (per EDPB Guidelines 05/2020 §93; ICO 2024 cookie guidance)
CSRF token bGuru (first-party) Prevents cross-site request forgery Session No — strictly necessary
Language preference (if implemented) bGuru (first-party) Stores your preferred display language 12 months Yes — functional (opt-in required)
Analytics / performance NONE at this version bGuru does not use Google Analytics, Plausible, Matomo, or any analytics SDK on the mini-site — —
Advertising / targeting NONE at this version bGuru does not use any ad-network or retargeting cookie — —

Why the consent-state cookie is strictly necessary. Without it, you would be asked for cookie preferences on every page load — recording your choice is an integral part of giving effect to that choice. The EDPB Guidelines 05/2020 on consent §93 and the ICO's 2023 cookie report both confirm this analysis.

Per-jurisdiction classification:

  • EU/EEA (ePrivacy Directive Art. 5(3) + GDPR). All four "strictly necessary" cookies above qualify for the Art. 5(3) exemption (the Service is technically unavailable without the bot-detection cookie; cannot function in an authenticated state without the session cookie; cannot honour your consent choice without the consent-state cookie; cannot prevent CSRF attacks without the CSRF token). Per-MS divergences: Germany TDDDG §25 (renamed from TTDSG, May 2024) requires reject-as-prominent-as-accept on the first layer; Italy Garante 2021 provvedimento requires the same; France CNIL délibération 2020-091 requires "Refuser tout" in one click (France is a deferred market at MVP); Belgium APD-GBA engagement-as-consideration WATCH (Belgium is a deferred market at MVP).
  • United Kingdom (PECR reg. 6). Same exemption applies (reg. 6(4) — strictly necessary for a service explicitly requested by the user). ICO 2024 cookie-banner design guidance requires reject-as-prominent-as-accept. Crown Dependencies (Isle of Man, Jersey, Guernsey, Gibraltar) apply materially equivalent regimes; bGuru's strictly-necessary-only posture satisfies all four.
  • Israel (PPL Amendment 13 + Communications Law §30A). Israel has no standalone cookie law; cookie obligations arise from the PPL's general consent + lawful-basis framework + the §30A opt-in rule for marketing identifiers. Strictly necessary cookies that do not store personally identifying information fall outside PPL scope; cookies linked to an authenticated user record fall within the contract-performance lawful basis. No Israeli-specific cookie banner is required; the first-party consent banner shown to EU/UK visitors equally satisfies PPL transparency obligations for Israeli visitors. The PPA's 2024 guidance is consistent.
  • United States (no federal cookie law). No federal-level cookie consent statute exists. State laws (CCPA/CPRA, VCDPA, CPA, CTDPA, etc.) treat cookies that collect personal information as personal-data processing subject to general transparency obligations. bGuru's strictly-necessary-only posture creates no current opt-out trigger; see §8 for state-level rights detail.

§2.2 Mobile app — no cookies; identifier inventory

The bGuru mobile app does not use cookies. It uses tokens (JWT) and identifiers, all classified below:

Identifier Purpose Lawful basis Retention
Supabase Auth JWT Authenticates your requests Contract performance Lifespan controlled by Supabase Auth; rotates on sign-out
OneSignal player_id Push notification subscription Consent (explicit opt-in via system permission prompt) Until you revoke push permission or account deletion completes
Sentry identifier NOT sent at this version of the Service. No email, display name, account ID, or device ID is sent to Sentry — bGuru's integration never calls Sentry's user-identification API, and the Sentry SDK does not generate one of its own. Crash reporting + performance monitoring runs on device model, OS version, app version, stack traces, and non-body request metadata only (see Privacy Policy §3.1). N/A —
Apple IDFV (Identifier for Vendor) Vendor-scoped, not third-party readable — used by OS; not actively read by bGuru code N/A (OS-level) Persistent for app install
Apple IDFA (Identifier for Advertisers) NOT requested at this version of the Service. bGuru does not use any advertising SDK, so there is nothing to request IDFA for. No ATT prompt is shown because no IDFA read is requested. N/A —
Google GAID (Advertising ID) NOT read or transmitted at this version of the Service. No advertising SDK is active, so GAID is never accessed. N/A —

§3 Advertising at this version of the Service — and the reintroduction plan

bGuru does not run any advertising at this version of the Service. No advertising SDK is active in the app. A Google AdMob non-personalized (NPA) integration was activated on 2026-06-02 and removed from the codebase on 2026-06-08 (branch chore/remove-admob-mvp) — the window in which it was live was a few days, and nothing is transmitted to Google AdMob, or to any other advertising network, now.

No ad formats currently exist: no banners, no interstitials, no video, no playables, no native feed ads.

§3.1 If advertising is reintroduced — the planned two-phase path

Nothing below is scheduled or committed to a date. It describes the plan bGuru will follow if and when advertising is reintroduced, so the commitments are on the record before that decision is made rather than drafted after the fact.

Phase 1 — non-personalized contextual ads (planned first step, v1.1+). If reintroduced, advertising would be served by Google AdMob in NPA (non-personalized ads) mode:

  • Ads would be chosen based on the app's content category (sports, predictions) — not on a profile of you.
  • Google would not read your Apple IDFA or Android GAID to select ads; AdMob requests would carry npa=1.
  • No interest graph or behavioral profile would be built about you for advertising.
  • No cross-app tracking would occur.
  • No targeting based on your prediction history, group memberships, or leaderboard position.
  • Frequency would be capped. Tapping an ad would open the advertiser's URL in an in-app browser.

Gambling-category block (committed as a condition of Phase 1, before it activates): the following ad categories will be blocked at the Google AdMob console and monitored through an internal kill-switch process: gambling, sports betting, casino, fantasy sports (paid entry), prediction markets with monetary stakes, lottery, binary options, crypto trading with leverage, and adjacent high-risk categories (payday lending, adult content). A remote kill-switch in the admin panel would let bGuru disable all ads instantly if a prohibited ad ever slipped through.

Phase 2 — personalized advertising (a further future step, not currently planned or scheduled, and may never happen). If bGuru ever moves beyond Phase 1 to personalized/behavioral advertising, this Policy will be substantially rewritten via the §9 material-change notice flow before that step, including the addition of an ATT prompt, a registered IAB TCF v2.2 CMP (Google UMP), GPC honouring, and a "Do Not Sell or Share" link — all BEFORE any personalized ad serves.

§3.2 What we do NOT use, at this version of the Service or in the Phase 1 plan

  • No behavioral analytics SDK. No Mixpanel, no Amplitude, no PostHog, no Heap, no Segment-based analytics pipeline.
  • No retargeting / remarketing pixels. No Meta Pixel, no Google Ads conversion pixel.
  • No conversion-tracking / attribution SDK. No AppsFlyer, no Adjust, no Branch, no Singular, no Kochava.
  • No cross-app tracking via IDFA. No advertising SDK is active; if Phase 1 activates, AdMob requests would carry npa=1 and IDFA would not be requested — an ATT prompt would not be triggered at that stage.
  • No cross-app tracking via GAID. No advertising SDK is active; if Phase 1 activates, GAID would not be passed to AdMob.
  • No fingerprinting. No canvas, audio, font, hardware, or network-level fingerprinting.
  • No programmatic header bidding, no IAB TCF v2.2 vendor list integration. If Phase 1 activates, NPA mode would route only through Google's own ad inventory; no OpenRTB auction with third-party DSPs.
  • No interest-based audience segments. No retargeting lists built from bGuru user data.

§4 Your consent and the cookie banner

§4.1 EU/EEA + UK users — opt-in consent

bGuru's mini-site shows a first-party consent banner served directly from bguru.app to all EU/EEA and UK visitors. The banner is implemented as a bespoke first-party component — no third-party CMP SDK (such as Google UMP) is loaded at this version of the Service. It records your choice in a single first-party cookie (bg_consent, values accepted or rejected, max-age 6 months, SameSite=Lax, host-only on bguru.app). Until you have clicked a button, no non-essential cookies are set and no third-party scripts are loaded. The banner is structured to satisfy ePrivacy Directive Art. 5(3) (EU/EEA) and PECR reg. 6 (UK) simultaneously.

Note on IAB TCF v2.2. bGuru does not implement the IAB TCF v2.2 framework at this version of the Service. The reason is straightforward: no advertising of any kind is served, so there is no behavioral (or even contextual) advertising vendor to whom consent must be signalled via the TCF. We will reassess this posture before enabling any advertising, personalized or otherwise. The bespoke first-party consent banner remains in place and is sufficient for the strictly-necessary-cookies disclosure that is its primary function on the mini-site today. If advertising is reintroduced in the future (see §3), the consent architecture question will be reassessed as part of the pre-activation checklist in §9: for Phase 1 (non-personalized), we currently expect TCF signalling will not be required for the same reasoning that applies today, but this will be reassessed before Phase 1 ships, not assumed; for Phase 2 (personalized), the consent architecture will be upgraded to a registered IAB TCF v2.2 CMP (Google UMP) before any personalized ad serves — as stated in §3 and §9 of this Policy. If platform policy, Google policy, or applicable local law requires consent for any ad delivery, measurement, frequency-capping, or related storage/access operation in a launch market at the time advertising is reintroduced, bGuru will adjust the consent flow or disable ads in that market before activating.

Consent standard (ePrivacy + GDPR Art. 7 / PECR + UK GDPR Art. 7). Consent must be freely given, specific, informed, unambiguous, and as easy to withdraw as to give. Pre-ticked boxes are NOT valid consent (CJEU C-673/17 Planet49, ICO confirmation). Continued-browsing is NOT consent. Cookie walls (conditioning access on cookie acceptance) are unlawful (EDPB Opinion 5/2019; confirmed by BfDI, Garante, AEPD, ICO).

Banner design constraints (non-negotiable):

  • "Reject all" must be at the same visual prominence as "Accept all" on the first layer (ICO 2024 + EDPB Guidelines + NOYB 700+ complaints since 2022).
  • No colour, size, or positioning steering toward acceptance.
  • No "I understand" mapped to acceptance.
  • No multi-click reject path while accept is one-click.
  • Granular consent per category (functional / analytics / advertising — at this version of the Service all three are empty buckets).
  • Withdrawable at any time via the "Cookie preferences" link in the mini-site footer.

Per-member-state enforcement landscape (EU/EEA — at MVP scope):

  • Germany — TDDDG §25 (renamed from TTDSG, May 2024). Strictest national enforcement in the EU. Max administrative fine €300,000 per violation under TDDDG (in addition to GDPR fines).
  • Italy — Garante 2021 provvedimento + 2023 enforcement. Active enforcement against small-to-medium operators, not only large platforms.
  • Ireland — DPC. Lead supervisory authority for several of bGuru's US sub-processors (OneSignal, Cloudflare).
  • Spain — AEPD Circular 1/2022. Reject = 1 click on the first layer. €250M+ cumulative cookie-related fines in 2024.
  • Netherlands — Autoriteit Persoonsgegevens. Cookie walls unlawful.

United Kingdom — PECR + UK GDPR. ICO 2024 cookie-banner guidance applies. PECR's reg. 6(4) "strictly necessary" exemption is interpreted narrowly. ICO enforcement in February 2026 (Reddit £14.47M, MediaLab £247,590 — the first-ever Children's Code fine) confirms the ICO's willingness to fine substantial sums against exactly the "stated protective floor with no real mechanism behind it" fact pattern; the earlier TikTok £12.7M fine (2023) remains historical context for the same willingness.

Crown Dependencies. Each Crown Dependency (Isle of Man, Jersey, Guernsey, Gibraltar) applies materially equivalent regimes. bGuru's strictly-necessary-only posture satisfies all of them without modification.

§4.2 Israel — opt-in consent for marketing identifiers (PPL + Communications Law §30A)

Israel has no standalone cookie law equivalent to ePrivacy. Cookie obligations arise from two overlapping sources: (a) the PPL Amendment 13 consent + lawful-basis framework, treating cookies linked to identifiable information as personal data; and (b) Communications Law §30A (the 2008 Spam Amendment), which imposes opt-in consent for marketing communications via electronic means — including push-notification marketing where the device identifier is treated as the operative addressee.

For Israeli visitors: the first-party consent banner shown to EU/UK visitors equally satisfies PPL transparency obligations. No Israeli-specific banner is required. For push notifications (OneSignal player_id), bGuru's existing explicit-opt-in soft-prompt + system-permission-prompt architecture satisfies both PPL consent and §30A opt-in standards.

Important framing note: Israel's standard is opt-in, the same substantive standard as EU ePrivacy — NOT implied consent. Earlier industry guides that classified Israel as an "implied consent" jurisdiction are outdated (pre-Amendment 13).

§4.3 Rest of world — notice + general data-protection consent posture

For visitors outside the EU/EEA, UK, and Israel, the first-party consent banner functions as a transparency-and-notice mechanism that satisfies general data-protection-law obligations across the rest-of-world portfolio:

  • Australia — not available at this version of the Service. Australia's unavailability turns on a separate Online Safety Act 2021 question — not on cookies or ad-tech (see Terms of Service §3 and Community Guidelines §9.5 for the full analysis) — and is listed in the Deferred markets note below rather than here as an active market. If and when Australia opens, the Privacy Act 1988 App. 1 notification-of-collection requirement and the APP 7 direct-marketing opt-out for push notifications would be satisfied by the same consent-banner + Settings → Notifications posture already described in this Policy.
  • Japan (APPI + PPC 2022 guidance). Cookies linked to identified individuals are personal information. APPI Art. 27 cross-border transfer disclosure (Cloudflare US + OneSignal US) made via the consent banner link to Privacy Policy §6.
  • South Korea (PIPA + IT Network Act). Strictest opt-in regime in Asia. Bundled consent invalid (PIPA Art. 22). Push notifications: explicit opt-in via system prompt satisfies the IT Network Act marketing-opt-in standard.
  • Singapore (PDPA Part III). Notification Obligation 4 satisfied via consent banner + Privacy Policy. DPO contact = legal@bguru.app.
  • New Zealand (Privacy Act 2020, IPP 3). Collection-notice requirement satisfied by consent banner.
  • South Africa (POPIA s. 18 + s. 69). Notification obligation satisfied; direct-marketing opt-in for push satisfied by system prompt. POPIA s. 35 under-18 parental-consent gap for 16-17 users noted as a calibrated risk acceptance per Privacy Policy §9.4.
  • UAE (UAE PDPL + DIFC DPL 2020 + ADGM DPR 2021). Federal PDPL notification satisfied. DIFC/ADGM use GDPR-aligned standards; bGuru's strictly-necessary-only posture satisfies.
  • Mexico (LFPDPPP). Aviso de privacidad obligation satisfied by consent banner + Privacy Policy.
  • Other LATAM (AR / CL / CO / PE). General notice + transparency obligations satisfied; no LATAM-specific opt-in for non-essential cookies at this version of the Service (none deployed).
  • Other MENA (SA / EG / MA / QA / KW). General notice + transparency obligations satisfied.
  • Switzerland (revFADP Art. 45c). Device-storage consent equivalent to ePrivacy Art. 5(3); strictly-necessary-only posture satisfies.

Deferred markets (Canada, France, Belgium, Brazil, India, Australia): these markets are not available at this version of the Service. Australia's gap is a different kind from the other five — an age-assurance-method/coverage question under the Online Safety Act 2021, not a parental-consent or translation requirement — and is not resolved by the same v1.1 infrastructure work (see Terms of Service §3 and Community Guidelines §9.5). The v1.1 expansion (FR-CA + FR-FR + NL/Flemish + DE/Belgian + LGPD/DPDP work) will include re-evaluation of cookie-banner obligations for Canada, France, Belgium, Brazil, and India before each of those five opens.

§5 Apple App Tracking Transparency (ATT)

ATT is Apple's framework requiring an explicit user grant before an iOS app may read the device IDFA (Identifier for Advertisers). The IDFA is the primary cross-app advertising identifier on iOS.

bGuru's current posture: NO ATT prompt at this version of the Service. No advertising SDK is active, so there is no IDFA request to gate. On Android, the equivalent identifier is the Google Advertising ID (GAID); bGuru does not read GAID at this version of the Service either.

If Phase 1 (non-personalized advertising) is reintroduced (see §3), bGuru still does not expect to show an ATT prompt at that stage: AdMob requests would be configured for non-personalized ads only (npa=1), and IDFA would deliberately not be requested. Not displaying an unnecessary tracking prompt is the cleanest user-trust posture and aligns with Apple's "minimum data collection" preference.

What changes if Phase 2 — personalized advertising — is ever introduced (a further future step, requiring a separate decision and its own 30-day notice, not currently planned). In this exact order, BEFORE any personalized ad serves:

  1. ATT prompt string written (NSUserTrackingUsageDescription in Info.plist), approved for clarity per Apple's guidance, and added to App Store Connect privacy-nutrition-label declaration.
  2. ATT prompt displayed BEFORE the ad SDK is initialised in personalized mode. If the user denies, IDFA is all-zeros, no cross-app tracking occurs, the app continues to function normally (App Store Review Guideline 5.1.2(iv) prohibits degrading functionality on ATT denial).
  3. CCPA/CPRA "Do Not Sell or Share" link + GPC-signal honouring activated in the same release. IDFA-based ad integration constitutes a "share for cross-context behavioural advertising" under Cal. Civ. Code § 1798.140(ah). These requirements are NOT triggered by Phase 1 / NPA mode (see §3 and the Privacy Policy §5).
  4. This Policy updated via the §9 material-change notice flow before activation.
  5. Google UMP (IAB TCF v2.2 registered CMP) wired to replace the bespoke first-party banner for advertising consent for EU/EEA and UK users.

Under-18 ATT gate (engineering constraint, applies if Phase 2 is ever reached). bGuru will not request IDFA access from any account that has self-reported being 16 or 17 at registration. This satisfies California SB-976 (KOSMA) and Maryland MODPA prohibitions on processing under-18 personal data for advertising.

§6 Sub-processor tracking and identifiers

Each sub-processor that touches user-identifiable data is listed below. Full DPA links + data-residency details are at bguru.app/legal/subprocessors.

Sub-processor Identifier / cookie Lawful basis Data residency
Supabase (Frankfurt) Session JWT (sb-*) Contract performance EU (no cross-border transfer for EU/UK/IL users)
OneSignal (US) player_id + push token Consent US (SCCs + DPF for EU/UK; PPL DPA-equivalent for IL)
Sentry (EU region) No identifier sent — crash trace + device/app metadata only (no email, display name, account ID, device ID, or IP address) Legitimate interest EU (no cross-border transfer for EU/UK/IL users)
Cloudflare (US-based CDN + global edge) __cf_bm + cf_clearance bot-detection Strictly necessary (PECR reg. 6(4) + ePrivacy Art. 5(3)) Global edge; SCCs + DPF for EU/UK; PPL DPA-equivalent for IL
Apple / Google OS-level telemetry; Apple ID / Google account Platform-tier processor relationship Worldwide; controlled by Apple/Google's own privacy policies
API-Football NONE — server-side only N/A France (API-Football's servers); no user PII transmitted

Google LLC (AdMob) — NOT an active sub-processor at this version of the Service. No ad data of any kind is transmitted to Google AdMob today; the AdMob SDK was removed from the codebase on 2026-06-08. It is therefore not in the active table above. If advertising is reintroduced (see §3), Phase 1 (NPA mode) would transmit only anonymous ad-impression metadata (slot, timing — no user ID linked) and rough geolocation (country/region, inferred from IP by AdMob) — bGuru would not pass to AdMob: IDFA, GAID, bGuru account ID, email, display name, Picks, group memberships, behavioral profile, or cross-app history. Lawful basis at that stage would be legitimate interest (non-profiling contextual ads); this Policy will confirm that analysis is still current before Phase 1 activates, and this table will be updated to list AdMob as active — as described in §9. Transfer mechanism, if activated: Google's Standard DPA + EU-US Data Privacy Framework (DPF) certification + SCCs as contractual backstop for EU/UK. Google DPA: policies.google.com/privacy/frameworks.

§7 Children and ad-tech

bGuru's 16+ flat minimum age (per Terms of Service, §3 Age eligibility, and Privacy Policy, §9 Children's data) means no users under 16 should be present on the platform. For users aged 16–17 (who are still minors under most jurisdictions' civil law), bGuru applies a blanket no-behavioural-targeting policy globally:

  • (a) Behavioural and profiling-based advertising (IDFA, GAID, advertising cookies, fingerprinting, interest-graph targeting) will never be applied to any user under 18, across any version of the Service. This is a permanent commitment — bGuru will not serve behavioural advertising to under-18 users regardless of what advertising model ships in future versions. This commitment reflects mandatory obligations under DSA Art. 28, the ICO Children's Code, KOSMA, MODPA, and equivalent regimes, and bGuru adopts it as a product design principle independent of those obligations.
  • (b) At this version of the Service, no advertising of any kind — personalized or non-personalized — is shown to any user, including those under 18, because no advertising SDK is active. If Phase 1 (non-personalized contextual ads via Google AdMob NPA mode) is reintroduced in a future version, for users registered as 16 or 17 bGuru will apply Google's then-current age-restricted ad-treatment settings available in the Google Mobile Ads SDK before any ad serves to those users. These settings would: (i) confirm to Google that the request comes from an app used by a child; (ii) cause Google to serve only COPPA-compliant non-personalized ads; (iii) ensure IDFA and GAID are not read for those users; (iv) apply Google's own additional protections for child-directed ad requests. Gambling-adjacent, adult-content, alcohol (where user is under 18), and payday-lending ad categories would be blocked at the Google AdMob console and monitored through bGuru's kill-switch regardless of the age-restricted ad-treatment settings, as described in §3.
  • No algorithmically-personalised content feed served to users under 18 (not applicable at this version of the Service — no such feed exists).
  • No push notifications for marketing purposes to users under 18 (only transactional notifications — prediction resolution, group invite — sent pursuant to explicit opt-in).
  • Data collected from under-18 users strictly limited to what is necessary to provide the core Service.

United Kingdom (ICO Age Appropriate Design Code — Children's Code). The Children's Code applies to any service likely to be accessed by users under 18, regardless of the sign-up age. bGuru applies the Code's 15 design standards to users aged 16–17: Standard 9 (data sharing) — only strictly-necessary sub-processors; Standard 10 (geolocation) — city-level only, never precise; Standard 12 (profiling) — off by default; Standard 13 (nudge techniques) — banner reject-as-prominent-as-accept design standard applied. ICO enforcement in February 2026 (Reddit £14.47M, MediaLab £247,590 — the first-ever Children's Code fine, for exactly the "stated protective floor with no real mechanism behind it" fact pattern) confirms the standard is actively applied; the earlier TikTok £12.7M fine (2023) remains historical context for the same willingness to fine substantial sums. At this version of the Service the point is moot in practice — no advertising is served to any user, so no under-18 profiling-for-advertising question currently arises.

United States — state minor-data laws.

  • California KOSMA (Cal. Civ. Code § 1798.99.29 et seq., effective Jan 2025). Prohibits algorithmic addictive feeds to under-18 users without parental consent; restricts push notifications to under-18s without time-of-day controls and consent; restricts data collection of under-18s for addictive-design purposes. bGuru does NOT operate an algorithmic feed and applies the blanket no-behavioural-targeting-of-under-18s policy — substantively compliant. Re-evaluate before any algorithmic-feed feature ships.
  • New York SAFE for Kids Act (N.Y. Soc. Serv. Law § 496-a, 2024). Same analysis: not currently in scope (no algorithmic feed). Re-evaluate on feed activation.
  • Maryland MODPA (Md. Code Com. Law § 14-4604(c), effective Oct 2025). Prohibits processing under-18 data for targeted advertising, sale, or profiling. At this version of the Service, no advertising of any kind is active, which trivially satisfies MODPA. If Phase 1 (NPA-only) is reintroduced, the combination of no profiling, no targeted advertising via IDFA/GAID, and Google's age-restricted ad-treatment settings for users registered as 16 or 17 (described above) is designed to continue satisfying MODPA's prohibition.
  • Colorado CPA (C.R.S. § 6-1-1306(4)). Same. UOM honouring per § 6-1-1315 applies if/when targeted advertising activates.
  • Florida HB 3 (Fla. Stat. § 501.1736 et seq., 2024). Under-14 ban + under-16 parental consent for "social media platforms" with algorithmic feeds. bGuru's 16+ gate + no algorithmic feed = not currently in scope. Re-evaluate on feed activation.

European Union — DSA Art. 28. Online platforms must implement appropriate and proportionate measures to ensure high privacy, safety, and security for minors. DSA Art. 28(2) prohibits profiling-based advertising to known minors. At this version of the Service, bGuru satisfies this trivially because no advertising of any kind is served to anyone. If Phase 1 (non-personalized) is reintroduced, bGuru's compliance would rest on: (a) AdMob NPA mode is not profiling-based — no behavioral profile would be built for anyone; (b) for users registered as 16 or 17, bGuru would apply Google's then-current age-restricted ad-treatment settings available in the Google Mobile Ads SDK, providing an additional hard enforcement signal to Google's ad-serving systems; (c) the gambling-category block (Google AdMob console + kill-switch) would apply to all users. DSA Art. 28 does not prohibit contextual non-profiling ads for minors on its face — it specifically prohibits profiling. If personalized (profiling-based) advertising is ever introduced (Phase 2), the engineering pre-requisite is age-signal-based suppression of behavioural-advertising segments for under-18 users.

Israel. PPL Amendment 13 minor protections + Israeli Consumer Protection Law §4A.5 plain-language obligation. On the age-targeting axis, bGuru's 16+ gate + max-protection treatment for 16–17 users + the current zero-advertising posture exceeds Israeli legal requirements (Israel has no standalone children's online-design code at this version of the Service, and no Israel-specific rule independently requires an 18+ threshold for ad targeting the way DSA Art. 28 or the UK Children's Code do).

A separate, content-suitability duty applies on top of the targeting axis, and is not satisfied by getting the targeting axis right. A 2022 Israeli Consumer Protection Authority (CPA) opinion holds that platforms whose audience includes minors are liable to ensure ad content is not prohibited for minors, "regardless of the manner or means of advertisement" — and specifically rejected the argument that a platform cannot control third-party ad-network content, applying the duty even where an ad reached a minor via a shared device's search history rather than the platform's own targeting choice. This is a content-suitability duty, not a targeting/profiling duty, and it applies to every ad shown to bGuru's 16+ Israeli population — including purely contextual, non-personalized ads — regardless of personalization status or age-band gating. The CPA opinion's own text identifies a recognised compliance route: "platforms may satisfy obligations by incorporating contractual provisions subjecting the advertising networks to the relevant law and regulations." bGuru's existing committed gambling/casino/sportsbook/predatory/financial-harm ad-category block (§3.1) already substantially covers this in substance; what remains before the first ad serves to Israel is drafting that block into the actual signed ad-network contract as a clause explicitly binding the network to Israeli minors-content law, not leaving it as policy prose alone. Full analysis: docs/legal/_research/age-gating-strategy.md §12.3.3/§12.3.4.

Rest of world. ZA POPIA s. 35 + UAE PDPL Art. 8 + MX LFPDPPP + LATAM/MENA civil-law minor protections all require parental consent for under-18 processing in their respective regimes. The 16–17 gap is a calibrated risk acceptance documented in Privacy Policy §9.1 + §9.4 (same magnitude as Art. 27 deferral). The v1.1 parental-consent provider integration closes the gap.

§8 Your rights and how to opt out

§8.1 Universal opt-out mechanisms (every jurisdiction)

  • Re-show cookie banner via the "Cookie preferences" link in the mini-site footer (bguru.app)
  • Clear cookies + local storage via your browser's settings
  • Push notifications: Settings → Privacy → Notifications (in-app) OR device system Settings → Notifications → bGuru → Off
  • Account deletion: Settings → Account → Delete account (per Terms of Service, §10 Account deletion)
  • All other rights: email legal@bguru.app with your account email + the right you're exercising

§8.2 Jurisdiction-specific opt-out + regulatory contact

United Kingdom — PECR withdrawal + UK GDPR Art. 21 objection. Withdraw cookie consent via the footer link or by deleting the bGuru consent-state cookie. Object to legitimate-interest processing (Sentry) via email subject "UK Art. 21 Objection". Complaints to the ICO: Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF; casework@ico.org.uk; 0303 123 1113; ico.org.uk/make-a-complaint. Crown Dependencies: Isle of Man Information Commissioner (inforights.im); Jersey Office of the Information Commissioner (jerseyoic.org); Guernsey ODPA (odpa.gg); Gibraltar GRA Data Protection Commissioner (gra.gi).

European Union / EEA — ePrivacy + GDPR Art. 21 objection. Withdraw cookie consent via the footer link (equally easy as giving). Object to legitimate-interest processing (Sentry) via email subject "GDPR Art. 21 objection". Complaints to your member-state DPA — see Privacy Policy, §8.2 Jurisdiction-specific rights for full table. Switzerland: FDPIC (edoeb.admin.ch).

Israel — PPL Amendment 13 + §30A. Withdraw cookie consent via footer link; withdraw push consent via Settings → Notifications. Complaints to the PPA (רשות להגנת הפרטיות): 3 Kaplan Street, Jerusalem 9195020; rmot.regulation@justice.gov.il; gov.il/en/departments/the_privacy_protection_authority. Israeli-resident consumers retain the right to bring proceedings in their local Israeli court per ToS §15.1.

United States — CCPA/CPRA + state-by-state.

  • California: CCPA/CPRA Sale/Share opt-out — NOT currently triggered (bGuru does not sell or share personal data, and no advertising SDK is active at this version of the Service); pre-activation commitment to add the "Do Not Sell or Share" link and to honour the GPC signal before any ad SDK ships. Complaints to the California Privacy Protection Agency (CPPA) at cppa.ca.gov/complaints.
  • Colorado: CPA Universal Opt-Out Mechanism (UOM) — same pre-activation commitment to honour UOM before any targeted-advertising capability ships. Colorado AG enforces.
  • Virginia, Connecticut, Utah: VCDPA/CTDPA/UCPA opt-out for sale, targeted advertising, profiling — same channel (legal@bguru.app), same posture.
  • Texas TDPSA (elevated AG enforcement): same opt-out rights, same channel.
  • Oregon, Montana, New Jersey, Indiana, Kentucky, Rhode Island, Tennessee, Delaware, Iowa, Nebraska, New Hampshire, Minnesota, Maryland (MODPA): same VCDPA-template opt-out rights; channel legal@bguru.app, 45-day response.
  • New York: SHIELD Act + GBL §349–350 private right of action; no comprehensive privacy law yet enacted. Channel: legal@bguru.app.
  • Florida: FDBR revenue thresholds (>$1B) not met at MVP scale; HB 3 minor-data covered in §7.

US response time: 45 days from verified receipt, with one 45-day extension for complex requests.

Rest of world — opt-out + regulator contact (see Privacy Policy, §8.2 Jurisdiction-specific rights, for full detail):

§9 Changes to this Policy

We may change this Cookie & Ad-Tech Policy from time to time. For material changes — including the addition of any third-party advertising SDK, any IDFA/GAID read, any behavioural-analytics SDK, or any new sub-processor that processes identifiers — we will give you at least 30 days' notice before the change takes effect, via an in-app banner shown the next time you sign in and (where you have provided an email address) by email.

Specific triggers for amendment of this Policy:

  1. Phase 1 — reintroducing non-personalized (NPA) advertising (switching from no advertising to non-personalized contextual ads via Google AdMob) → material update to this Policy required, plus a 30-day material-change notice to all users before any ad serves. ALL of the following pre-conditions must be completed before the first ad of any kind serves:

    Engineering pre-conditions:

    • npa=1 parameter set on every ad request from the first request onward — no window in which a request could be personalized by default.
    • No IDFA requested; no ATT prompt shown at this phase.
    • No GAID passed to AdMob.
    • Gambling, sports betting, casino, fantasy sports (paid entry), prediction markets with monetary stakes, lottery, binary options, crypto-with-leverage, payday-lending, and adult-content ad categories blocked at the Google AdMob console.
    • Remote kill-switch wired into the admin panel and tested end-to-end before the first ad serves.
    • Age-restricted ad-treatment settings applied for users registered as 16 or 17, verified fail-safe (defaults to child-directed treatment if age is unknown or ambiguous).
    • The full checklist in docs/features/feature-13-admob-rollout-plan.md completed.

    Legal doc updates (before Phase 1 activates): this Policy (§0, §3, §6, §7 — remove the conditional "if reintroduced" framing and describe NPA as the active state); Privacy Policy (§0, §3.1, §3.2, §4.1, §4.2, §5, §8.2, §9.3 — same flip); Sub-processor list (move Google LLC (AdMob) from inactive to active with full data-category disclosure).

    30-day material-change notice issued to all users before the first ad of any kind serves, per the standard flow at the top of this §9.

  2. Phase 2 — personalized advertising activation (switching from NPA to behavioral/personalized mode — e.g., enabling AdMob personalization, disabling npa=1) → substantial rewrite of this Policy required, plus a further 30-day material-change notice to all users before any personalized ad serves. This trigger is only reachable after Phase 1 has already activated. ALL of the following pre-conditions must be completed before the first personalized ad serves:

    Engineering pre-conditions:

    • iOS ATT prompt integrated and approved (NSUserTrackingUsageDescription written + App Store Connect privacy-nutrition-label updated; IDFA read gates behind ATT grant — all-zeros on denial; app continues to function normally on denial per App Store Guideline 5.1.2(iv)).
    • Android GAID handling: GAID accessed only if user has not opted out via Android Privacy settings.
    • npa=1 parameter removed from ad requests for users who have granted ATT/consent; retained for users who have denied ATT, rejected consent, or are under 18.
    • Google UMP (User Messaging Platform) wired as the IAB TCF v2.2 registered CMP — replaces the bespoke first-party consent banner for users in the EU/EEA and UK.
    • Under-18 child-directed-treatment flag continues: users aged 16–17 → child-directed (non-personalised only, npa=1 always); users aged 18+ → personalised-eligible (subject to ATT/GAID/UMP consent). Must be fail-safe: if age is unknown or ambiguous, default to child-directed.
    • "Do Not Sell or Share My Personal Information" link live in the mobile app Settings screen and in the mini-site footer (CCPA/CPRA §1798.120; GPC signal honouring activated in the same release).
    • GPC signal honoured (mobile + mini-site).
    • Apple Privacy Nutrition Label updated: "Data Used to Track You" + "Data Linked to You" fields.
    • Play Store Data Safety section updated.
    • Remote kill-switch remains in place (already required from Phase 1; must remain functional for the personalized phase).

    Gambling-adjacent ad blocking (continues from Phase 1; contractual block must be verified to still cover personalized inventory before personalized activation): the block on gambling, sports betting, casino, fantasy sports, daily fantasy, lottery, prediction markets, and crypto/binary-options trading categories must be confirmed to apply to both NPA and personalized programmatic inventory before personalized ads activate.

    Legal doc rewrites (at personalized activation): Privacy Policy §4.1 (update lawful basis from legitimate interest to consent for behavioral processing); Cookie & Ad-Tech Policy §3 (update from NPA description to personalized description); Cookie & Ad-Tech Policy §4.1 (update consent architecture to UMP); Cookie & Ad-Tech Policy §5 (update ATT section); Sub-processors list (update Google LLC AdMob entry to describe behavioral data categories including IDFA/GAID).

    Per-jurisdiction triggers also engaged at personalized activation: KOSMA + NY SAFE Act + MODPA + CO CPA UOM + FL HB 3 re-evaluation + DSA Art. 28 under-18 profiling-suppression engineering re-verification + KR PIPA opt-in + APPI Art. 27 disclosure + AU APP 7 opt-out + IL §30A / POPIA s. 69 / LGPD Art. 18 review.

  3. Algorithmic content-recommendation feed activation → KOSMA + NY SAFE Act + FL HB 3 + DSA Art. 28 all engaged; substantial §7 rewrite.

  4. Any new sub-processor with personal-data flow → §6 inventory update + GDPR Art. 28 sub-processor obligations + cross-border transfer reassessment.

  5. Apple IDFA / Google GAID read activation → §5 ATT prompt + Privacy Policy update to name the new identifier use.

  6. Belgian Gaming Commission engagement-as-consideration theory expansion → §4.1 BE-specific re-evaluation (Belgium is a deferred market at MVP; trigger applies when BE re-opens).

Non-material changes (typographical corrections, link updates, clarifications) may be published without 30-day notice; the updated last_updated date in the document header is the controlling indicator.

For changes required by mandatory law or by a genuine security or safety obligation that cannot reasonably be delayed, we may make the change effective immediately and notify you within 7 days.

EU/EEA users (DSA Art. 12). During the 30-day notice period for any material change, you have the right to terminate your use of the Service and delete your Account (see Terms of Service, §10 Account deletion) free of any penalty.

§10 Contact us

For any cookie or ad-tech inquiry, contact us:

Email: legal@bguru.app In-app: Settings → Help → Contact Us

We respond within one month of receiving your inquiry per GDPR Art. 12(3), UK GDPR equivalent, IL PPL Amendment 13, and equivalent obligations. Faster on urgent matters.

Sole-proprietorship posture. bGuru is currently operated as a sole-proprietorship project of an Israeli resident (see Privacy Policy §2). The legal@bguru.app channel is staffed personally by the founder until the entity decision lands post-MVP.

EU/EEA Art. 27 representative + UK Art. 27 representative: appointment deferred (cost-driven, target MVP+1). legal@bguru.app is the interim channel.

§11 Changelog

Version Effective date Changes
0.1.12 2026-08-17 One stale Terms-of-Service cross-reference corrected. The Terms of Service gained a new §11 (Third-party intellectual property) in an earlier release, which shifted every later section down by one — Geographic restrictions §13→§14, Governing law §14→§15, Changes §15→§16, Contact §16→§17 — but inbound cross-references were never updated. Each pointer below therefore sent readers to a real but wrong section. No right, obligation, or disclosure changed; this is a navigation fix. Fixed: §8.2 Israel (Israeli-court right) ToS §14.1→§15.1.
0.1.11 2026-08-17 Four corrections found by the 5-specialist debate round on the age-gating research-completion pass. (1) §4.3's Australia bullet described ordinary active compliance with no deferred flag, and Australia was missing from the "Deferred markets" list — the same overclaim ToS v0.1.14 / Privacy Policy v0.1.13 already corrected in their own Australia paragraphs, propagated to this document for the first time (the second consecutive pass in which this document and Community Guidelines fell through separate "Affects" tracking on an age/market-availability question). Fixed: Australia now states plainly it is not available, cross-references the ToS/Community Guidelines treatment, and is added to the Deferred markets list with a note that its gap is a different kind (age-assurance method, not translation/parental-consent) from the other five. (2) §4.1 and §7 cited ICO Children's Code standard numbers 4/5/8/9 for data sharing/geolocation/profiling/nudge techniques — the confirmed-correct ICO ordering is 9/10/12/13 (matching age-gating-strategy.md §4.3/§12.3.1's own citations); the substance described at each number was accurate, only the citation labels were wrong. (3) §4.1 and §7's ICO-enforcement citation (TikTok £12.7M, 2023) updated to lead with the more directly on-point February 2026 Reddit (£14.47M) / MediaLab (£247,590, first-ever Children's Code fine) pair — the fact pattern (stated floor + no real enforcement + no DPIA) directly on point for bGuru's current state — kept alongside the TikTok fine as historical context. (4) §7's Israel paragraph — confirmed to already exist since 2026-05-31 (not absent, as an earlier pass mistakenly reported) but stale — updated with the 2022 Israeli Consumer Protection Authority content-suitability opinion and the ad-network-contract compliance route it identifies, separating the age-targeting axis (bGuru's own voluntary 18+ choice, already satisfied) from the content-suitability axis (a real, adjudicated duty, not yet drafted into any ad-network contract). No change to the no-advertising posture at this version of the Service. Full debate record: docs/legal/_research/_history/debate-il.md, debate-uk.md, debate-global.md.
0.1.10 2026-08-11 Structural rewrite — advertising-posture correction. This document was never updated for the 2026-06-08 decision to remove the AdMob SDK from the MVP codebase; every section describing advertising (§0, §1, §2.2, §3, §4.1, §5, §6, §7, §9) asserted, in the present tense, that non-personalized contextual ads were currently being served. They are not — no advertising SDK has been active since 2026-06-08. Rewrote §3 from an affirmative "how our advertising works" description into "advertising at this version of the Service — not active" plus a two-phase (Phase 1 NPA / Phase 2 personalized) forward plan; §6's sub-processor table no longer lists Google LLC (AdMob) as active; §7's children's-advertising analysis now states the DSA Art. 28 / MODPA / Children's Code satisfaction is trivial because no advertising is served to anyone, with the age-restricted-treatment commitments recast as pre-conditions of any future Phase 1 reintroduction; §9's amendment-trigger list now has a dedicated Phase 1 (NPA reintroduction) checklist that did not exist before — the prior version only described the "NPA → personalized" step, because it assumed NPA was already the live state. The 30-day material-change notice commitment before any ad of any kind serves is unchanged. The permanent "no behavioural or profiling-based advertising to under-18s at any version" commitment is unchanged and remains unconditional. Companion corrections in the same pass: Terms of Service v0.1.11 (§3 UK/US/EU under-18 paragraphs, which had the same problem and had never been corrected at all) and Community Guidelines v0.1.10 (its 2026-06-08 pass fixed only one of four affected sections).
0.1.9 2026-08-10 Corrected the Sentry references in §1 (dropped "Sentry session ID" from the illustrative identifier list), §2.2 (the identifier-inventory table row, rewritten to state plainly that no identifier is sent to Sentry, matching the existing IDFA/GAID "NOT requested" house style), and §6 (the sub-processor tracking table, "Anonymised session ID" replaced with "No identifier sent"). Reason: the mobile app's Sentry integration was rewritten the same day (PR #512) to send no user identifier at all — not the "anonymised" one previously described. This is a narrowing of what's collected, not an expansion, so no 30-day material-change notice under §9 is required. Companion correction: Privacy Policy v0.1.11 and sub-processor list v0.1.10.
0.1.8 2026-06-02 Refined the age-restricted ad-treatment description (§7) to use generic public wording rather than naming a specific Google SDK flag. The substantive behaviour is unchanged. Collapsed the public changelog's pre-launch drafting iterations into a single summary entry for clarity.
0.1.7 2026-06-02 Refined AdMob NPA-mode IDFA/GAID descriptions in §3 to focus on what bGuru configures. Refined gambling-category blocking description (§0, §3, §7) to match current configuration (console + kill-switch). Added consent fallback safety commitment in §4.1.
0.1.6 2026-06-02 Refined AdMob NPA-mode descriptions to focus on what bGuru configures. §0 / §1 / §2.2 / §4.1 / §5 / §6 reframed.
0.1.5 2026-06-02 Updated for AdMob NPA live. §0 / §1 / §2.2 / §3 / §4.1 / §5 / §6 / §7 / §9 all updated to reflect NPA contextual ads as active.
0.1.4 2026-06-02 Clarified no-ads posture as applying to this version. Permanent no-behavioural-ads-to-under-18 commitment reinforced (§7). §9 amendment trigger 1 updated to name Google AdMob and list all pre-conditions.
Pre-launch drafting iterations 2026-05-30 → 2026-06-01 Multiple internal drafting iterations during the pre-launch review period. The substantive provisions described above were drafted, refined, and consolidated through this period.