bGuru

bGuru Cookie & Ad-Tech Policy

Version 0.1.1-draftdraft

⚠️ DRAFT — not legally reviewed. Pending attorney sign-off per docs/legal/_research/decisions-log.md "Attorney review — deferred MVP+30d" (target 2026-07-01).

§0 Plain-language summary

bGuru's MVP is built to do the bare minimum tracking. No ads. No cross-app tracking. No behavioural analytics. No IDFA or GAID read.

What we do use:

  • A handful of essential cookies on the mini-site (bguru.app) — for session management, security, and the cookie banner itself.
  • A push-notification identifier (OneSignal player_id) — only if you opt in to push.
  • Crash-reporting telemetry (Sentry, EU region) — to find and fix bugs. No email or display name in crash reports.
  • The basic platform telemetry Apple and Google collect automatically.

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).

When we eventually add advertising (planned for a future version, not at MVP), we will: (a) update this Policy via the 30-day material-change notice flow, (b) add the Apple App Tracking Transparency (ATT) prompt, (c) add a "Do Not Sell or Share My Personal Information" link for US users, (d) honour the Global Privacy Control (GPC) signal — BEFORE the ad SDK ships.

§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, Sentry session ID, IDFA, GAID, IDFV, etc.). Identifiers are the mobile-app equivalent of cookies.
  • 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.
  • CMP (Consent Management Platform) — software that collects, records, and signals your cookie choices to bGuru and any third-party sub-processors. bGuru uses Google User Messaging Platform (UMP) as its CMP, configured for IAB TCF v2.2.
  • 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.
  • 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 MVP.

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 MVP

At MVP, 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
CMP consent-state cookie bGuru / UMP Records your cookie choices so the banner is not re-shown on every page load 12 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 MVP bGuru does not use Google Analytics, Plausible, Matomo, or any analytics SDK — —
Advertising / targeting NONE at MVP 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 per Q10); Belgium APD-GBA engagement-as-consideration WATCH (Belgium is a deferred market per Q10).
  • 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 MVP 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 UMP 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 session identifier Crash reporting + performance monitoring (anonymised; no email or display name per §3.1 of Privacy Policy) Legitimate interest (EU/UK/IL) 30 days
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 MVP per Q6.3 N/A —
Google GAID (Advertising ID) NOT READ at MVP per Q6.3 N/A —

§3 Advertising and tracking we do NOT use at MVP

Affirmative disclosure (per Q6.1 + Q6.3 resolutions 2026-05-31):

  • No third-party advertising SDK. No AdMob, no Meta Audience Network, no in-house ad server, no header-bidding code.
  • No behavioural 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. bGuru does not request an ATT prompt on iOS (Q6.3).
  • No cross-app tracking via GAID. bGuru does not read the Android Advertising ID (Q6.3).
  • No fingerprinting. No canvas, audio, font, hardware, or network-level fingerprinting.

This MVP posture is unambiguous. When we activate advertising in a future version (per the Q6.1 roadmap), this Policy will be amended via the §9 material-change notice flow + the ATT prompt + IAB TCF v2.2 vendor list expansion + GPC honouring + a "Do Not Sell or Share" link, all BEFORE any ad SDK ships.

§4 Your consent and the cookie banner

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

bGuru's mini-site shows a Google User Messaging Platform (UMP) consent banner to all EU/EEA and UK visitors. The banner is configured for IAB TCF v2.2 compatibility and is structured to satisfy ePrivacy Directive Art. 5(3) (EU/EEA) and PECR reg. 6 (UK) simultaneously.

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 MVP 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. The TikTok £12.7M fine (2023) for children's data confirms ICO willingness to fine substantial sums.

Crown Dependencies. Each Crown Dependency (Isle of Man, Jersey, Guernsey, Gibraltar) applies materially equivalent regimes. bGuru's strictly-necessary-only MVP 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 UMP cookie 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 UMP banner functions as a transparency-and-notice mechanism that satisfies general data-protection-law obligations across the rest-of-world portfolio:

  • Australia (Privacy Act 1988, APP 5). Notification-of-collection requirement; UMP banner + Privacy Policy satisfy. APP 7 direct-marketing opt-out for push notifications satisfied by Settings → Notifications. eSafety Commissioner Basic Online Safety Expectations 2022 (BOSE) compliance via minimal-tracking posture.
  • 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 UMP 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 UMP banner + Privacy Policy. DPO contact = legal@bguru.app.
  • New Zealand (Privacy Act 2020, IPP 3). Collection-notice requirement satisfied by UMP 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 UMP banner + Privacy Policy.
  • Other LATAM (AR / CL / CO / PE). General notice + transparency obligations satisfied; no LATAM-specific opt-in for non-essential cookies at MVP (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): no cookie-policy treatment at MVP per Q10 + Q12. v1.1 expansion (FR-CA + FR-FR + NL/Flemish + DE/Belgian + LGPD/DPDP work) will include re-evaluation of cookie-banner obligations.

