bGuru

bGuru Privacy 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 is a free social network for sports predictions. To run it, we collect a small amount of personal data about you: your email and display name, the picks you make, the groups you join, and (if you opt in) a push notification token. That's most of it.

We do not sell your data. We do not show you ads, and we do not track you across other apps or websites. We do not collect anything we don't need.

The two third parties who actually see your data are Supabase (our database provider in Frankfurt) and OneSignal (the push notification service). We also use Sentry (in the EU) to find out when the app crashes, but Sentry doesn't see your email or display name.

You can ask to see, correct, export, or delete your data at any time — through Settings or by emailing legal@bguru.app. We'll respond within one month, faster on urgent matters.

You must be at least 16 to use bGuru. If we find out a user is under 16, we delete the account immediately.

The rest of this Policy is the detail behind the headlines.

§1 Definitions

Terms used in both this Privacy Policy and the Terms of Service have the same meaning as in the Terms of Service (see Terms of Service, §1 Definitions). The following Privacy-Policy-specific terms apply:

  • Personal Data — any information that identifies you, or that can identify you when combined with other information we hold. The exact statutory definition varies by jurisdiction; see §3.2.
  • Special Category Data — heightened-protection categories under GDPR Art. 9 and equivalent regimes (e.g., health, biometric, racial origin, religious belief). bGuru does not collect Special Category Data.
  • Processing — anything we do with Personal Data: collect, store, organise, alter, retrieve, disclose, erase, etc.
  • Sub-processor — a third party that processes Personal Data on bGuru's behalf. See the sub-processor list.
  • Controller — the entity that decides why and how Personal Data is processed. For bGuru, that's the entity identified in §2.
  • Data Subject — you, the person the Personal Data is about.

§2 Who we are (controller identity)

The controller of personal data processed through the Service is:

bGuru (operating as a sole-proprietorship project of an Israeli resident) Web: bguru.app Jurisdiction: Israel Contact: legal@bguru.app

Formal entity formation (Israeli Ltd. or Estonian OÜ) is pending post-MVP review. This section will be updated via the standard 30-day material-change notice mechanism (see Terms of Service, §15) once the entity decision is finalised.

For data-protection purposes:

  • EU/EEA Art. 27 representative — appointment deferred. In the interim, legal@bguru.app is the direct contact channel for EU/EEA users and supervisory authorities; we commit to responding within one month per GDPR Art. 12(3).
  • UK Art. 27 representative — same posture; appointment deferred; legal@bguru.app is the interim channel for UK users and the ICO.
  • Data Protection Officer (DPO) — not appointed at MVP. The processing profile at MVP (no large-scale processing of special-category data, no large-scale systematic monitoring of individuals) does not trigger mandatory DPO appointment under GDPR Art. 37(1)(b) or (c). For Israeli law: bGuru is currently below the PPL Amendment 13 database-registration thresholds (10,000 Israeli residents / 100,000 individuals worldwide holding sensitive information); we monitor user-count growth against these thresholds and will register the database with the PPA and appoint a DPO promptly upon crossing either threshold.

§3 Data we collect

§3.1 Data we actually collect at this version of the Service

Account data (required to use the Service):

  • Email address — used as your login identifier; not displayed publicly.
  • Display name — your public handle on bGuru, set during onboarding (unique, URL-safe).
  • Hashed credential or OAuth token — the password is hashed (bcrypt via Supabase Auth) and is never visible to bGuru; OAuth (Google, Apple, Facebook) returns only a stable identifier.
  • Profile fields — avatar (optional), bio (optional), home city (used for city-level leaderboards; structured FK to the cities table, not free text).

Prediction and social data (the core service):

  • Picks (predictions) — each Pick records: market identifier, outcome chosen, conviction context, timestamp, and the user who submitted it.
  • Conviction scores — computed at lockout (5 minutes before kickoff) based on diversity/unanimity of your Picks across contexts.
  • Group memberships, follows, comments, reactions, group descriptions.
  • Reputation points + leaderboard positions — derived, recomputed periodically; not free text.

Push notification data (only if you opt in):

  • OneSignal player_id — a unique identifier issued by OneSignal for your device.
  • Push token — issued by Apple APNs or Google FCM, stored only as long as needed to deliver notifications.
  • Notification preferences (opt-in/opt-out, topic subscriptions).

