Privacy Policy

Status: self-authored draft (AI-assisted), appropriate for the current closed-beta scale. This notice is drafted to satisfy the information obligations of GDPR Article 13 (information to be provided where personal data are collected from the data subject) and the device-access consent rule of Article 5(3) of the ePrivacy Directive 2002/58/EC (as amended by 2009/136/EC). It also reflects Apple App Store Guideline 5.1.1(i) and Google Play's User Data / Data safety requirements. These documents are not legal advice and are not a substitute for a professional review — a lawyer review is recommended as the user base and data processing grow, and is advisable before enabling ID/biometric verification. Items marked [LEGAL REVIEW: …] flag a substantive legal judgement to finalise in such a review.

Last updated: 18 June 2026 (current draft date, adjustable) Applies to: the Flybi mobile application ("Flybi", "the app", "we", "us")

Flybi is operated by:

Controller: Nicholas Gerster Toft Simonsen, operating Flybi as a private individual / sole operator (not a registered company), based in Aarhus, Denmark.
CVR number / registered entity: Operated by Nicholas Gerster Toft Simonsen as a private individual; no CVR (company registration) yet — a registered company and CVR will be added as the project grows.
Postal address: Contact is by email at the address below; a postal address will be added when a company is registered. (At the current scale, email contact satisfies the GDPR Art 13 controller-contact requirement.)
Contact e-mail: ngts91@gmail.com (this will move to a company/branded address as the project grows). This is the contact for support and for privacy/data-protection matters.
Privacy policy URL: https://flybi.app/privacy (the canonical URL referenced as LegalLinks.privacyPolicyUrl; to be published before store submission).

EU representative (GDPR Art 27): Not applicable — the controller is established in the EU (Denmark). Art 27 applies only to controllers not established in the Union (Art 3(2)). The Danish establishment is itself the contact point for the supervisory authority and for data subjects.

No Data Protection Officer is appointed; one is not legally required at the current scale. The controller (Nicholas Gerster Toft Simonsen, ngts91@gmail.com) is the contact for privacy matters. This position is re-assessed if scale grows or biometric/ID verification is enabled. We do not consider a DPO mandatory under GDPR Art 37(1): we are not a public authority, and our core activity is operating a single consumer app rather than large-scale monitoring or large-scale special-category processing as our core business in the Art 37 sense. [LEGAL REVIEW: re-confirm no DPO is mandatory given the large-scale location processing described in Section 4 — Art 37(1)(b) "regular and systematic monitoring of data subjects on a large scale". If a DPO is appointed, add their contact details here.]

Flybi is an 18-and-over service. You must be at least 18 to create an account. We do not knowingly process the personal data of anyone under 18.

At registration you must confirm acceptance of our Terms/EULA, and during onboarding we collect a date of birth to operate an 18+ age gate (stored as dateOfBirth on your profile — see Section 4).
Under GDPR Art 8 the age at which a child may self-consent to information society services is 16, which Member States may lower to no less than 13. Denmark set this at 13 via the Danish Data Protection Act (Databeskyttelsesloven) § 6(2). Because Flybi is an adults-only (18+) service, that age-of-consent threshold does not in practice apply to our user base — our binding rule is our own 18+ minimum age.
GDPR Art 6(1)(f) legitimate-interest balancing expressly weighs against processing "in particular where the data subject is a child." Our age gate exists precisely to keep minors off an adults' service.

If we learn that a user is under 18, we will close and erase the account.

The table below lists each category of personal data, the purpose, and the lawful basis under GDPR Art 6 (and, where relevant, the special-category condition under Art 9(2)). The field names in brackets are the actual Firestore fields (see lib/core/constants/firestore_fields.dart) and are given for transparency.

3.1 Account & authentication

Data: e-mail address; authentication identifiers from your chosen sign-in provider (e-mail/password, Google, or Apple). (email)
Purpose: to create and secure your account and let you sign in.
Lawful basis: Art 6(1)(b) — performance of a contract (you cannot use the service without an account). Where you sign in with Apple, we honour Apple's private-relay e-mail.
Provision: providing an e-mail/identifier is a contractual requirement (Art 13(2)(e)); without it the service cannot be provided.