§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 MVP. bGuru does NOT read the IDFA at this version of the Service per Q6.3. No advertising SDK is integrated at MVP. Because no IDFA read occurs, Apple's framework does not require bGuru to display the ATT prompt — and bGuru deliberately does not, as not displaying an unnecessary tracking prompt is the cleanest user-trust posture and aligns with Apple's "minimum data collection" preference.

On Android, the equivalent identifier is the Google Advertising ID (GAID); bGuru does not read GAID at MVP.

What changes when advertising activates (planned for a future version per Q6.1). In this exact order, BEFORE any ad SDK ships:

  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. 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).
  4. This Policy updated via the §9 material-change notice flow before activation.

Under-18 ATT gate (engineering constraint). When ATT activates, 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) Anonymised session ID + crash trace 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

§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:

  • No advertising tracking technologies (IDFA, GAID, advertising cookies, fingerprinting) applied to any user under 18 at any version of the Service.
  • No algorithmically-personalised content feed served to users under 18 (not applicable at MVP — 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 4 (data sharing) — only strictly-necessary sub-processors; Standard 5 (geolocation) — city-level only, never precise; Standard 8 (profiling) — off by default; Standard 9 (nudge techniques) — banner reject-as-prominent-as-accept design standard applied. Recent ICO enforcement (TikTok £12.7M, 2023) confirms the standard is live.

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. bGuru's no-advertising posture satisfies.
  • 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. bGuru's no-advertising posture at MVP automatically satisfies. Re-evaluate before ad SDK ships for the engineering pre-requisite: 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. bGuru's 16+ gate + max-protection treatment for 16–17 users + zero ad-tech posture exceeds Israeli legal requirements (Israel has no standalone children's online-design code at MVP).

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 §14.1.

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

  • California: CCPA/CPRA Sale/Share opt-out — NOT currently triggered (bGuru does not sell or share at MVP); pre-activation commitment to add the link + GPC honouring before any ad SDK ships. GPC signal honoured via CMP. Complaints to the California Privacy Protection Agency (CPPA) at cppa.ca.gov/complaints.
  • Colorado: CPA Universal Opt-Out Mechanism (UOM) honoured via CMP; same pre-activation commitment. 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. Advertising SDK activation (e.g., AdMob) → substantial rewrite required: ATT prompt + IAB TCF v2.2 vendor list expansion + "Do Not Sell or Share" link + GPC honouring + KOSMA + SAFE Act + MODPA + CPA + FL HB 3 re-evaluation + DSA Art. 28 under-18 ad-suppression engineering + KR PIPA opt-in + APPI Art. 27 disclosure + AU APP 7 opt-out + per-jurisdiction §30A / IT Network Act / POPIA s. 69 / LGPD Art. 18 review.
  2. Algorithmic content-recommendation feed activation → KOSMA + NY SAFE Act + FL HB 3 + DSA Art. 28 all engaged; substantial §7 rewrite.
  3. Any new sub-processor with personal-data flow → §6 inventory update + GDPR Art. 28 sub-processor obligations + cross-border transfer reassessment.
  4. Apple IDFA / Google GAID read activation → §5 ATT prompt + Privacy Policy v0.2 (per Privacy Policy T9.6 trigger list).
  5. Belgian Gaming Commission engagement-as-consideration theory expansion → §4.1 BE-specific re-evaluation (currently deferred market per Q10; 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 Status Changes Reviewed by
0.1.0-draft 2026-06-01 (target) draft Initial draft via 5-specialist team workflow (legal-uk + legal-us + legal-eu + legal-il + legal-global). MVP-only scope: no ads / no IDFA-GAID / no behavioural analytics / minimal tracking per Q6.1 + Q6.2 + Q6.3. Israel reframed as opt-in jurisdiction (was incorrectly classified as "implied consent" in skeleton). Specialist drafts merged 2026-05-31; flags from legal-il (§30A push opt-in confirmation + PPA 2024 guidance) + legal-uk (Crown Dependencies treatment + ICO 2024 design guidance) + legal-eu (German TDDDG § 25 rename + NOYB dark-pattern risk + DSA Art. 28 forward-looking gate) + legal-us (ATT under-18 gate + state-by-state opt-out matrix + CPRA pre-activation commitment) + legal-global (rest-of-world notice-via-UMP architecture) all integrated. unreviewed (specialist whole-doc review round pending; attorney sign-off deferred to MVP+30d per Q4)