Crash + performance data (Sentry, EU region):

  • Device model, operating-system version, app version.
  • Anonymised user identifier (not your email, not your display name; the Sentry SDK's beforeSend callback explicitly scrubs these).
  • Error stack traces, network-request metadata (URL only, no body), performance metrics.

Connection data (transient):

  • IP address — held in memory for rate-limiting + breach-detection (typically <24 hours); not stored long-term.
  • Session JWT — used to authenticate your requests; rotates on sign-out.

Account-deletion data:

  • Deletion-requested timestamp + 30-day grace-period state.

We do NOT collect at MVP:

  • Special Category Data (GDPR Art. 9).
  • Financial data (no payment flow at MVP).
  • Precise geolocation (city-level is the most granular).
  • Apple IDFA or Google Advertising ID (per Q6.3 — we do not request these).
  • Behavioural-tracking data of any kind.

§3.2 Jurisdiction-specific data definitions

European Union / EEA (GDPR Art. 4(1)). Under Regulation (EU) 2016/679 (GDPR), "personal data" means any information relating to an identified or identifiable natural person (a "data subject") — per Art. 4(1), a person is identifiable if they can be identified, directly or indirectly, by reference to an identifier such as a name, an identification number, location data, an online identifier (for example an IP address or a device token), or by reference to one or more factors specific to their physical, physiological, genetic, mental, economic, cultural, or social identity. GDPR Art. 9 defines a subset as "special category data" (racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data, data concerning health, data concerning sex life or sexual orientation) — bGuru does not collect any Art. 9 special category data. GDPR Art. 10 covers data on criminal convictions — bGuru does not process such data. Users in the EU/EEA should be aware that even indirectly identifying data — IP addresses held transiently for rate-limiting, and device identifiers in Sentry crash reports — constitutes personal data within the meaning of Art. 4(1) and is handled on a lawful basis described in §4.

United Kingdom (UK GDPR + DPA 2018 + DPDI Act 2025). For users in the UK, "personal data" means any information that relates to an identified or identifiable living individual, as defined in Article 4(1) of the UK GDPR (the retained UK version of Regulation (EU) 2016/679 as incorporated by the European Union (Withdrawal) Act 2018 and supplemented by the Data Protection Act 2018). That definition is substantively the same as its EU counterpart and is supplemented by Parts 2 and 3 of the DPA 2018 (which extend the framework to law-enforcement and intelligence contexts not relevant to bGuru). "Special category data" — heightened protection under UK GDPR Art. 9 and DPA 2018 Schedule 1 — is not collected by bGuru. The Data (Use and Access) Act 2025 has made targeted amendments to the UK framework since January 2025, principally reducing certain record-keeping burdens for lower-risk controllers and confirming the digital-consent age for information-society services at 13 under DPA 2018 s. 9; none of those amendments alter the definitions, the six lawful bases available to bGuru, or the rights set out in §8. The UK regulator is the Information Commissioner's Office (ICO).

Israel (PPL 5741-1981 + Amendment 13). Under the Privacy Protection Law 5741-1981 / חוק הגנת הפרטיות, תשמ"א-1981 as materially modernised by Amendment 13 (enacted 2024, effective August 2025), "personal information" (מידע אישי) means any information that identifies or can identify a natural person, or information about the personality, personal history, intimate life, health condition, economic situation, opinions, and beliefs of a specific person. This broadly tracks GDPR Art. 4(1), with one substantive Israeli-law difference: the PPL treats financial information (economic situation, income, assets, indebtedness) and information about personal beliefs and opinions as categorically sensitive by default. Under GDPR Art. 9, financial information is not a "special category"; under the PPL, it is. The practical consequence for bGuru at MVP is limited — bGuru does not collect financial information — but the classification matters for future paid tiers. Amendment 13 also introduced a separate "sensitive information" (מידע רגיש) tier that aligns with GDPR Art. 9 (health, biometric, sexual orientation, religious and political affiliation, racial or ethnic origin, criminal history) and imposes stricter processing obligations and the 100,000-individual database-registration threshold on controllers processing it. bGuru does not collect any PPL sensitive information at MVP.

United States (COPPA + CCPA/CPRA + state laws). For US users, "personal information" carries distinct meanings across federal and state law. COPPA (15 U.S.C. § 6501(8)) defines personal information collected from a child under 13 to include name, postal address, email, telephone number, SSN, persistent identifiers (device IDs, session cookies, IP addresses used over time), and any photograph/video/audio of the child. bGuru's 16+ gate (§9) is designed so COPPA's verifiable-parental-consent obligations are never triggered. CCPA/CPRA (Cal. Civ. Code § 1798.140(v)(1)) defines personal information as any information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household. The harmonised state-law definitions used in Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), Utah (UCPA), Texas (TDPSA), Oregon (OCPA), Montana (MCDPA), New Jersey (NJDPA), Indiana (INDPA), Kentucky (KYDPA), Rhode Island (RIDTPPA), Tennessee (TIPA), Delaware (DPDPA), Iowa (ICDPA), Nebraska (NDPA), New Hampshire (NHPA), Maryland (MODPA) (which imposes stricter-than-baseline data-minimisation and profiling restrictions — bGuru's no-behavioural-targeting posture aligns), and Minnesota (MN MCDPA) each define "personal data" as information linked or reasonably linkable to an identified or identifiable natural person, excluding de-identified or publicly available information. The New York SHIELD Act (N.Y. Gen. Bus. Law § 899-aa) defines a narrower "private information" category focused on data-security. bGuru does not currently collect California-defined "sensitive personal information" (Cal. Civ. Code § 1798.140(ae)) — no SSNs, driver's licence numbers, financial-account credentials, precise geolocation, biometric data, health information, sexual orientation, or contents of private communications.

Rest of world (AU / JP / KR / SG / NZ / ZA / UAE / MX / LATAM / MENA / CH). Definitions converge: Australia Privacy Act 1988 App. 1 (APP 1) defines personal information as information about an identified or reasonably identifiable individual; Japan APPI Art. 2(1) (個人情報) covers information enabling identification including personal identification codes (個人識別符号); South Korea PIPA Art. 2(1) (개인정보) covers identifiable information including pseudonymous data that can be re-identified; Singapore PDPA §2 covers data about an identifiable individual; New Zealand Privacy Act 2020 §7 covers information about an identifiable individual; South Africa POPIA §1 covers information relating to an identifiable, living, natural person; UAE Federal Decree-Law No. 45 of 2021 Art. 1 plus DIFC DPL 2020 Art. 1 and ADGM DPR 2021 (the latter two GDPR-aligned); Mexico LFPDPPP Art. 3(V) covers identified or identifiable natural persons (sensitive data under Art. 3(VI)); other LATAM (Argentina Law 25.326 Art. 2; Chile Law 21.719 Art. 2; Colombia Ley 1581/2012 Art. 3; Peru Law 29.733 Art. 2) and other MENA (Saudi PDPL Art. 1; Egypt Law 151/2020 Art. 2; Morocco Law 09-08 Art. 1; Qatar Law 13/2016 Art. 1; Kuwait Reg. 12/2024 Sec. 1) all use functionally equivalent definitions. Switzerland revFADP Art. 5(a) is materially GDPR-aligned. Forward-looking (deferred markets): Brazil LGPD Art. 5(I); India DPDP Act 2023 §2(t) — both will apply when those markets open at v1.1.

§4 Why we collect it (lawful basis)

§4.1 Lawful bases overview

Each category of data we collect from §3.1 is processed under a specific lawful basis. The same mapping applies in substance across all jurisdictions, with jurisdiction-specific terminology in §4.2.

Data category (from §3.1) Lawful basis Why
Account data (email, display name, password hash, OAuth token, profile fields) Contract performance We can't provide the Service without it
Prediction + social data (Picks, conviction, groups, follows, comments) Contract performance This IS the Service
Push notification data (OneSignal player_id, push token, preferences) Consent Explicit opt-in via system permission prompt + soft-prompt logic
Crash + performance data (Sentry) Legitimate interest Service stability + security; minimal data; balancing test applied (see §4.2)
Connection data (IP, session JWT) Legitimate interest Necessary for rate-limiting + security; transient
Account-deletion data (timestamps, grace-period flag) Legal obligation Demonstrates compliance with statutory erasure rights

We do not rely on vital interests (GDPR Art. 6(1)(d)) or public task (Art. 6(1)(e)) for any processing.

§4.2 Jurisdiction-specific lawful bases

European Union / EEA (GDPR Art. 6). Account creation, predictions, groups, and leaderboards are necessary for the performance of the contract per Art. 6(1)(b). Sentry crash data is processed on the basis of legitimate interests per Art. 6(1)(f) — bGuru's interest in maintaining a stable, secure service; the balancing test favours this basis because the data is minimal, retained for at most 30 days (Sentry's default), processed in the EU region (Sentry EU deployment), and does not include directly identifying personal data (no email, no display name). Push notification delivery is processed on the basis of freely given, specific, informed, unambiguous consent per Art. 6(1)(a); consent may be withdrawn at any time via Settings, and withdrawal does not affect the lawfulness of prior processing per Art. 7(3). Account-deletion records are retained under legal obligation per Art. 6(1)(c) and the Art. 17(3)(b) and (e) exceptions.