3.2 Profile & personality

Data: display name (displayName); biography text (bio); profile and tag photos (photoUrl, stored in Firebase Storage); your personality / Big Five self-assessment and its chosen visibility (personality); displayed badges and member number (displayedBadges, signupOrdinal); locale (locale).
Purpose: to present you to other users — in Flybi "the people are the content" — so others can discover and connect with you.
Lawful basis: Art 6(1)(b) contract for the core profile needed to deliver discovery; Art 6(1)(a) consent for genuinely optional enrichment fields you choose to add (e.g. an optional bio/photo or making your personality profile visible). [LEGAL REVIEW: confirm the contract/consent split per field; consent fields must be separately and freely given.]
Provision: a minimal profile is a contractual requirement; optional fields are voluntary and may be left blank.

3.3 Interests as "tags", including secret tags

Data: the interest tags you add to your profile, each marked as an identity or seeking intent, and optionally flagged secret (isSecret); secret tags are only revealed to another user through a mutual reveal handshake (reveal_requests).
Purpose: to find and surface the people who best fit you, and to power the shared-interest discovery experience.
Lawful basis: Art 6(1)(b) contract (surfacing best-fit people is the core service).
⚠️ Special category — Art 9. Free-text tags and "seeking" preferences can reveal special-category data under Art 9(1) — for example sexual orientation, religious or philosophical beliefs, or health. Where they do, the lawful condition is Art 9(2)(a) explicit consent (in addition to the Art 6 basis), or Art 9(2)(e) where you have manifestly made the data public yourself by publishing it on your profile. [LEGAL REVIEW: assess the tag / "seeking-chip" data model against Art 9. If orientation/seeking is processed as special-category data, implement an explicit-consent step and reflect it here.]

3.4 Location — discovery (coarse area) — see also Section 9 (ePrivacy)

Data: your device location. When you use discovery, the app reads your device GPS and writes to your profile both (a) coarse-area geohash indexes — geohash4 (~39 km cell) and geohash6 (~1.2 km cell) — used to find people in your ring, and (b) the precise latitude/longitude point (location.latitude / location.longitude), which is retained and used to post-filter candidates by exact distance.
Purpose: to show you people within your selected radius and to compute distances for discovery and the optional soulmate scan.
Lawful basis: Art 6(1)(a) consent. For precise/continuous location in a consumer service, consent is the only defensible basis (a legitimate- interest balancing under Art 6(1)(f) is generally overridden for precise location). Your consent is specific, granular and withdrawable (see Sections 7 and 9) and is not bundled into the general Terms.
⚠️ [LEGAL REVIEW / MINIMISATION — Art 5(1)(c)]: the code stores the raw latitude/longitude on the profile alongside the coarse geohashes (DiscoveryRepositoryImpl.updateUserLocation), not only a coarse value. Under the data-minimisation principle this should be reviewed: consider storing only the geohash (or a deliberately rounded coordinate) for the discovery feature, and computing exact distance transiently. If precise storage is retained, this notice and the DPIA (Section 12) must say so plainly, as it does here.
Provision: location is optional — declining the OS location permission disables nearby discovery but you can otherwise use the app. We will not gate unrelated functionality on granting location.

3.5 Location — live "Hot/Cold" game (real-time precise distance)

