Flybi.

Privacy Policy (GDPR Art 13 + ePrivacy)

Status: appropriate for the current closed-beta scale, revised against an external legal research memo dated 7 August 2026 and then reconciled, the same day, against a line-by-line audit of the shipped source code. Where the two disagreed, the code won: several passages that described an intended design now say plainly what the app does today, and are marked [planned] where the design is still being built. 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), transposed in Denmark as cookiebekendtgørelsen, BEK nr 1148 of 9 December 2011, § 3. It also reflects Apple App Store Guideline 5.1.1(i) and Google Play's User Data / Data safety requirements.

Last updated: 27 October 2026 — Section 3.7 now says what blocking someone does on their side: they are not told. A one-to-one chat you had with them is changed for good the way an account deletion changes it: your name, e-mail address and photos are taken out of it, and unblocking does not bring it back. In a group room you both stay, and their app shows you to them like an account that has left Flybi, with no profile to open. The copy of a room's members' block lists that keeps a blocked person out of an open room is now on a record only our servers can read (#2330). Also 27 October 2026 — Section 3.4: the finest area cell (~153 m) is no longer on your profile. Distances other people see are now worked out on Flybi's servers from your private record, and their app receives only a rounded distance, never your position or a cell. The server also ignores a stored position that would mean travelling faster than about 300 km/h since the last one it accepted. If that server work ever has to be switched off for a while, distances are worked out on the phone from the ~1.2 km cell instead, so they are coarser and the Hot/Cold game cannot be started (#2310). Before that, 26 October 2026 — New Section 3.3a: what you write in your tags, your bio and your chats can say sensitive things about you (for example about your health, your religion or beliefs, your political views or your sexuality), so from the app update that adds it, Flybi asks for your explicit consent to process it, as its own question: before you set up your profile if you are new, and once, the next time you open the app, if you already use Flybi. Flybi cannot run without it. If you say no, or later withdraw it in Profile → Privacy & legal, Flybi keeps what you wrote but stops showing your profile to other people, stops working out vibes with you, and the app is on hold for you until you agree, with log out and account deletion always available. Sections 3.2, 3.3, 3.6 and 10 now point to it (#2308). Also 26 October 2026 — New Section 3.16, and a row in Section 8, say what happens when you e-mail support@flybi.app, including through "Send feedback / report a bug" in the app, which fills in your app version, phone system and version, phone model and app language for you to send (#2285): we receive what you send, use it only to answer you and fix the problem, and keep it as long as that takes. Also 26 October 2026 — Section 3.7 now says that your block lists (whom you blocked, and their e-mail addresses) are kept on a private record under your account that only you can read, and that a private record under your account, which only our servers write, lists who has blocked you so that your app can keep you and them apart. Until the app update that does this, your block lists were on your profile, where another signed-in user could read them; a list set before that update stays there until a one-off clean-up moves it, or until you next block or unblock someone (#2312). Also 26 October 2026 — Section 3.3 now says that nobody sees whether, or how many, secret tags you share with them until you both agree to compare. The Discover card used to show a count of shared secret tags; it no longer does, and the stored counts are being deleted (#2311). It also says that two people can compare again 30 days after the last answer, and that nobody can ask someone who blocked them or hid from them (#2324). Before that, 23 October 2026 — Section 7 now says where your photos are stored. Until 23 October 2026 they were stored with Google in the United States. They are now stored in Belgium, and a copy stays in the US only as a fallback until about 30 October 2026. App versions up to 1.7.0 still send chat images to the US (#1649). Before that, 22 October 2026 — Three changes. First, Section 3.9 now separates two kinds of push notification. Notifications about something a person did (a message, a chat request, an invite, a reveal) are sent unless you turn them off, and notices about your account are always sent, as before. Notifications about a soulmate or a strong fit nearby, and about a badge you earned, are now off unless you turn them on in the app's notification settings, or, for the soulmate one, on the Soulmate step when you set up your profile; nobody had to do anything for them, so they need your yes first. Turning on notifications in your phone's settings is not that yes. If you used the app before this change you are not opted in. App versions up to 1.7.0 cannot turn them on: the switch they show for them does not do it, although turning it off there still turns them off. Until you turn them on in a later version, you get none of these on any of your devices. Section 10 says how to turn them off again (#1400, #2200). Second, Section 6.1 now says that other users see a coarse activity status on your Discover card: "Active now", "Recently", "Today", "This week" or "Inactive". It never shows an exact time, and it is not shown on a card that is blurred for the person looking. From the app update that does this, it is shown however long ago you were last active; before, it was shown only for the last 24 hours (#2219). Section 3.4 points to it. Third, Section 6.1 also says what your comfort zone does and does not hide: people farther away than it do not see you in their Discover feed, but if you write to someone yourself, by a chat request or, with Premium, a room invite, that person sees you in the request or invite, and in the chat or room if they accept, even when they are outside your comfort zone (#2218). Before that, 16 October 2026 — Sections 3.4, 8, 9 and 10 now say what happens when your phone stops giving Flybi your location: you turn off Flybi's location permission in your phone's settings, or, on iPhone, switch Location Services off. From the app update that does this, the next time you open Flybi it deletes the location stored for you, both the copy on your profile and the private copy, so other people no longer find you from it. Until you open Flybi again, the location stored before stays where it was. While your phone does not give Flybi your location, Flybi shows you nobody nearby either, and no Stop Bi's or On the Fly rooms nearby. When your phone gives Flybi your location again, it stores a fresh location the next time it reads it (#1697). Before that, 15 October 2026 — Sections 3.2 and 8 now say that, in app versions after 1.7.0, the files and settings Flybi keeps on your phone (such as the answers to a vibe check you have not finished, or your consent choices) are left out of your phone's own backup and do not move to a new phone. On Android they are not backed up at all. On iPhone the app marks its files to be left out of iCloud and computer backups, and deletes settings that a newer backup brings back before using them. A backup made with version 1.7.0 or earlier can still hold a copy until your phone replaces it, and on iPhone restoring it can put that copy back. On iPhone your sign-in is kept in the keychain, which iOS manages, and can stay after you remove the app (#2104). Earlier the same day — Section 6.1 now says that an open room is not only a "Stop Bi": an "On the Fly" room is open too, unless you set who can join to "Invite only", and open is its default. Everything Section 6.1 says about open rooms, including the warning about what an open-room listing carries, applies to it as well (#1619). Before that, 14 October 2026 — Section 3.2 now says that the answers to a vibe check you have not finished are kept on your phone, so you can pick up where you left off after closing the app, that they are never sent to us, and when they are deleted. The same fact is in the account row of Section 8 (#2053). Before that, 6 October 2026 — Section 3.4 now says that while the app is open Flybi refreshes your location about every 10 minutes, and that from the app update that fixes this, the refresh stops when you leave the app. It also corrects what happened before: in earlier app versions this refresh could keep running after you left the app, so a phone (on Android in particular, where the app stays in memory) was asked for its location about every 10 minutes while Flybi was in the background, even if you had not allowed background location. Where the phone had not granted background location it refused those requests, but they should not have been made. Where the phone did allow background location, those readings went through, under the earlier single choice that Section 3.4 describes for app versions before background location became its own choice. From the app update that fixes this, nothing is read in the background unless you have allowed background location, both in Flybi and in your phone's settings (#2036). Earlier the same day, Sections 3.4 and 9 now say that your location consent belongs to your account, not to your phone, and correct what happened before: a new account signed in on a phone where someone else had already said yes to location was not asked, and its location was stored with no record of consent. From the app update that fixes this, every account is asked for itself, and nothing is collected for an account until it has said yes (#2002). Before that, 5 October 2026 — Section 10 now also lists two more records a chat room keeps under your e-mail address that deleting your account removes: when you last read the chat, and that you sent its latest message (#1998). Earlier the same day, Section 10 now says that deleting your account also removes the records a chat room keeps under your e-mail address (that you hid or cleared a chat, that you were removed from a group, and your address on the copy of its members' block lists), and the record that limits how often you can send chat requests (#1969). It also says that for an account deleted before that change reached our servers, those records may keep its address until a one-off clean-up has run, which has not run yet. Before that, 4 October 2026 — Section 3.13 now says plainly that Google AdMob, not Flybi, chooses the ads you see and that the consent question about personalised ads is about Google's use of your data. It also lists the ad categories we block in AdMob, with the date they were last checked, and says that we never sell your personal data (#1927). Also on 4 October 2026 — Sections 3.7, 4 and 5 now describe how offensive language is handled. Nothing you write is refused because of its words. A setting on your device, on unless you switch it off, shows threats and slurs in other people's names, bios, tags and room names as ******. When someone reports you, our server checks what you have written publicly, and your messages that were already reported, for threats, slurs and hostile statements, which can count toward the reports that pause an account automatically until a person looks at it. Section 4 says how that pause works and how we treat it under GDPR Art 22; Section 3.7 says what is read and what is kept (not the words). Section 3.7 also describes what our moderation tool shows a person who reviews a report (#1913, #1917, #1921). Before that, 2 October 2026 — Section 10 now gives the way to delete your account in the app as the app shows it: Profile → Account → Delete account (#1571). Before that, 29 September 2026 — Sections 3.6, 8 and 10: "Keep this chat". In a one-to-one chat, a Premium member can ask to keep the chat, and if the other person agrees, its messages are kept for up to 12 months from when each was sent instead of 30 days. This rests on the consent of both of you; either of you can withdraw at any time, and you are both told when keeping ends, 7 days before the chat goes back to 30 days (#1810). Earlier the same day, Section 3.7 now also says where the details of a closed chat room, and of a verification decision about your account, are kept: on records that only our moderation tools can read. The room shows only that it is closed and the fixed reason, and your profile only the verified badge. Until this change those details were stored on the room or on your profile, where other signed-in users could read them (#1815). Earlier the same day, Section 3.7 now also says where the other details of a pause on your account are kept. When it began, whether it was automatic and when a cooldown ends are on the private record only you can read. Which reports led to it, and how and when it was lifted, are on a record that only our moderation tools can read. Until this change they were stored on your profile, where other signed-in users could read them (#1809). Earlier the same day, Sections 3.6, 6.1, 8 and 10: every chat message, with any image in it, is now deleted 30 days after it was sent, by a server job that runs every night. This replaces the limit of 12 months after a conversation's last message, which no job enforced. A message is only kept longer while a safety report about it, or about its chat, is being dealt with (#1102). Earlier the same day, Section 3.7 now says where the statement of reasons for a pause on your account is kept: on a private record only you can read. Until this change it was stored on your profile, where other signed-in users could read it (#1806). Earlier, 28 September 2026 — Sections 8 and 10 now say that a deleted photo or image is not gone at once: our cloud provider keeps deleted files in a recovery store for up to 7 days, which only our administrators can reach, and then they are gone; files from a deleted account are never brought back (#1802). Earlier the same day, Sections 3.15 and 8: when you delete your account, the record of anyone you invited stops naming you; this was marked [planned] and is now done (#1792). Earlier the same day, a new Section 3.15, and a row in Section 8, describe invitations: the invite code, the record that someone used one, the free Premium it gives, and on Android the install referrer Google Play carries from the invite link. These were in use but not described here (#1179). Earlier the same day, Section 3.7 now describes notices sent through the web form at flybi.app/report, which anyone can use without an account: what we keep from a notice, that the email address is used only to confirm receipt and to tell the sender what we decided, and that the sender's IP address and email address are only kept as a keyed, anonymised fingerprint for 30 days to prevent misuse (#1180). Before that, 26 September 2026 — Section 8's note on how the retention periods are enforced was out of date: it now says which of them run as scheduled jobs. Its Backups row described a 30-day backup rotation that did not exist; the database is now backed up once a day and each backup is kept for 7 days, and the row says so. A Hot/Cold game's live position (Sections 3.5, 8, 10) is now removed when the game ends by a server job as well as by the app, and with your account. The placeholder that replaces you on other people's encounters (Sections 8, 10) no longer carries your account's ID, and Section 2 now says who closes an under-18 account and how. Earlier the same day, Sections 3.2 and 6.1 now describe where your personality result is kept and what other users can see of it: the exact scores are no longer on your profile, only a rough summary is (#1737). Earlier the same day, Section 3.9 was made precise about a device's push token once its notifications are turned off: that takes effect the next time the app is opened, and only the switch in the device's settings counts, because the notification choices inside the app apply to the whole account (#1737). Before that, 25 September 2026 — Section 3.7 now says that the statement of reasons for a moderation decision is kept under your account, readable only by you, so the app can show it to you (#1181). Earlier the same day, Section 3.14 now lists that we keep whether your subscription is set to renew, which Apple and Google tell us, so the app can show "Cancelled, active until" a date. Before that, 24 September 2026 — Section 3.11 was changed to describe crash diagnostics, performance monitoring and usage analytics in two parts: how they work from the app update that adds Profile → Diagnostics (two switches, both off until you switch them on, asked once, withdrawable in one tap, with your user ID cleared on sign-out), and what app versions without it still do (everything runs from launch, with no switch). Sections 3.4, 3.10, 6.2, 7, 9 and 10 are scoped the same way. Before that, 20 September 2026 — new Sections 3.7a and 3.7b describe the automatic check of your profile and tag photos, and what a report about one photo does: enough different people reporting the same photo hides it while a person decides, temporarily, reversibly, and without anything happening to your account. Section 4 says why that is not an Art 22 decision, and Section 8 gives the retention for the records behind it. Before that, 19 September 2026 — Section 10 now says what account deletion does with your e-mail address on chat rooms and messages (it replaces it), and that copies in our analytics warehouse are deleted within 30 days. Before that, 14 September 2026 — Sections 3.13 and 3.14 now describe advertising on the free plan and Premium subscriptions as they work once each is switched on, with who receives what (Section 6.3), transfers (Section 7), retention (Section 8) and device access for ads (Section 9). Before that, 10 September 2026 — the location lifecycle is now a ladder rather than two cliffs (Section 3.4). Background reading no longer stops dead after 14 days: it narrows instead, so a dormant account is only updated after a large move and only as a coarse area, and stops entirely at 90 days. The automatic expiry in the same section splits the same way — precise position deleted after 14 days of account inactivity (a tightening on the previous 90), coarse presence deleted after 180. Collecting and deleting remain separate mechanisms: one stops us taking new readings, the other removes what was already taken Applies to: the Flybi mobile application ("Flybi", "the app", "we", "us")

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

Flybi is operated by:

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.

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

No Data Protection Officer is appointed; one is not legally required at the current scale. The controller (Nicholas Gerster Toft Simonsen, support@flybi.app) 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. At the current closed-beta size the "large scale" thresholds in Art 37(1)(b) and (c) are not met. That will change as we grow: a proximity service doing background location and processing special-category data crosses those thresholds well before it feels like a large company, and we re-run the assessment at each order of magnitude of growth.

Note that a DPO is not required for a Data Protection Impact Assessment to be required — see Section 12.

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

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.

If we learn that a user is under 18, we will close and erase the account. It is erased by the same process that runs when you delete your own account (Section 10), started by a person on our side.

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

3.2 Profile & personality

3.3 Interests as "tags", including secret tags

3.3a What you write: tags, bio and chat — your explicit consent

3.4 Location — proximity discovery, including in the background when the app is closed — see also Section 9 (ePrivacy)

Read this section carefully. It is the most intrusive processing Flybi does.

Profiles last written before this change can still carry an old ~153 m geohash7 cell until a one-off clean-up removes it; the app no longer writes it, and our database rules refuse it.

New and updated profiles now publish only the cells described above. Profiles that have not been written since the change may still carry the old precise copy, and that cleanup is being applied in stages — the last stage cannot run until the app update that reads the new cells has reached everyone, because removing the old field from under an older app would empty that person's feed. Until each stage completes, treat a last-known precise position on an un-updated profile as readable by any other signed-in user. [in progress]

Your e-mail address is a separate matter and is still readable on the profile document by any signed-in user. It cannot be moved yet: the chat and blocking features currently find people by e-mail address, and that has to be changed to use an internal ID first. [planned] We will update this bullet when each of these actually lands, rather than quietly dropping it.

Why we ask some people again. We have rewritten how the location consent screen explains why your location is sensitive. If you said yes to the earlier wording, the app asks you once more, and nothing is collected on the strength of the earlier yes in the meantime. If you said no, we do not ask again.

Your consent is your account's, not your phone's — a correction. In app versions before the update that fixes it, the app remembered the answer to the location question on the phone, not on your account. If someone had already said yes on a phone, a new account signed in on that phone was not asked: its location was read and stored, and we had no record that its owner had agreed to anything. That was wrong. From that update: - each account is asked for itself, and its answer is recorded under that account, with the date and the version of the screen it saw; - what decides whether we collect your location is your account's recorded answer. Signing out removes your answer from the phone, and the next person to sign in is asked for theirs; - an account that has no recorded yes — including one whose location was stored on someone else's yes — is asked when it next opens the app (or at the location step, if it has not finished signing up), and nothing is collected for it until it says yes. Until it answers, the last location stored for it stays as it was and is no longer updated; the usual expiry still removes it (the precise position after 14 days of account inactivity, the remaining coarse area cell after 180 days; see "Retention" below). If it says no on the screen that asks it when it opens the app, the location stored for it is deleted. We do not fill in a yes on anyone's behalf. - Background location is its own choice. Foreground and background are two different things we do with your location, and from the app update that separates them they are asked, stored and withdrawn separately: - Flybi asks about background location on its own screen, and only on a later visit — never in the same breath as the first location question. Yes and no are equally easy to press. Your phone's "allow all the time" prompt appears only after you have said yes there; the first location question asks your phone for "while using the app" only. - Saying no, or turning it off later, leaves nearby discovery working whenever the app is open. Nothing else changes. - Profile → Location has a switch for each. Turning background off stops background reading and deletes the location stored for you; a fresh one is stored the next time you use the app with location on. Turning location off turns all of it off, including background, and switching location back on later does not switch background back on. - If you said yes to location before the update, you said yes to both at once. You keep location while using the app. Your earlier yes is not treated as a yes to background: background stops with the update, and you are asked about it separately.

In app versions before that update, one switch governs both, so there is no way to allow one and refuse the other.

What is true in every version: turning location off in Profile → Location stops both, at the same depth as turning it on, and leaves the rest of Flybi working — you keep your account, your chats and your connections. We will never require location as a condition of using Flybi, and we will never re-ask after you have refused.

  1. After 14 days of account inactivity we delete the precise part of your stored position — the exact coordinates (and, on a profile that still carries one, the old ~153 m cell). A coarse area cell remains, so people can still find you, but nobody can be shown a specific distance to you.
  2. After 180 days of account inactivity the coarse cell goes too, and you stop appearing to anyone. We warn you first: a notification 7 days before, and another 24 hours before.

Opening the app at any point restores a fresh position and resets both clocks; doing nothing lets it go, which is a perfectly good outcome and costs you nothing else — your account and everything in it are untouched.

The periods are measured from your last activity, not from when the point was recorded, so a point you keep refreshing is never removed by this.

Why the split. A stored point stops being treated as precise almost immediately: after 30 minutes of inactivity the app no longer shows anyone a specific distance to you, only a coarse "in your area" reading. So holding the precise version of a dormant point buys nothing anybody can see — which is why stage 1 removes it early, and why that is a tightening on the previous 90 days. What the remaining period keeps is coarse presence, not a live position, and that is the part worth keeping longer: it is what lets someone still reach you after a quiet few months instead of finding you gone. We do not put your coordinates into analytics events, crash reports or server logs; a coarse ~39 km area cell can, however, appear as a diagnostic detail on a crash report — from the app update that adds Profile → Diagnostics, only if you have switched crash diagnostics on; in earlier versions, whenever the app sends one (Section 3.11).

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

3.6 Chat messages

3.7 Safety: reports, blocks & moderation

3.7a Automatic check of your profile and tag photos

3.7b Reports about one photo, and a photo hidden while it is looked at

3.8 Date of birth / 18+ age gate

3.9 Push notifications & device tokens

3.10 Technical, security & abuse-prevention data

App Check. Firebase App Check is integrated, but its enforcement is currently switched off on our server functions, including account deletion — the device-attestation providers it depends on are not yet registered with Apple and Google. So while it is listed here and in Section 6.2 as something we use, it is not protecting those paths today. Section 13 says the same.

3.11 Crash diagnostics, performance monitoring and analytics

Which version this describes. Everything below this box applies from the app update that adds Profile → Diagnostics — you can tell you have it because that screen exists. In earlier versions of the app:

If your app does not have Profile → Diagnostics, e-mail us (Section 1) and we will stop it for your account and delete what was collected, by hand. Account deletion does not reach Google's own copies of this data (Section 10).

From that update, these are off by default. Nothing is collected unless you switch it on, and the app works identically either way.

3.12 Best-fit / ML signals

3.13 Advertising (free plan)

Flybi pays for itself partly with a small number of ads shown to people on the free plan. Advertising is controlled by a switch on our side and may be off; while it is off, nothing in this section happens. Premium subscribers never see ads (Section 3.14).

3.14 Premium subscriptions and payments

3.15 Invitations (referrals)

3.16 E-mails to support

4. Automated decisions — GDPR Art 13(2)(f) / Art 22

Flybi uses automated processing to rank and surface profiles (best-fit and soulmate/strong-fit scans), and word lists that, on your device, show threats and slurs in other people's text as ****** while the Hide offensive language setting is on (Section 5). That setting acts only on what you see and takes no decision about anyone. 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), with one measure we set out in full below so that you can judge it yourself: the automatic pause of an account. Every decision that you broke a rule, and every warning, removal of content for what it says or shows, cooldown, ban or termination, is taken by a human moderator, who issues a statement of reasons (DSA Art 17).

The automatic pause of an account. Your account can be paused automatically, before a person has looked, when people report it (Terms Section 6.1). Only reports about your account count, not reports about one photo, one tag or one message:

Reports from people you have blocked, and from someone whose reports keep being dismissed as unfounded, do not count towards either.

What it means for you: you can still sign in, read why, contest it, read our terms and this policy, sign out and delete your account, but you cannot otherwise use Flybi, and the app stops showing your profile to others, until a person has looked. Nothing is deleted. Only a person lifts the pause, or replaces it with a decision of their own, with a statement of reasons. The statement you see says that the pause was automatic, that a person will look at it, and, where language counted, that it did.

We treat this pause as falling outside Art 22(1), and we say why rather than assert it: it is not a decision that you did anything wrong but a holding measure until a person decides; it starts only with a report from a person; it is temporary, deletes nothing and leaves you able to see why and contest it; and a person reviews every automatic pause. We also recognise that it restricts you, and that how long it lasts depends on when a person gets to it. So, in case it is a decision under Art 22(1), we rely on Art 22(2)(a) (it is part of how the service you signed up to keeps people safe, and our terms describe it), and the Art 22(3) safeguards are in place: a person reviews every automatic pause, and you can put your point of view and contest it at support@flybi.app at any time, including before that review.

The automatic photo check (Section 3.7a) takes no decision about you and none about what your photo shows: it only marks photos for a person to review, and a person decides whether a photo is removed. The one removal made without a person is of a photo link that does not point at a photo uploaded through Flybi, a technical rule about where a link points rather than a judgement of the photo or of you. It concerns one link, you can add a photo through the app straight away, and nothing else about your account changes. You can still ask a person to look at it (Section 3.7a).

One further measure takes effect before a person has looked: when enough different people report the same photo, that photo is hidden while a person decides (Section 3.7b). We treat this as falling outside Art 22(1) and we say why, rather than asserting it: it concerns one photo, it is temporary and reversible, it is not a decision about you — your account, your other photos and everything you can do on Flybi are untouched — and the decision that actually removes a photo is taken by a person, who gives their reason. The photo is not deleted while it is hidden. Even so, we tell you it happened and why, and support@flybi.app reaches a person who can put it back.

5. How we keep the service safe

We operate: an in-app report flow and block capability; a human moderation process with statements of reasons and warn / hide / cooldown / ban actions; the Hide offensive language setting, which is on unless you switch it off and, on your device, shows explicit threats and unambiguous slurs in other people's display names, bios, tag titles, tag descriptions and room names as ****** (swearing always shows, your own text always shows to you, chat messages are not filtered, and the setting itself stays on your device); the automatic pause on reports, with the language check described in Sections 3.7 and 4; an 18+ age gate; and Terms/EULA acceptance at registration. Nothing anyone writes is refused because of its words. These underpin the safety processing described in Sections 3.6–3.8.

Your profile and tag photos are also checked automatically after upload. A photo the check marks is reviewed by a person, who decides; nothing is removed automatically for what it shows (Section 3.7a). Photos sent in chat are not checked; there, reports and blocks are the controls.

You can also report a single photo, from the photo itself. Reports about one photo act on that photo: when enough different people report the same one, it is hidden while a person decides, and nothing about the reported account changes (Section 3.7b).

6. Who receives your data — GDPR Art 13(1)(e)

6.1 Other users

By design, your profile (name, photo, bio, public tags, approximate area, badges, a rough summary of your personality result — low, middle or high for each trait — and, if you make it visible, your communication style) is shown to other signed-in users so they can discover and connect with you. Your Discover card also shows a coarse activity status, worked out from when you last used the app: "Active now" or "Recently", "Today" or "This week", or "Inactive". It never shows an exact time, and it is not shown on a card that is blurred for the person looking (for example because you are outside their comfort radius). Chat content is shared with the people in that conversation. Secret tags are shared only via a mutual reveal.

Your comfort zone. If you set a comfort zone, people farther away than it do not see you in their Discover feed. That covers being found, not writing: if you write to someone yourself, by a chat request or, with Premium, a room invite, that person sees you in the request or invite, and in the chat or room if they accept, even when they are outside your comfort zone. Writing to them is your choice to be seen by that one person. Nobody else outside your comfort zone sees you because of it (#2218).

More than that is currently readable, and you should know it. Your profile record as stored today also carries your e-mail address and your precise last-known coordinates, and it is readable by any signed-in Flybi user, not only by the people we choose to show you to. Nothing in the app displays those fields — but "not displayed" is not the same as "not shared", and we are not going to describe it as if it were. Removing them from the readable copy is [planned]; see Section 3.4. The same is true of the exact personality scores on a profile last saved with an app version from before #1737, until the one-off move in Section 3.2 has run.

Open rooms. If you create or join an open room, that room is listed to other signed-in users so they can find and join it. Open rooms are of two kinds: a "Stop Bi", and an "On the Fly" room whose "Who can join?" setting lets in people who share your tags ("Any shared tag" or "Min. shared tags"). That is the default for an On the Fly room, so a room you open with "Go On the Fly" is open unless you have chosen "Invite only". An open On the Fly room is listed at the area where you opened it; it does not follow you. The listing shows its title and image, its join tags, and its approximate area — a geohash cell of roughly 1.2 km × 0.6 km, the same coarse grid used for profile discovery. Your precise coordinates are not in the room record: it holds only the cell, so the point you were standing on when you opened the room is not recoverable from it (#1033). Rooms you keep private are visible only to their participants and to anyone you invite; an On the Fly room set to "Invite only" is one of those.

⚠️ What an open-room listing actually carries. Everything in the room's record travels to the device of every signed-in user who lists open rooms — not just the parts the app puts on screen. That includes the e-mail addresses of the room's participants, of anyone invited to it, and of whoever created it (room membership is keyed by e-mail throughout Flybi), and the text of the last message sent in the room. The app does not display the last message or the addresses in the discovery card, but they are delivered all the same, and a determined person can read them. That copy of the last message's text is cleared from the room when the message itself is deleted at 30 days (Section 8). If you would not want your e-mail address known to strangers, do not join open rooms until we have fixed this. Re-keying membership from e-mail to an opaque ID is tracked as #696 / #600.

What a new joiner can see. When someone joins an open room, they are shown messages sent before they arrived — currently up to the most recent 200 messages of that conversation. There is no server-side limit behind that number: it is a cap the app applies, and one we can change remotely, so it is a product setting rather than a guarantee. People who were not present when you wrote something can therefore read it. The app shows none that is more than 30 days old, and every message is deleted 30 days after it was sent, unless a safety report is holding it (Section 8). A real cap — post-join only, or a short window — is [planned].

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:

And, for crash, performance and usage data (Section 3.11) — which, from the app update that adds Profile → Diagnostics, run only if you have switched them on, and in earlier versions run for everyone:

Google processes this data on our behalf as a processor under the Google Cloud / Firebase Data Processing and Security Terms (an Art 28 Data Processing Agreement is in place via acceptance of Google's DPA). For the three diagnostic and analytics services above, the contracting entity is Google LLC and the data reaches the United States — see Section 7. We keep Google's data-sharing settings off so that Google does not become an independent controller of that data. No other processors (for example 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.)

6.3 Independent controllers: Google for ads, Apple and Google for payments

These companies decide for themselves how they use the data they receive, under their own terms and privacy policies, so they are not our processors:

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.

7. International transfers — GDPR Art 13(1)(f) / Arts 44–49

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

Your photos. Until 23 October 2026 your photos were stored with Google in the United States. On that day we moved them to europe-west1 (Belgium), where every photo from the current app version is stored too. Until about 30 October 2026 we keep a copy of them in the US, only so that we can undo the move if something goes wrong; then we delete it. App versions up to 1.7.0 still send chat images to the US until those versions stop working. The safeguards below cover this too.

Three things nonetheless leave the EEA:

For the first two, the mechanism is the same. Google LLC is certified under the EU–US Data Privacy Framework, which the European Commission has found to provide an adequate level of protection (Art 45), and the EU Standard Contractual Clauses are incorporated into Google's Data Processing Terms as an Art 46 safeguard that stands behind it. We keep the SCCs in the contract chain deliberately, so that the transfer remains covered if the Framework is ever suspended or annulled — a legal challenge to it is pending before the Court of Justice. You can request a copy of the relevant safeguard using the contact details in Section 1.

8. How long we keep your data (retention) — GDPR Art 13(2)(a)

We keep personal data only as long as needed for the purposes above. Every period below is anchored to an event we actually record — the date you deleted your account, the time a chat message was sent, the date a report was closed — so that you can work out the period that applies to your data rather than reading a general promise.

⚠️ How these periods are enforced today, 29 September 2026. Deletion you ask for — account deletion, erasing your location — runs straight away, on our server, and you can rely on it. The time-based periods in the table below are enforced in two different ways, and each row says which. Four run on their own, as scheduled jobs: the two-stage location expiry (nightly, since 18 August 2026), the removal of Hot/Cold live positions (every 10 minutes), the deletion of a deleted account's copies in our analytics warehouse (Section 10), and the deletion of chat messages 30 days after they were sent (nightly) — or up to 12 months after, in a one-to-one chat you both chose to keep. The others do not: rows marked [not yet automatic] describe the limits we hold ourselves to and will delete to on request, not a job that runs on its own. We are telling you this instead of quietly loosening the wording, and building those jobs is the fix.

Data Retention
Account, profile, tags, photos, personality, stats Kept while your account exists. Erased when you delete your account (Section 10) — see the erasure timing note below. The answers to a vibe check you have not finished are on your phone only, never on our servers, and are deleted from it when the finished test is saved, when you sign out or delete your account, or when you remove the app (Section 3.2).
Location (Section 3.4) One point only. Each reading overwrites the previous one, so no trail is built. The stored point is deleted when you turn location off, when you use "Erase my stored location", and when you delete your account. From the app update that does this, it is also deleted the next time you open Flybi while your phone withholds location from it (Section 3.4). In addition, an un-refreshed point expires automatically in two stages: the precise position after 14 days of account inactivity, and the remaining coarse area cell after 180 days, with notifications 7 days and 24 hours before the second. Running since 18 August 2026; two-stage since 10 September 2026.
Live Hot/Cold game session data Your live position is deleted when the game ends: by your app straight away, and by a server job every 10 minutes for any position on a game that has ended or that nobody has updated for 10 minutes. It is also deleted when you use "Erase my stored location", and when you delete your account, which deletes the whole game record from every room you played in (Section 3.5).
Chat messages (Section 3.6) 30 days. Every message — its text, any image in it, and the lines the app posts itself, such as "X left the chat" — is deleted 30 days after it was sent, for everyone in the conversation. A server job runs every night and deletes every message that is more than 30 days old. Normally a message is gone within a day or two of turning 30 days old, but it can take longer: after an outage, while a large backlog is being cleared, or when deleting its image failed and is retried on a later run. The app stops showing it at 30 days whatever the job has done. The time a message was sent is set by our server when it is saved, not by anyone's phone, so it cannot be moved to make a message last longer. For a message with an image, the image stored with that message is deleted first, then the message. That does not cover an image another message still uses while it is held for a safety case (it goes when that message does), or a photo that was uploaded but never sent in a message. Kept longer while a safety case is open: a message is not deleted while a report about it, or a report that includes it in the part of the chat attached to the report, is still open (not yet decided by a moderator); while a report about the whole chat is open, or the chat is closed pending a moderator's review; or while its image is temporarily hidden pending a moderator's decision, is being taken down by a moderator, or is being kept as evidence (Section 3.7); or while a moderator has put it, or its chat, on hold as evidence, for example because the police asked for it. Once that ends, a following nightly run deletes it. A report keeps its own copy of the messages it concerns, under the limit for reports in the next row. The chat itself — who is in it, its name, its status and when it was last active — is the connection between you, not its content, and is not deleted by this; when its last message is deleted, the preview of that message on the chat is cleared too, so no deleted text is left in your chat list. On account deletion your profile is erased, but messages you sent stay in the conversations they were delivered to until they are 30 days old, like every other message, on our legitimate interest in the other participants' own record of their conversation (Art 6(1)(f)); you can object to that under Art 21 and we will weigh it. The images you sent are an exception: they are deleted from Storage by the erasure cascade, so a retained message shows the text but no longer the photo (#1021). A deleted message can remain in a database backup, and a deleted image in our cloud provider's recovery store, for up to 7 days (the Backups and Deleted photos and images rows below). Keep this chat: up to 12 months, only if you both agree. In a one-to-one chat, a Premium member can ask to keep the chat, and the other person can agree; agreeing is free. Group chats cannot be kept. While a chat is kept, each of its messages is kept for up to 12 months from when it was sent instead of 30 days, and the app shows them for that long; the chat says that it is kept. Nothing is kept longer than 12 months, and a safety case can still hold a message as described above. This rests on the consent of both of you (Art 6(1)(a)), and either of you can withdraw at any time from the chat's menu. Keeping ends when one of you withdraws, when the Premium of the person who asked ends, when the chat itself ends (for example, the moment one of you leaves it), or when one of you deletes your account. You are then both told (only the one still here, if an account was deleted), in the chat and with a notification, and after a grace of 7 days the chat goes back to 30 days: a following nightly run deletes every message in it that is more than 30 days old. Unless one of you stopped it, the notice does not say why keeping ended. If one of you deletes your account, that person's own messages in the chat that are more than 30 days old are deleted at once, and the rest are deleted when they turn 30 days old. A request to keep a chat that nobody answers lapses after 14 days. If, on a given night, our server cannot check whether one chat is still kept, it deletes nothing from that chat that is younger than 12 months that night and checks again the next night. If it cannot check which chats are kept at all, it goes on keeping only the chats that were kept at its last successful check, for at most 7 nights in a row; every other chat keeps to its 30 days, and after those 7 nights the kept chats go back to 30 days too. The record of who asked, who agreed and when is kept with the chat and deleted with it. Whose Premium the keep relies on, and why it ended, are on a record that only our server can read.
User reports / safety & moderation records Our limit is 24 months from the date the report is closed (actionedAt), and these are kept beyond your account deletion, because they are needed to keep other users safe and to establish, exercise or defend legal claims (Art 17(3)(e), and our legitimate interest under Art 6(1)(f) in the safety of the people who reported). [not yet automatic] — deletion at 24 months is done on request or by hand until the scheduled job ships. Reports that led to a ban, or that concern serious harm, may be kept longer where a specific matter is live — we will tell you the period if you ask.
Photo check results (Section 3.7a) The result of each check (the ratings, whether the photo was marked for review and what the reviewer decided, never the photo) is kept while your account exists and erased when you delete your account. A photo waiting for another check is listed in a queue until it has been checked, and that entry is erased with the account too. The note that a photo was removed is kept until a new photo replaces it, and is erased with the account.
Report-counting records and reporter reputation (Section 3.7b) The record that you reported a particular photo, and the count of how many of your reports were dismissed, belong to the reports they were derived from and are kept under the same limit — 24 months from the date the report is closed — and for the same reasons. Like the reports, deletion at 24 months is [not yet automatic], and these records can outlive the account they concern for that period, on the same Art 17(3)(e) and Art 6(1)(f) grounds as the reports themselves.
Record of a hidden photo (Section 3.7b) Kept under your own account for as long as the account exists, so that a photo that was hidden can be put back and so that a decision about it can be shown to you; erased when you delete your account. The photo itself is never deleted merely for being hidden.
Date of birth / age-gate record Kept while your account exists (age-assurance evidence); erased with the account.
Encounter & ML/connection-outcome rows about other users On your deletion these are stripped of your name and photo and your identifier is replaced with a placeholder, rather than the rows being deleted, so other users' history and counts survive. On an encounter, the placeholder is a random value made separately for each person who keeps the row, and the row's own ID, and the record that counts you among the people they met, are re-keyed to it: none of them carries your account's ID any more. Encounter rows anonymised before 26 September 2026 still carry the deleted account's internal ID inside the placeholder; converting them to the new form is a one-off job that is [not yet run]. See Section 10.
Blocks placed on you by other users Kept as long as the blocking user's account exists, so that their block continues to work — and removed when you delete your account, since the erasure cascade scrubs you from other people's block lists, and from the private record of who blocked each person you had blocked (#2312). The record of who blocked you is under your account and goes with it.
Technical logs, rate-limit and security data Our limit is 30 days from the date of the log entry, and up to 6 months for logs retained for a specific abuse or security investigation. [not yet automatic].
Crash, performance and analytics data (Section 3.11) Retained by Google: Crashlytics 90 days; Performance Monitoring 30 days where associated with an IP address and 60 days where associated with an installation. These are enforced by Google, not by us.
Premium purchase records (Section 3.14) Kept while your account exists; erased when you delete your account. Apple and Google keep their own billing records under their terms.
Invitations (Section 3.15) Your invite code, the record that you used an invitation and your Premium history are kept while your account exists and erased when you delete your account. An invite code read from the Android install referrer stays on your device only until it has been tried. When you delete your account, the record of someone you invited stops naming you: your user ID, your code and your Premium end date on it are replaced with a placeholder, and their Premium is not affected.
E-mails to support (Section 3.16) Kept as long as we need them to answer you and fix the problem you wrote about, and no longer. They are not stored in the app, so they are not part of deleting your account: ask us at support@flybi.app to have them erased. [not yet automatic] — this is done by hand.
Advertising data (Section 3.13) Held by Google under its own retention policy (https://policies.google.com/technologies/retention). Your consent choice stays on your device until you change it or remove the app. Flybi keeps no ad data beyond the placement counts in the analytics row above.
On your phone The files and settings Flybi keeps on your phone (for example your consent choices, which one-time screens you have seen, the answers to a vibe check you have not finished, and a copy of data the app has loaded) stay there until they are no longer needed, you sign out or delete your account where this policy says so, or you remove the app. In app versions after 1.7.0, Flybi keeps them out of your phone's backups, and they do not move to a new phone. On Android, the backups your phone makes no longer contain them: Flybi switches off the phone's backup (Google Drive) and phone-to-phone transfer for the app, so none of it is copied. On iPhone, the app marks its files to be left out of iCloud and computer backups, but iOS may still back up the small settings file it keeps for every app, which holds for example your consent choices and the answers to a vibe check you have not finished; if a backup made with a version after 1.7.0, or a new iPhone set up from one, brings Flybi's settings back, the app deletes them before using them. A backup your phone made with version 1.7.0 or earlier can still hold a copy until your phone replaces it with a newer backup. On Android it is not put back into the updated app. On iPhone, restoring that backup, or setting up a new iPhone from it, can put the copy back, and the app then keeps it. On iPhone your sign-in is not kept in these files but in the iPhone's keychain, which iOS manages: it can stay on the iPhone after you remove the app, so reinstalling on the same iPhone may find you still signed in. On a new phone, or after reinstalling the app, you may have to sign in again and you see the one-time screens again (#2104).
Backups Since 26 September 2026 the database is backed up once a day, and each backup is kept for 7 days. So something you delete, or your whole account, can remain in a backup for up to 7 days after you delete it; after that it is gone. Backups are readable only by us and are used only to restore the service after data loss. If we ever restore from one, we bring back only what was lost, and nothing from an account deleted after the backup was taken. Separately, the database keeps the previous version of a changed or deleted record for one hour (its standard version retention).
Deleted photos and images When a photo or chat image is deleted — by you, by a moderator's decision, or because you deleted your account — our cloud provider (Google Cloud Storage) keeps the deleted file in a recovery store for up to 7 days, so that a file deleted by mistake can be recovered. Only our administrators can reach it, and it is used for nothing else. We never bring back files from an account that was deleted. After 7 days the file is gone.

Timing of erasure. When you ask us to erase data, or delete your account, we act on it promptly — the deletion runs when you confirm it, not on a clean-up schedule, and well inside the one month Art 12(3) gives us to respond. That is deliberately a different clock from the periods in the table above, which is why the box above tells you which of those periods are not yet enforced by a job.

Where a period above depends on something we cannot predict — an open safety investigation, a legal claim — we keep the data for as long as that specific matter requires and no longer, and we will tell you the expected period if you ask (Art 13(2)(a)).

9. Access to your device (ePrivacy) — Art 5(3) ePrivacy Directive / cookiebekendtgørelsen § 3

Three things Flybi does count as storing information on, or gaining access to information stored in, your terminal equipment under Art 5(3) of the ePrivacy Directive 2002/58/EC, transposed in Denmark as BEK nr 1148 of 9 December 2011 § 3:

  1. Reading your device's location and sending it to our servers — for discovery and background updates (Section 3.4) and the live game (Section 3.5). Sensor readings are outside Art 5(3) only while they stay on the device; once the reading, or any derivation of it such as a geohash, leaves the device, Art 5(3) applies (EDPB Guidelines 2/2023 v2.0, §44).
  2. Writing and reading the installation identifiers used by Crashlytics, Performance Monitoring and Analytics (Section 3.11). From the app update that adds Profile → Diagnostics, the app asks you first, with two switches that both start off, and the three services are built to start switched off until you answer. Earlier versions start them at launch without asking — the rule below is the rule, and those versions do not meet it for this item; see the box at the top of Section 3.11.
  3. Ads on the free plan (Section 3.13). The Google Mobile Ads software reads the device's advertising identifier, and stores and reads identifiers and your consent choice on the device. When advertising is on, Google's consent message asks you before the first ad is requested, and on iOS Apple's tracking prompt is shown as well. No ad is requested, and the ad software is not started, until that message says ads may be requested. If you decline, ads are not personalised; declining does not remove ads.

All of these require your prior consent, and this is a separate legal hook that sits in front of our GDPR Art 6 basis — if we do not clear Art 5(3), no Art 6 basis can rescue the processing, and Art 5(3) has no legitimate-interest option. We do not rely on the "strictly necessary for a service you explicitly requested" exemption for any of it. In particular, that exemption cannot cover collection that continues while the app is closed, and it cannot cover crash reporting or analytics, because the test is what is strictly necessary from your point of view — Flybi works the same without them.

The operating-system permission dialog is not this consent. An OS permission prompt is a technical control over a resource; it does not name a purpose, a retention period, a recipient or a withdrawal right, and it cannot be a valid consent on its own. Our own in-app consent screen is what asks you, and the OS prompt is only triggered after you have said yes there. If you decline in Flybi, we do not show you the OS prompt at all. From the app update that separates background location, the location question asks your phone for "while using the app" only, and the "allow all the time" prompt follows only a yes on the separate background screen.

The in-app consent is per person; the OS permission is per phone. The permission you give in your phone's settings belongs to the phone and covers whoever uses Flybi on it. Flybi's own consent belongs to your account: on a phone shared by two accounts, each is asked, and neither's location is read on the other's yes. In app versions before the update that fixes this, it did not work that way — a new account on a phone where someone else had said yes was not asked (Section 3.4, "Your consent is your account's").

Withdrawal. Turn location off in Profile → Location — one tap, at the same depth as switching it on. From the app update that separates background location, the same screen also has its own switch for background location alone. You can additionally revoke the permission in your device settings. From the app update that does this, Flybi then deletes the location stored for you the next time you open it (Section 3.4, "When your phone stops giving Flybi your location"). Turning location off in-app stops every location read, foreground and background, and also erases the location already stored for you, both the copy on your profile and the private copy (Section 3.4). Withdrawing leaves the rest of Flybi working. For diagnostics and analytics, from the app update that adds Profile → Diagnostics, switch either off there (Section 3.11) — the same one tap it took to switch it on; in earlier versions there is no in-app switch, so e-mail us and we will stop it for you. For ads, Profile → Privacy & Ads → Manage ad consent reopens your choices.

Supervision. GDPR matters are supervised by Datatilsynet; Digitaliseringsstyrelsen supervises the Danish cookiebekendtgørelse — the rules in this section — and can impose penalties under it. See Section 11.

10. Your rights — GDPR Art 13(2)(b)–(d)

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

A separate deactivation option lets you hide your account without deleting it.

What "delete your account" does, and what "clear chat history" does — they are not the same. Deleting your account really deletes data, as described above. The control still labelled "Clear chat history" deletes nothing: it records a point in time against your e-mail address on that conversation and hides everything before it from your own view. Everyone else in the room still sees every message, and the messages remain in our database until they are deleted, 30 days after they were sent — or up to 12 months after, in a chat you both chose to keep (Section 8). We are renaming the control, because the current name promises deletion and delivers hiding. If you want data gone rather than hidden, delete your account or ask us. - Restriction (Art 18) — ask us to stop using your data while a dispute about its accuracy or our legal basis is resolved, instead of deleting it. Hiding a conversation from your own view is a form of restriction, not erasure — see above. - Objection (Art 21) — object to processing based on legitimate interests (Sections 3.7, 3.10 and 3.12); 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, you can withdraw at any time, as easily as you gave it, without affecting the lawfulness of processing before withdrawal. We rely on consent for: - Foreground location and, separately, background location (Sections 3.4 / 3.5) — withdraw either in Profile → Location, or in your device settings. (In app versions before the update that separates them, one switch withdraws both.) Withdrawing in Profile → Location also erases the location already stored for you, and the same screen has a standalone "Erase my stored location" control. Turning off Flybi's location permission in your device settings (or, on iPhone, Location Services) erases it too, from the app update that does this, the next time you open Flybi (Section 3.4). - Crash & performance diagnostics and, separately, usage analytics (Section 3.11) — from the app update that adds Profile → Diagnostics, withdraw either there; in earlier versions, e-mail us and we will switch it off for your account. To have what was already collected deleted, e-mail us. - What you write in your tags, bio and chats (Section 3.3a) — from the app update that adds it, withdraw in Profile → Privacy & legal → Tags, bio & chat consent. Flybi then stops showing your profile to other people and stops working out vibes with you, and the app is on hold for you until you agree again; what you wrote stays stored unless you remove it or delete your account. Optional profile fields can also be removed by editing your profile. - Personalised ads and the device access they need (Sections 3.13 and 9): withdraw in Profile → Privacy & Ads → Manage ad consent, and on iOS also in Settings → Privacy & Security → Tracking. Ads then continue, not personalised. - Keeping a chat for up to 12 months (Sections 3.6 and 8): either of you can withdraw at any time from the chat's menu, Stop keeping this chat (or Not now, before you have agreed). You are both told, and after 7 days the chat goes back to 30 days. - Optional alerts — a soulmate nearby, a strong fit nearby and a badge you earned (Section 3.9): in app versions after 1.7.0, turn them off again in the app's notification settings, under Optional alerts; in 1.7.0 and earlier, turning off the switch for that alert also stops it. Your other notifications stay as they are.

Withdrawing any one of these leaves the rest of Flybi working. We do not make access to the app conditional on background location, diagnostics or analytics, and we will not re-ask after you have refused.

Access and data-portability requests are handled via the contact e-mail in Section 1 (support@flybi.app), 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.)

11. Right to complain — GDPR Art 13(2)(d)

If you believe we have processed your data unlawfully, you may lodge a complaint with the Danish supervisory authority. You do not need to raise it with us first, though we would rather you did.

Datatilsynet (Danish Data Protection Agency) — https://www.datatilsynet.dk — supervises our compliance with the GDPR. Its current postal address and complaint channel are published on datatilsynet.dk; refer to the site for the authoritative details.

Digitaliseringsstyrelsen (Danish Agency for Digital Government) — https://digst.dk — supervises the Danish cookiebekendtgørelse (BEK nr 1148 of 9 December 2011), which is the rule that governs access to information on your device: our reading of your location, and the installation identifiers used by crash reporting, performance monitoring and analytics (Section 9). Complaints about those go to Digitaliseringsstyrelsen rather than Datatilsynet. Digitaliseringsstyrelsen is also Denmark's Digital Services Coordinator under the Digital Services Act.

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

A Data Protection Impact Assessment (DPIA) under Art 35 is mandatory for our location processing. The route is not "large scale" — at our current size we do not meet the Art 35(3)(b)/(c) scale triggers — but Datatilsynet's own Art 35(4) list, item 3: processing of location data in combination with at least one further criterion. We process location data and meet at least two further WP248 rev.01 criteria (systematic monitoring, and sensitive or highly personal data). That list item carries no size threshold, so a closed beta of 26 users does not escape it. The DPIA covers the foreground/background split and why background collection is necessary, the Art 9 analysis, the sampling frequency and stored precision, retention, the outing / stalking / physical-safety risk model, processors and transfers, and withdrawal and deletion mechanics. If a high residual risk remains after mitigation we will undertake Art 36 prior consultation with Datatilsynet. The ROPA and DPIA are maintained on file.

13. Security & data breaches

We protect your data with measures including encryption in transit, Firebase Authentication, server-side security rules (firestore.rules) and rate limiting. App Check is integrated but its enforcement is currently off on our server functions (Section 3.10), so it is not adding protection today. No system is perfectly secure, and Sections 3.4, 3.5, 6.1 and 10 name the specific places where our current rules are looser than we intend them to stay.

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:

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 and in the external legal research memo of 7 August 2026 (MEMO.md) — GDPR Arts 3, 5, 6, 7, 8, 9, 12, 13, 17, 18, 21, 22, 25, 27, 30, 33, 34, 35; ePrivacy Art 5(3) + EDPB Guidelines 2/2023 v2.0 §44, transposed as BEK nr 1148 § 3; 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). The first revision of 7 August 2026 brought the notice into line with the memo on: background location and the Art 9 condition (§3.4, §3.5, §9), Crashlytics/Performance/Analytics as consent-gated device access (§3.11), event-anchored retention (§8), the honest account of chat clearing versus deletion (§3.6, §10), and controller contact details (§1).

The second revision of the same day reconciled the notice against a line-by-line source-code audit (code-audit-2026-08-07.md), and the code won every disagreement. Corrected: the reach and the gaps of the deletion cascade (§10, §8); the App Check claim (§3.10, §6.2, §13); world-readable profile e-mail and coordinates (§3.4, §6.1); what an open-room listing actually delivers and how much backlog a new joiner sees (§6.1); telemetry running by default rather than on consent, with the Flybi user ID and, in one path, an e-mail address attached (§3.11, §7, §9, §10); published retention periods that no scheduled job enforces (§8); the live-position record left behind by the Hot/Cold game (§3.5); the "clear chat history" watermark (§3.6, §10); and the client-side-only age gate (§3.8). Passages describing a design that is not yet shipped are marked [planned]; that marker is load-bearing and must not be removed ahead of the code.

The open questions behind those markers — founder decisions, and points the audit listed as not determined — are tracked internally in docs/legal/open-items-2026-08-07.md and in #1167. They are deliberately kept out of this file: tool/build_site.py renders this document to https://flybi.app/privacy, and markdown passes HTML comments through to the published page.*