United Kingdom (UK GDPR Art. 6). Same mapping as EU/EEA. The ICO's "legitimate interests balancing test" (the three-part purpose/necessity/balancing test set out in ICO guidance on Art. 6(1)(f)) has been applied for the Sentry processing; bGuru has assessed that the legitimate interest is not overridden by users' interests, rights, or freedoms, given the strict data-minimisation and pseudonymisation applied. Documentation of the Legitimate Interests Assessment (LIA) is retained internally.

Israel (PPL Amendment 13). The PPL operates through a functionally equivalent framework: processing is lawful if (a) done with the data subject's consent (הסכמה) — the PPL's primary and default ground; (b) required for performance of a legal obligation (חובה חוקית); (c) necessary to perform a contract; or (d) serves a legitimate purpose (מטרה לגיטימית) that does not disproportionately infringe privacy (a ground Amendment 13 codified more explicitly, bringing it closer to GDPR Art. 6(1)(f)). Mapped to bGuru: account + predictions + groups + social = contract performance; Sentry = legitimate purpose with data minimisation; push notifications = explicit consent.

§5 Who we share it with (sub-processors)

bGuru relies on a small number of third-party sub-processors to provide the Service. We name them all explicitly: Supabase (Frankfurt — Postgres, auth, storage), OneSignal (push notifications), Sentry (EU region — crash reporting), API-Football (sports data feed — no user data transmitted), Apple (App Store + APNs), Google (Play Store + FCM), Cloudflare (mini-site CDN + DDoS).

For each sub-processor: the data categories transferred, the purpose, the data residency, and the data-processing agreement (DPA) link are published at bguru.app/legal/subprocessors.

When we add a sub-processor that materially changes the categories of data processed or the data-residency posture, we notify users via the §11 material-change notice flow (30-day notice, in-app banner + email).

We do NOT sell or share Personal Data within the meaning of CCPA/CPRA (Cal. Civ. Code § 1798.140(ad) "sell" or § 1798.140(ah) "share for cross-context behavioural advertising"), VCDPA, CPA, or any other US state law. We do not engage in targeted advertising or profiling for advertising. If this ever changes (per Q6.1, an advertising-supported feature is planned for a future version), we will activate the required opt-out mechanisms (including a "Do Not Sell or Share My Personal Information" link, GPC-signal honouring, and Universal Opt-Out Mechanism / UOM support) before the feature ships, via the §11 material-change notice flow.

§6 International data transfers

bGuru's primary data infrastructure is in Frankfurt, Germany (Supabase EU region), and most sub-processors are also EU-based or hold appropriate transfer safeguards. The paragraphs below describe the legal mechanism for transfers from each major jurisdiction.

§6.1 European Union / EEA — transfers to Israel and to US sub-processors