What happens: the Hot/Cold game is a real-time, two-player game that runs only inside an active, mutually-accepted game between you and one other user in your direct chat. While the game is active:
your device GPS is polled about every 5 seconds on your device to keep the warmer/colder tint responsive;
the other player's current precise position is read live from their profile location field (via a real-time listener) and the distance between you is computed on-device (haversine);
only distance labels and the colour tint (e.g. "Getting warmer", "🔥 Burning!") are exchanged as in-chat system messages — not raw coordinates;
the game auto-quits if you drift more than ~5 km apart, and either player can quit at any time.
Purpose: to play the consensual real-time proximity game.
Lawful basis: Art 6(1)(a) consent — both players must actively invite and accept the game, which is a specific, freely-given, withdrawable consent to share live precise distance for that session.
⚠️ [LEGAL REVIEW — accuracy of the "ephemeral, cleared-after" claim]: in the current implementation the opponent's precise position consumed during the game is the same location value used for discovery (Section 3.4), refreshed as each player moves; there is not a separate ephemeral fine-GPS document that is created for and wiped after the game. The live game does not itself persist a new location record beyond what Section 3.4 already stores. Confirm this description reflects the shipped build and the founder's intended design (lib/app/chat_room_game_wrapper.dart, firestore.rules → hot_cold_game). If a separate live-GPS broadcast that is cleared after the game is later built, update this section.

3.6 Chat messages