bGuru is currently operated from Israel. Israel holds an EU Commission adequacy decision (Commission Decision 2011/61/EU of 31 January 2011, transitioned under GDPR Art. 45(9) and confirmed by the Commission's January 2024 periodic review of pre-GDPR adequacy decisions). Transfers from the EU/EEA to bGuru's Israeli controller therefore do not require Standard Contractual Clauses — the adequacy channel applies. (For the avoidance of doubt: if the adequacy decision were to be withdrawn or expire, SCCs Annex I-III per Implementing Decision (EU) 2021/914 plus supplementary measures per Schrems II would apply as a fallback; this Policy will be updated immediately if the adequacy status changes.)

For sub-processors located outside the EU/EEA:

  • Supabase — data hosted in Frankfurt (AWS eu-central-1); no third-country transfer occurs.
  • Sentry — EU region (Frankfurt); no third-country transfer occurs.
  • OneSignal (US) — transfers under Module 2 SCCs (controller-to-processor) per Implementing Decision (EU) 2021/914, supplemented by OneSignal's EU-US Data Privacy Framework (DPF) certification where active.
  • Cloudflare (US) — SCCs per Implementing Decision (EU) 2021/914; Cloudflare also holds DPF certification, which the ICO and Commission have assessed as providing essentially equivalent protection for EEA-to-US transfers.

A copy of the SCCs in force for each sub-processor is available on request via legal@bguru.app.

§6.2 United Kingdom — transfers to Israel and to US sub-processors

For UK users, transfers outside the UK are governed by Chapter V of the UK GDPR. Israel benefits from a UK adequacy regulation made under DPA 2018 s. 17A (reflecting the original EU adequacy decision and maintained in UK domestic law post-Brexit, per Schedule 3 to the UK GDPR (Application, Corrections and Adaptations) Regulations 2019). UK-to-Israel transfers therefore do not require additional safeguards under UK GDPR.

For US-based sub-processors (OneSignal, Cloudflare), bGuru relies on either (a) the International Data Transfer Agreement (IDTA, the UK's post-Brexit successor to the EU SCCs) issued by the Secretary of State under DPA 2018 s. 119A, or (b) the UK Addendum to the EU SCCs (ICO-issued, appended to EU SCCs Decision 2021/914), supplemented by a UK Transfer Risk Assessment (TRA) per ICO guidance. Each of bGuru's US-based sub-processors currently holds EU-US DPF certification, which the ICO has assessed as providing essentially equivalent protection; SCCs/IDTA serve as a contractual backstop.

§6.3 Israel — transfers to EU and to US sub-processors

For Israeli users, transfers are governed by the Privacy Protection Regulations (Transfer of Data Abroad) 5761-2001 / תקנות הגנת הפרטיות (העברת מידע אל מחוץ לגבולות המדינה), תשס"א-2001 + Amendment 13 transfer provisions. Transfers to countries on the PPA's adequacy list (which includes EU/EEA member states) are permitted without additional formalities — bGuru's transfers to Supabase Frankfurt and Sentry EU fall within this channel. Transfers to non-adequate countries (OneSignal US, Cloudflare US) are made under a data-processing agreement that imposes PPL-equivalent protections on the recipient (Israeli equivalent of the SCC mechanism); OneSignal's and Cloudflare's DPAs also incorporate EU SCCs, which the PPA accepts as compatible contractual safeguards.

API-Football: server-side only, no personal data of bGuru users is transmitted; outside the Regulations' scope.

§7 How long we keep your data

The retention period varies by data category. Where multiple bases for retention apply (e.g., a user account is active AND under legal-hold), the longest applicable period applies.

Data category Retention
Account data (email, display name, password hash, OAuth token, profile fields) Indefinite while account is active; 30-day grace period after deletion request, then hard-deleted per ToS §10
Predictions, picks, conviction scores Indefinite while account is active; severed from your identity on hard-deletion (anonymised aggregates retained — no longer Personal Data)
Group memberships, follows, comments, reactions Same as Predictions
Push notification tokens + preferences Until you revoke consent (via Settings or device system settings) or account deletion completes
Sentry crash + performance data 30 days (Sentry default; matches the free Developer tier)
Connection data (IP, session JWT) Transient — IP held in memory for rate-limiting ~24 hours; JWT lifespan controlled by Supabase Auth (rotates on sign-out)
Account-deletion records (timestamps, grace-period state) Retained for as long as required to demonstrate compliance with statutory erasure obligations; minimum 12 months
Backups Per Supabase backup-rotation cycle (default 7 days); deletion requests are honoured against backups as the rotation cycles
Aggregated, de-identified statistics Indefinite — no longer Personal Data once de-identified per the standards in GDPR Recital 26 + IL PPL guidance

§8 Your rights

§8.1 Rights you have everywhere

Regardless of jurisdiction, you have the following rights over your Personal Data held by bGuru:

  • Access — see what we have about you.
  • Rectification / correction — fix what's wrong.
  • Erasure / deletion — ask us to delete (subject to legal-obligation exceptions; see Terms of Service, §10 Account deletion).
  • Restriction of processing — ask us to pause processing while a dispute is resolved.
  • Objection — object to processing based on legitimate interest (currently only Sentry crash data).
  • Portability — receive a copy of the data you've provided to us in a structured, machine-readable format (manual export at MVP; in-app export planned for a future version).
  • Withdraw consent — for processing based on consent (push notifications), at any time, without affecting the lawfulness of prior processing.

How to exercise (any jurisdiction):

  1. In-app: Settings → Privacy → Exercise rights (where available)
  2. Email: legal@bguru.app (include your account email + which right you're exercising)
  3. We respond within one month per GDPR Art. 12(3) and equivalent obligations, with a two-month extension where the request is complex (you'll be notified of any extension within the first month).

§8.2 Jurisdiction-specific rights

European Union / EEA (GDPR Art. 15–22). Specific rights: access (Art. 15), rectification (Art. 16), erasure / "right to be forgotten" (Art. 17 — cross-ref ToS §10 + Art. 17(3) exceptions), restriction (Art. 18), portability (Art. 20 — structured, commonly-used, machine-readable format), objection (Art. 21 — including to the Sentry processing described in §4.2), automated-decision-making rights (Art. 22 — bGuru does not make solely-automated significant decisions about individuals; the prediction engine generates probabilities for sports events, not decisions about you). Right to complain to the supervisory authority in your member state of habitual residence — for example, the Data Protection Commission (DPC) in Ireland (dataprotection.ie), the Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) in Germany (bfdi.bund.de), the Garante per la protezione dei dati personali in Italy (garanteprivacy.it), Agencia Española de Protección de Datos (AEPD) in Spain (aepd.es), or the supervisory authority of any other EU/EEA member state in which bGuru has an establishment or the place of processing.

United Kingdom (UK GDPR Art. 15–22 + DPA 2018). Same rights as EU/EEA. UK-specific complaint channel: Information Commissioner's Office (ICO): Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF; casework@ico.org.uk; 0303 123 1113; ico.org.uk/make-a-complaint. You also have the right to bring proceedings in the courts of England and Wales (or Scotland, or Northern Ireland, as applicable) if you consider bGuru has infringed your rights, independently of any ICO complaint.

Israel (PPL Amendment 13 §§13–17). Right of access (§13), right of correction (§14), right of deletion (§17 — cross-ref ToS §10), right to data portability (§15A — Amendment 13's portability right; honoured by manual export at MVP, in-app automated export planned for a future version), right to object / restrict processing (§16). Right to complain to the Privacy Protection Authority (PPA / רשות להגנת הפרטיות): 3 Kaplan Street, Jerusalem 9195020; gov.il/en/departments/the_privacy_protection_authority; rmot.regulation@justice.gov.il. Israeli-resident consumers retain the right to bring proceedings in any Israeli court of competent jurisdiction in their district of residence (see ToS §14.1).

United States — California (CCPA/CPRA, Cal. Civ. Code §§ 1798.100–1798.199.100). Right to know (§ 1798.110), right to delete (§ 1798.105 — subject to the § 1798.105(d) exceptions), right to correct (§ 1798.106), right to opt out of sale/sharing (§ 1798.120 — bGuru does not currently sell or share within these statutory meanings; if this ever changes, the "Do Not Sell or Share" link + GPC-signal honouring will be activated before the change), right to limit use of sensitive PI (§ 1798.121 — bGuru does not currently process sensitive PI per §3.2 US), right to non-discrimination (§ 1798.125). Data-breach private right of action (§ 1798.150 — statutory damages $100-$750 per consumer per incident or actual damages, plus injunctive/declaratory relief, for failure to implement reasonable security). Shine the Light (§ 1798.83 — request via legal@bguru.app subject line "Shine the Light Request"; bGuru does not currently share PI with third parties for their own direct marketing). Global Privacy Control (GPC) is honoured as a valid opt-out signal per CPPA Final Regulations § 7025(c). Complaints to the California Privacy Protection Agency (CPPA) at cppa.ca.gov/complaints.

United States — other states (VCDPA / CPA / CTDPA / UCPA / TDPSA / OCPA / MCDPA (MT) / NJDPA / INDPA / KYDPA / RIDTPPA / TIPA / DPDPA / ICDPA / NDPA / NHPA / MODPA / MN MCDPA). Residents of Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, New Jersey, Indiana, Kentucky, Rhode Island, Tennessee, Delaware, Iowa, Nebraska, New Hampshire, Maryland (MODPA — heightened data-minimisation + profiling restrictions; bGuru's posture aligns), and Minnesota have rights mirroring the CCPA framework: access, correction, deletion, opt-out of sale + targeted advertising + profiling (bGuru does not engage in any of these three at MVP), and portability. Colorado CPA (C.R.S. § 6-1-1315) requires honouring the Universal Opt-Out Mechanism (UOM); bGuru's CMP is configured to honour this. Enforcement is by each state's Attorney General; none of these state laws provides a private right of action (in contrast to CCPA § 1798.150 for data-breach claims). Request channel: same as universal (Settings or legal@bguru.app), subject line "US Privacy Rights Request" + state. Response within 45 days (CCPA outer limit + state equivalents), with one 45-day extension on notice.

United States — New York (SHIELD Act, NY GBL §§ 349–350, SAFE for Kids Act). SHIELD Act (N.Y. Gen. Bus. Law § 899-aa, § 899-bb) imposes data-security obligations on businesses holding NY residents' "private information"; bGuru's reasonable safeguards under § 899-bb are described in §10. Breach-notification under § 899-aa is addressed in §10; bGuru applies the strictest 72-hour benchmark for primary regulator notifications. NY GBL §§ 349-350 (deceptive acts and false advertising) preserves NY residents' private right of action ($50 minimum, up to $1,000 for wilful violations, plus attorneys' fees). NY SAFE for Kids Act (2024) — bGuru does not operate an algorithmic content-recommendation feed, so it is not currently a "social media platform" within the Act; if this changes, bGuru will assess compliance before the change ships.

Rest of world — your rights by jurisdiction.

  • Australia (Privacy Act 1988, APPs 12–13): right of access (APP 12) and right of correction (APP 13). Complaints to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au.
  • Japan (APPI Arts. 28–35, as amended 2022): disclosure (Art. 33), correction (Art. 34), addition/deletion (Art. 34), suspension of use (Art. 35), third-party-provision stoppage (Art. 35), erasure (Art. 35). Complaints to the Personal Information Protection Commission (PPC, 個人情報保護委員会) at ppc.go.jp.
  • South Korea (PIPA Arts. 35–39): access (Art. 35), correction/deletion (Art. 36), suspension (Art. 37), compensation (Art. 38), complaints (Art. 39). Complaints to the Personal Information Protection Commission (PIPC, 개인정보보호위원회) or the Korea Internet & Security Agency (KISA) at privacy.go.kr.
  • Singapore (PDPA, Part V — Access and Correction Obligation): access (§ 21), correction (§ 22). 30-day response (extendable). Complaints to the Personal Data Protection Commission (PDPC) at pdpc.gov.sg.
  • New Zealand (Privacy Act 2020, IPP 6–7): access (IPP 6), correction (IPP 7). Complaints to the Office of the Privacy Commissioner (OPC) at privacy.org.nz.
  • South Africa (POPIA §§ 23–25): notification (§ 23), correction/destruction/deletion (§ 24), record of correction request (§ 25). Complaints to the Information Regulator (South Africa) at inforegulator.org.za.
  • UAE (UAE PDPL Arts. 13–19; DIFC DPL 2020; ADGM DPR 2021): access (Art. 13), correction (Art. 14), erasure (Art. 15), restriction (Art. 16), portability (Art. 17), objection (Art. 18). 30-day response. Complaints to the UAE Data Office, DIFC Commissioner of Data Protection, or ADGM Registration Authority as applicable.
  • Mexico (LFPDPPP Arts. 22–29 — ARCO rights): Access (Acceso), Rectification (Rectificación), Cancellation (Cancelación), Opposition (Oposición). 20-business-day response, 15-business-day implementation. Complaints to INAI at inai.org.mx.
  • Other LATAM (AR / CL / PE / CO): rights are functionally equivalent to ARCO (access, rectification, suppression/cancellation, objection). Argentina — AAIP enforcement; Chile — Law 21.719 (fully effective 2026); Colombia — SIC; Peru — APDP. Same channel: legal@bguru.app.
  • Other MENA (SA / EG / MA / QA / KW): access + correction + erasure + objection rights under each national PDPL. Same channel: legal@bguru.app. 30-day response standard.
  • Switzerland: revFADP Art. 25 (access right), Art. 32 (rectification + erasure rights). The Federal Data Protection and Information Commissioner (FDPIC) enforces.

Forward-looking (deferred markets — v1.1): When Brazil opens, LGPD Arts. 17–22 rights will apply (ANPD enforcement). When India opens, DPDP Act 2023 ss. 11–14 rights will apply (Data Protection Board enforcement, once constituted). When Canada opens (excluding Quebec until FR-CA translation lands), PIPEDA + provincial laws will apply. When France or Belgium re-open, GDPR rights described above will apply per CNIL / APD-GBA / DGCN respectively.

§9 Children's data

§9.1 Coordinator framing

bGuru sets a flat minimum age of 16 in all jurisdictions in which the Service is available (see Terms of Service, §3 Age eligibility). bGuru does not knowingly collect Personal Data from any user under 16.

If we discover that a registered user is under 16, we hard-delete the account and associated Personal Data without further notice; for users discovered to be under 13, we apply the COPPA immediate-deletion process described in §9.2 (the standard 30-day grace period does NOT apply to under-13 accounts — federal law requires immediate deletion). For users discovered to be aged 13–15 (above COPPA but below bGuru's 16+ gate), the same hard-deletion treatment applies per bGuru's contractual gate, though without the COPPA-specific immediate-deletion timeline.

Important nuance for users aged 16–17. A small number of jurisdictions require parental consent for users under 18 (not just under 16) for the processing of their Personal Data: South Africa (POPIA s. 35), UAE (PDPL Art. 8), Mexico (LFPDPPP + Mexican civil law), and several LATAM/MENA jurisdictions. bGuru's 16+ gate does not eliminate the under-18 parental-consent requirement in these jurisdictions. At MVP, bGuru applies the most restrictive data-minimisation and no-behavioural-targeting treatment to all users under 18 globally as a partial mitigation; the parental-consent gap for 16–17 users in these specific jurisdictions is a calibrated risk acceptance under the same pattern as the Art. 27 representative deferral. The v1.1 parental-consent provider integration will close this gap.

§9.2 United States — COPPA hard-block and state minor-data laws

COPPA — federal hard-block for users under 13 (15 U.S.C. §§ 6501–6506; 16 CFR Part 312). bGuru is not directed to children under 13 and does not seek verifiable parental consent ("VPC"); bGuru's 16+ minimum age gate is designed to prevent any user under 13 from registering. If bGuru obtains actual knowledge that a registered user is under 13 (the COPPA standard, per 16 CFR § 312.3), bGuru will: (1) immediately and permanently suspend access to the account; (2) delete all personal information collected from or about that user from active systems, without retention of any identifying data, except where required to comply with a legal obligation or to exercise or defend legal claims; (3) notify the parent or guardian if contact information is available; and (4) process any inadvertent paid-tier charge as a refund. This hard-deletion obligation applies regardless of any parental consent obtained outside the Service; no VPC mechanism can authorise a sub-13 account under these Terms or this Policy. The FTC enforces COPPA. bGuru does not employ cookie-fingerprinting, device-fingerprinting, or any mechanism designed to identify users as minors for tracking or targeted-advertising purposes.

State minor-data laws (users under 18). California — SB-976 (KOSMA, Cal. Civ. Code § 1798.99.29 et seq.): bGuru's client-side gated push-notification prompt (explicit opt-in before any push notifications are sent) satisfies KOSMA's consent-before-notification requirement; bGuru does not currently operate an algorithmically curated content-recommendation feed, so is not currently a "social media platform" within KOSMA for the addictive-design restrictions. New York SAFE for Kids Act (2024): same analysis. Maryland MODPA (Md. Code Com. Law § 14-4601 et seq.): bGuru's MVP data-minimisation posture + no-behavioural-targeting + no-profiling-of-under-18 alignment satisfies MODPA's heightened requirements. Colorado CPA minor-data provisions (C.R.S. § 6-1-1306(4)): bGuru does not sell PI and does not engage in targeted advertising. Florida HB 3 (2024, Fla. Stat. § 501.1736 et seq.): bGuru does not operate an algorithmic feed and is not currently within scope. Blanket policy: bGuru applies no-behavioural-targeting to all users under 18 globally, providing forward-looking compliance for any additional state minor-data laws enacted between updates of this Policy.

§9.3 United Kingdom + European Union — under-18 protections at the 16+ baseline

United Kingdom (ICO Age Appropriate Design Code). The ICO Children's Code (issued under DPA 2018 s. 123) applies to any online service "likely to be accessed by children" — defined as persons under 18 — regardless of the minimum age set by the service. Because bGuru's 16+ gate still admits users aged 16-17, the Code applies. bGuru designs its Service to meet the Code's 15 standards for 16- and 17-year-old users:

  • No profiling of under-18 users for behavioural advertising, interest-based targeting, or any purpose unrelated to providing the prediction and social-ranking features.
  • No targeted or interest-based advertising to any user under 18 at any version (the restriction is at under-18, not merely under-16).
  • Default privacy settings for under-18 users: leaderboard visibility defaults to followers-only, profile visibility defaults to private until the user actively changes.
  • Data minimisation for under-18 users: only what is strictly necessary to provide the Service.
  • No nudge techniques, no compulsive-use gamification mechanics, no default-on notifications for users under 18.

bGuru's 16+ baseline exceeds the UK digital-consent age of 13 (set by DPA 2018 s. 9 and confirmed by the DPDI Act 2025), but that higher sign-up age does not exempt bGuru from its Children's Code duties towards 16-17 year-old users.

European Union / EEA (GDPR Art. 8 + DSA Art. 28). GDPR Art. 8 sets the digital-consent age between 13 and 16 by member state; bGuru's flat 16+ gate is at-or-above every EU/EEA member state's Art. 8 threshold, so no per-member-state parental-consent flow is required at this version of the Service. For users aged 16 and 17, DSA Art. 28 (Regulation (EU) 2022/2065) requires online platforms to implement appropriate and proportionate measures to ensure a high level of privacy, safety, and security for minors. bGuru's compliance at MVP rests on: (i) no algorithmic content-recommendation feed and no personalisation system based on profiling — the Art. 28(2) recommender-system interface-design obligations do not apply; (ii) no behavioural or interest-based advertising to any user, including 16–17 year-olds, consistent with the no-ads MVP posture; (iii) no profiling of under-18 users for purposes beyond the core Service. bGuru will reassess if an algorithmic-feed or behavioural-advertising feature is introduced.

§9.4 Rest of world — under-18 protections by jurisdiction

Australia. Online Safety Amendment (Social Media Minimum Age) Act 2024 establishes 16 as the minimum age for social media services; bGuru's 16+ gate satisfies natively. Privacy Act 1988: OAIC treats under-13 as requiring heightened protections; bGuru's 16+ gate exceeds this. bGuru does not collect, process, or knowingly permit access to any Australian user under 16; on actual knowledge, the account is immediately hard-deleted per §9.1.

Japan. APPI does not set a fixed digital-services minimum age; common industry practice treats 16 as the operative threshold. bGuru's 16+ gate aligns.

South Korea. PIPA Art. 22(6) requires VPC for users under 14; bGuru's 16+ gate is above. For 16-17 year-old users (who are "youth" under the Youth Protection Act, 청소년 보호법), bGuru applies the same no-behavioural-targeting + explicit-opt-in posture as elsewhere, consistent with PIPA's strict opt-in regime.

Singapore + New Zealand. Neither PDPA nor Privacy Act 2020 sets a statutory minimum age for digital services; bGuru's 16+ gate exceeds the regulatory-guidance threshold (under-13 in SG; under-16 in NZ). Standard PDPA / Privacy Act 2020 protections apply for 16-17 users.

South Africa, UAE, Mexico, other LATAM, other MENA. POPIA s. 35, UAE PDPL Art. 8, LFPDPPP + Mexican civil law, and the LATAM/MENA cluster all require parental consent for users under 18. bGuru's 16+ gate does not eliminate this requirement for 16-17 year-old users in these jurisdictions. Calibrated risk acceptance at MVP — bGuru does not knowingly register users under 18 in these markets, applies maximum data-minimisation + no-behavioural-targeting treatment to all under-18 users globally, and will integrate a managed parental-consent provider at v1.1 to close this gap. Enforcement against indie operators for the 16-17 sub-band is rare; the documented mitigation posture is in the same risk class as the Art. 27 representative deferral.

Forward-looking (deferred markets — v1.1). Brazil — Digital ECA (Law 15.211/2025) imposes a hard block for under-12s, requires parental consent for 12-17, and prohibits profile-based advertising to under-18s; bGuru's planned parental-consent provider integration satisfies this. India — DPDP Act 2023 s. 9 requires VPC for under-18s; same v1.1 parental-consent provider integration. Canada — depending on which Path A/B is taken for the Quebec FR-language commitment, parental-consent flow may or may not be required at v1.1 entry.

§10 Security and breach notification

Security. bGuru implements reasonable technical and organisational measures appropriate to the risks of the processing, the nature of the Personal Data, and the size of the operation. These include: TLS in transit for all client–server and server–server traffic; encryption at rest (Supabase default); strict access control via JWT with short-lived sessions; password hashing (bcrypt via Supabase Auth, never stored in plaintext); the Sentry beforeSend PII-scrubber to prevent accidental logging of identifying data; periodic dependency-vulnerability scanning; sub-processor due diligence per the criteria in the sub-processor list; and the controls documented in the security section of the internal architecture documentation.

We comply with the New York SHIELD Act § 899-bb reasonable-safeguards obligation through these measures.

Breach notification. In the event of a Personal Data breach (defined as a security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data — GDPR Art. 4(12) and equivalent), bGuru will notify the relevant supervisory authority and affected users in accordance with applicable law:

  • GDPR Art. 33 (EU/EEA users) — supervisory-authority notification within 72 hours of awareness, unless the breach is unlikely to result in a risk to data subjects.
  • GDPR Art. 34 (EU/EEA users) — direct user notification without undue delay when the breach is likely to result in a high risk.
  • UK GDPR — same 72-hour SLA to the ICO.
  • IL PPL Amendment 13 — without unnecessary delay; bGuru applies the GDPR-aligned 72-hour benchmark for the PPA as well (the PPA's implementing guidance permits up to 60 days for "severe security events" but the operational standard is faster).
  • US state laws — without unreasonable delay (CA Civ. Code § 1798.82, NY SHIELD Act § 899-aa, and 48 other state breach-notification statutes); bGuru applies the same 72-hour benchmark uniformly.
  • Rest of world — Australia 30 days (NDB scheme), New Zealand 72 hours (Privacy Act 2020 s. 114), Japan 3–5 days (APPI 2022 Art. 26), South Korea 72 hours (PIPA 2023 amendment), Singapore 3 calendar days (PDPA First Schedule), South Africa "as soon as reasonably possible" (POPIA s. 22), UAE "without undue delay" (PDPL + Executive Regulations 2024), MX/LATAM/MENA "without undue delay."

bGuru maintains an internal breach-notification playbook (regulator-notification template, user-notification template, hour-by-hour response) and applies a uniform 72-hour benchmark for all primary regulator notifications, regardless of jurisdiction, as the strictest binding SLA in the bGuru market portfolio.

§11 Changes to this Privacy Policy

We may change this Privacy Policy from time to time. For material changes — changes that meaningfully affect your rights or the way we process your Personal Data — 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. For non-material changes (typographical corrections, clarifications, references to new help-doc pages), we may publish an updated version without 30 days' 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 as soon as practicable thereafter (and in all cases within 7 days).

If you continue to use the Service after the effective date of a change, you are bound by the updated Privacy Policy. If you do not agree to a change, your remedy is to stop using the Service and to delete your Account (Terms of Service, §10 Account deletion).

EU/EEA users (DSA Art. 12). If you are a user in the EU/EEA, you have the right, during the 30-day notice period for any material change to this Privacy Policy, to terminate your use of the Service and to delete your Account under Terms of Service, §10 Account deletion free of any penalty. We will remind you of this right in any material-change notification.

§12 Contact us

For any data-protection inquiry — exercising your rights under §8, asking about anything in this Policy, or raising a concern about how we handle your data — 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) and equivalent obligations, and faster on urgent matters.

Sole-proprietorship posture. bGuru is currently operated as a sole-proprietorship project of an Israeli resident (see §2). The legal@bguru.app channel is staffed personally by the founder until the entity decision lands post-MVP, at which point a formal contact structure will be published via the §11 material-change notice mechanism.

EU/EEA users — Article 27 representative. We are working to appoint an EU/EEA representative under GDPR Article 27. The name, address, and contact details of our appointed representative will be published in this section once the appointment is confirmed (target: MVP+1). In the meantime, legal@bguru.app is the direct contact channel for EU/EEA users and supervisory authorities. You have the right to lodge a complaint with the supervisory authority of your member state of habitual residence — see §8.2 for the named EU/EEA supervisory authorities.

UK users — Article 27 representative. Same posture. legal@bguru.app is the interim channel. Complaints to the ICO per §8.2.

Israeli users — PPA contact. Complaints to the Privacy Protection Authority (PPA / רשות להגנת הפרטיות): 3 Kaplan Street, Jerusalem 9195020; gov.il/en/departments/the_privacy_protection_authority; rmot.regulation@justice.gov.il.

US users — state-specific contacts are in §8.2 (California Privacy Protection Agency / state Attorneys General). Federal: FTC for COPPA matters.

Rest of world — supervisory authority contacts are in §8.2 by jurisdiction.

§13 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 per Q5. Sole-developer + brand-as-identity controller posture per Q12. 16+ flat age gate per Q12. Sentry at MVP (EU region, free tier, Pattern C disclosure) per Q6.2. No ads / no IDFA / no GAID per Q6.1/Q6.3. Canada / France / Belgium / Brazil / India deferred to v1.1 per Q10/Q12. Israel adequacy with EU confirmed per Commission Decision 2011/61/EU + 2024 review. Specialist drafts merged 2026-05-31; flags from legal-global about ZA/UAE/MX 16–17 parental-consent gap incorporated in §9.1 + §9.4 as a calibrated risk acceptance pattern. unreviewed (specialist whole-doc review round pending; attorney sign-off deferred to MVP+30d per Q4)