Data: the text and images you send in direct and group chats (chat_rooms/*/messages → text, imageUrl, senderEmail, sentAt); room membership and metadata; in-chat system messages.
Purpose: to deliver the messaging feature.
Lawful basis: Art 6(1)(b) contract for message delivery; safety screening of message content (the disallowed-language filter, Section 5) rests on Art 6(1)(f) legitimate interests (keeping users safe) and, where applicable, Art 6(1)(c) legal obligation.
Note: a message you send is also received by the other participant(s). Their copy may persist in their conversation even after you delete your account (see Sections 6 and 8).

3.7 Safety: reports, blocks & moderation

Data: user reports you submit or that concern you (user_reports: reporter/reported identity, reason, free-text details, and a snapshot of the shared chat context); your block lists (blockedUserIds, blockedEmails); and the moderation audit trail (actionTaken, actionedBy, actionedAt, statementOfReasons, slaDeadline).
Purpose: to keep users safe, to action abuse, to meet our content- moderation obligations, and to defend against or bring legal claims.
Lawful basis: Art 6(1)(f) legitimate interests (the safety of our users and the integrity of the platform — the specific legitimate interest required by Art 13(1)(d)), and Art 6(1)(c) legal obligation where the EU Digital Services Act notice-and-action duties (DSA Art 16–18) apply.
Reports are handled under our internal notice-and-action procedure: each report is reviewed (target: within ~24 hours), an action is taken or declined, and a statement of reasons is recorded against the report.

3.8 Date of birth / 18+ age gate

Data: your self-declared date of birth (dateOfBirth).
Purpose: to enforce the 18+ age gate and prevent minors using an adults' service.
Lawful basis: Art 6(1)(c) legal obligation and/or Art 6(1)(f) legitimate interests (age assurance / child protection).
Minimisation note (Art 5(1)(c)): we store the full date of birth. [LEGAL REVIEW: consider storing only a verified "over-18" flag plus the verified date rather than the full DOB where the feature allows, to minimise the data held.]

3.9 Push notifications & device tokens

Data: Firebase Cloud Messaging (FCM) device tokens (fcmTokens) and your notification preferences (notificationPreferences).
Purpose: to send the in-app notifications you have enabled (chat messages, requests, game invites, strong-fit alerts, etc.).
Lawful basis: Art 6(1)(b) contract for service notifications you have configured; Art 6(1)(a) consent via the OS notification permission.

3.10 Technical, security & abuse-prevention data

Data: rate-limit markers (rate_limits), App Check signals, crash and diagnostic data from the Firebase SDKs, and server logs (which may include technical identifiers).
Purpose: to operate, secure and debug the service and to prevent abuse.
Lawful basis: Art 6(1)(f) legitimate interests (security, fraud and abuse prevention, service reliability).

3.11 Best-fit / ML signals

Data: server-computed best-fit embedding vector (embeddingVector), connection-outcome rows used to improve who we surface (connection_outcomes), encounter records and streak stats (flybi_encounters, flybi_user_stats).
Purpose: to compute and improve who we surface to you.
Lawful basis: Art 6(1)(b) contract (surfacing best-fit people) and Art 6(1)(f) legitimate interests (improving how well we surface people).

3.12 Advertising — not active at launch

At launch Flybi shows no advertising. The Google AdMob SDK is integrated but ships disabled ("dark"), and we do not use your data for advertising, behavioural targeting, or ad measurement. There is therefore no Art 6 basis claimed for advertising at this time. If advertising is later enabled, we will update this notice first and, for any behavioural/targeted advertising or device-storage access for ads, obtain your Art 6(1)(a) consent (and the separate ePrivacy device-access consent — Section 9) and, on iOS, your App Tracking Transparency permission before any tracking occurs.

Flybi uses automated processing to rank and surface profiles (best-fit and soulmate/strong-fit scans) and an automated text filter to screen names, bios and chat for disallowed language. These help us run the service and keep it safe.

We do not make decisions producing legal effects concerning you or similarly significantly affecting you solely by automated means within the meaning of Art 22(1). Moderation actions that restrict an account or content (warn / hide / suspend) are taken by a human moderator, who issues a statement of reasons (DSA Art 17). [LEGAL REVIEW: confirm the automated language filter that blocks content at entry is positioned as a content rule, not an Art 22 automated decision with significant effect; if any automated suspension is added, an Art 22 safeguard + this disclosure must be expanded.]

5. How we keep the service safe

We operate: an in-app report flow and block capability; a human moderation process with a ~24-hour review target, statements of reasons, and warn/hide/suspend actions; a disallowed-language filter on names, bios and chat; an 18+ age gate; and Terms/EULA acceptance at registration. These underpin the safety processing described in Sections 3.6–3.8.

6.1 Other users

By design, your profile (name, photo, bio, public tags, approximate area, badges and — if you make it visible — your personality profile) is shown to other signed-in users so they can discover and connect with you. Chat content is shared with the people in that conversation. Secret tags are shared only via a mutual reveal.

6.2 Processors (sub-processors) acting on our instructions

We use Google Firebase as our backend processor (the contracting Google entity — e.g. Google Ireland Limited and/or Google LLC, as applicable under Google's Cloud/Firebase terms). The specific services are:

Cloud Firestore — profile, tags, chat, reports and related documents;
Firebase Authentication — sign-in (email/Google/Apple);
Firebase Storage — profile and tag images;
Cloud Functions (region europe-west1, Belgium) — server-side logic including the account-erasure cascade and moderation triggers;
Firebase Cloud Messaging (FCM) — push notifications;
Firebase Remote Config and Firebase App Check — configuration and anti-abuse attestation.

Google processes this data on our behalf as a processor under the Google Cloud / Firebase Data Processing Terms (an Art 28 Data Processing Agreement is in place via acceptance of Google's DPA). No other processors (e.g. separate crash/analytics SDKs or a third-party e-mail provider) are shipped in the current build; this list will be updated if any are added. (Current position; to be confirmed in a professional review as the project grows.)

Google AdMob: integrated but disabled at launch (Section 3.12); no ad data is shared while it is dark.

6.3 Authorities and legal claims

We may disclose data to public authorities (e.g. Danish Police) where required by law or to address a serious risk to life or safety, and to our advisers to establish, exercise or defend legal claims.

Our processing is configured for the EU/EEA: Cloud Functions run in europe-west1 (Belgium) and Firestore/Storage are provisioned in an EU region (e.g. eur3 / europe-west1). (Current configuration; to be confirmed in a professional review as the project grows.)

Some Google support, security or operational functions may nonetheless involve access from outside the EEA (e.g. the United States). Where personal data is transferred to a third country, it is protected by an appropriate safeguard under Art 46 — principally the EU Standard Contractual Clauses incorporated into Google's Data Processing Terms, and/or reliance on the EU–US Data Privacy Framework where the recipient is certified. You can request a copy of the relevant safeguard using the contact details in Section 1. [LEGAL REVIEW: confirm which transfer mechanism Google relies on for the services you enable and whether any adequacy decision (Art 45) applies, then state it precisely.]

We keep personal data only as long as needed for the purposes above. By category:

Data	Retention
Account, profile, tags, photos, location, personality, stats	For the life of your account. Erased when you delete your account (Section 10).
Live Hot/Cold game session data	Not persisted beyond the profile `location` value described in Section 3.4; game state ends when the game is quit/auto-quit.
Chat messages	For the life of the conversation. On account deletion, your profile is erased but message copies already delivered to other participants are retained in their conversations (Art 17(3)(a)/(b) — others' freedom of expression / their own use). [LEGAL REVIEW: confirm this carve-out and consider a maximum retention/auto-expiry for dead rooms.]
User reports / safety & moderation records	Retained beyond account deletion for as long as necessary for safety and to establish, exercise or defend legal claims (Art 17(3)(b) and (e)). Closed reports/safety records are retained 24 months after closure (current policy, adjustable).
Date of birth / age-gate record	For the life of the account (age-assurance evidence).
Encounter & ML/connection-outcome rows about other users	On your deletion these are anonymised (your name/photo stripped, your identifier replaced with an opaque tombstone) rather than deleted, so other users' history and counts survive.
Technical logs, rate-limit and security data	Short operational retention: 30 days (current policy, adjustable).
Backups	Residual copies may persist in routine backups for a limited period after erasure before being overwritten: residual copies overwritten within 30 days (current policy, adjustable).

Where we cannot give a fixed period, the criterion is "as long as your account is active, plus any period required to meet a legal obligation or defend a legal claim" (Art 13(2)(a)).

9. Device location access (ePrivacy) — Art 5(3) ePrivacy Directive

Reading your device's GPS and sending it to our servers (for discovery in Section 3.4 and the live game in Section 3.5) is "gaining access to information stored in your terminal equipment" under Art 5(3) of the ePrivacy Directive 2002/58/EC, as clarified for sensor/GPS data by EDPB Guidelines 2/2023 on the technical scope of Art 5(3). This requires your prior consent and is a separate, additional legal hook on top of our GDPR Art 6 basis (Section 3.4):

Your operating-system location permission prompt, together with our in-app explanation shown immediately before we request it, provides the ePrivacy device-access consent.
Our GDPR Art 6(1)(a) consent (Section 3.4) covers the subsequent processing of that location.

You can withdraw the device-access consent at any time in your device settings (turn off location for Flybi); this disables nearby discovery and the live game. [LEGAL REVIEW: we do not rely on the Art 5(3)(b) "strictly necessary for a service explicitly requested" exception for nearby/location; confirm this conservative consent-based position.]

You have the following rights over your personal data. To exercise them, use the in-app controls described below or contact us (Section 1).

Access (Art 15) — a copy of your data.
Rectification (Art 16) — correct inaccurate data; you can edit most of your profile in-app.
Erasure / "right to be forgotten" (Art 17) — delete your account from within the app (Settings → Delete account). This triggers a server-side cascade (deleteAccount Cloud Function) that erases your profile, tags, tag images, location, personality, stats, your own encounters, reveal requests, Storage objects and your Firebase Authentication record; anonymises records that live on other users; and removes you from others' block lists. Certain data is retained as permitted by Art 17(3) — see the chat-copies and safety/legal-claims carve-outs in Section 8. A separate deactivation option lets you hide your account without deleting it.
A web-based deletion request is also available for users who have uninstalled the app, at https://flybi.app/delete-account (which names the app/developer, as required by Google Play's account-deletion policy) (to be published before store submission).
Restriction (Art 18) — restrict processing in certain cases.
Objection (Art 21) — object to processing based on legitimate interests (Section 3.7, 3.10, 3.11); we will stop unless we have overriding legitimate grounds (e.g. ongoing safety/abuse handling).
Data portability (Art 20) — receive data you provided, based on consent or contract, in a structured, commonly used, machine-readable format.
Withdraw consent (Art 13(2)(c); Art 7(3)) — where we rely on consent (location in Sections 3.4/3.5; optional profile fields; any future ads), you can withdraw at any time without affecting the lawfulness of processing before withdrawal. Withdraw location consent in your device settings; withdraw optional-field consent by editing your profile.

Access and data-portability requests are handled via the contact e-mail in Section 1 (ngts91@gmail.com), with a response target of within one month as required by Art 12(3). (Current process; to be confirmed in a professional review as the project grows.)

If you believe we have processed your data unlawfully, you may lodge a complaint with the Danish supervisory authority:

Datatilsynet (Danish Data Protection Agency) — https://www.datatilsynet.dk (Datatilsynet's current postal address and contact/complaint channel are as published on datatilsynet.dk; refer to the site for the authoritative details.)

You may also complain to the supervisory authority in your EU/EEA country of residence.

12. Accountability records we maintain (informational)

For transparency, and because the Art 30(5) "<250 employees" exemption does not apply to us (our location processing is not occasional and is likely to result in a risk to data subjects — these are alternative triggers, any one of which removes the exemption), we maintain a Record of Processing Activities (ROPA) under Art 30(1). Given large-scale, systematic processing of precise geolocation, we also maintain a Data Protection Impact Assessment (DPIA) under Art 35 (the WP248 rev.01 high-risk criteria — systematic monitoring + large-scale processing + combining datasets — are met), completed before the location feature is offered, and will undertake Art 36 prior consultation with Datatilsynet if a high residual risk remains. The ROPA and DPIA are maintained on file. [LEGAL REVIEW: re-verify the ROPA and DPIA are complete and current, and check the location feature against the current Danish Art 35(4) DPIA list published by Datatilsynet.]

13. Security & data breaches

We protect your data with measures including encryption in transit, Firebase Authentication, server-side security rules (firestore.rules), App Check, and rate limiting. No system is perfectly secure.

If a personal data breach occurs, we will notify Datatilsynet without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to your rights and freedoms (GDPR Art 33), and we maintain an internal breach register (Art 33(5)). Where a breach is likely to result in a high risk to you, we will inform affected users without undue delay (Art 34). Because a breach affecting precise location, chat and identity could be high-risk (per EDPB Guidelines 01/2021 breach-severity factors: nature/sensitivity/volume of data, ease of identification, and severity of consequences), we treat such incidents accordingly.

14. Future features (not active)

The following are not part of the live service and are listed only so this notice stays accurate as the app evolves:

Biometric / face-comparison identity verification — deferred. If introduced, biometric data used to uniquely identify you is special-category data (Art 9) and will require Art 9(2)(a) explicit consent, a strengthened DPIA, and an update to this notice before any processing begins. We do not process biometric data today. (A non-biometric "verified" trust badge exists, decided by a human moderator; any verification artifacts are kept in a private collection not exposed in discovery.)
Advertising (Section 3.12) and payments/in-app purchases — not active; this notice will be updated before either launches.

15. Changes to this policy

We may update this notice. We will post the new version at https://flybi.app/privacy and, for material changes (e.g. a new processing purpose or legal basis), notify you in-app or by e-mail and, where required, seek fresh consent.

Drafting note for counsel: every legal requirement above is grounded in the research brief — GDPR Arts 3, 5, 6, 8, 9, 13, 17, 22, 27, 30, 33, 34, 35; ePrivacy Art 5(3) + EDPB Guidelines 2/2023; Danish Data Protection Act § 6(2); e-handelsloven § 7. Data-flow descriptions are taken from the live code (firestore_fields.dart, firestore.rules, discovery_repository_impl.dart, chat_room_game_wrapper.dart, the deleteAccount Cloud Function, and the moderation runbook). Two descriptions deliberately diverge from the project one-line summary because the code differs — flagged in Sections 3.4 and 3.5 — and must be reconciled with the founder's intended design before publication.

Privacy Policy (GDPR Art 13 + ePrivacy)

1. Who we are (the controller) — GDPR Art 13(1)(a)

Data Protection Officer — GDPR Art 13(1)(b)

2. Who Flybi is for — 18+ only (children) — GDPR Art 8

3. The data we process, why, and our legal basis — GDPR Art 13(1)(c)–(d)