Privacy Policy

IBOMEA s.r.o.

Version: 2
Effective: the day we publish this version at https://ibomea.com/privacy (see section 21)
Supersedes: version 1, effective 10 May 2026
Company / Controller: IBOMEA s.r.o.
Company Identification Number (IČO): 14071312
Registered Address: Hasova 3091/2, Modřany, 143 00 Praha, Czech Republic
Website: https://ibomea.com
Privacy Contact: support@ibomea.com
Support Contact: support@ibomea.com

1. The short version

You type your measurements into Ideal Body Measurements and we calculate figures from them. Those numbers, and everything we work out from them, are health data, and we treat them that way in every country we operate in. They stay in the EU. They are never sent to an advertising provider. You can delete them yourself from your history in the app. Section 5.4 lists them, and section 9 is the account of how we treat them.

To hold an account we need an email address and a sign-in method. Nothing else about you is required. Ideal Body Measurements is free because it shows rewarded video advertisements, and that is the only place we send any data of yours to anyone for advertising: your IP address, information about your device and the app, what you do with the advertisement, the answer you gave to Google's consent message, and on Android your advertising identifier.

If you use AthleteOS, our training app, section 5.14 is the account of it: it asks for a first and a last name, it holds your training plan and your workouts, and a trainer you connect with can read the plan and, in a workout the two of you run together, sees what is logged as it is logged.

Two things we do in Ideal Body Measurements we cannot give you a lawful basis for, and we would rather write that down than dress it up. That app starts Google's advertising component the moment it launches, before your consent answer is back and before it knows whether you have paid, so an advertisement request can leave your device with nothing behind it (section 8.1). And Article 9 of the GDPR wants your explicit consent for health data, put as its own question; the app never asks, so we do not have it (section 9.1). Both are defects in that app, and both need it changed rather than this page.

Most of what you can ask us for we do by hand, by email to support@ibomea.com; section 16 says what happens on its own and what only happens when you ask. Because privacy laws differ by country, there is a regional addendum at the end. Every version of this Policy carries a version number at the top, and that number is what we record when you confirm you were given it to read.

2. Company and Controller Information

For consumer-facing Services, IBOMEA s.r.o. is generally the data controller (or equivalent role under local law).

Company / Controller: IBOMEA s.r.o.
IČO: 14071312
Address: Hasova 3091/2, Modřany, 143 00 Praha, Czech Republic
Email: support@ibomea.com

For privacy requests, account deletion, or complaints, contact support@ibomea.com.

3. Scope

This Policy covers personal data processed through the ibomea.com website, Ideal Body Measurements, AthleteOS and other IBOMEA apps that link to it, account registration, login, profile, security and deletion, subscription status, the emails we send you, our prize draws and referral programme, and the systems that operate all of it. What AthleteOS collects, what a trainer you connect with can see and write about you, and what the two of you see of each other, is section 5.14. That section also says which parts of section 5 were written about Ideal Body Measurements and do not apply to AthleteOS, which takes no body measurements and carries no advertising of ours; the rest of this Policy applies to it as it does to everything else. We may offer further products under the IBOMEA account in future; what we process depends on which you use. It does not cover third parties we do not control, such as Apple, Google, the app stores, or an email provider you use outside our Services, which have their own privacy policies. Where our Terms of Service, our Cookie Notice or our Giveaway Rules, in the versions published before this one, describe what we do with personal data differently, this Policy is the later account and, on the day it was published, the accurate one.

4. Definitions

Personal data means information that identifies or can reasonably be linked to you. Sensitive personal data means the special categories listed in Article 9 of the GDPR and the equivalent categories under other laws; your body measurements, and every figure we calculate from them, are in it, and section 9 says what that means in practice. Processing means any use of personal data, including collection, storage, use, disclosure and deletion. Services means IBOMEA websites, apps, accounts and related digital services covered by this Policy.

5. Personal Data We Collect

We collect only what is reasonably needed for the Services you use. Not every category applies to every user or product.

5.1 Account and identity data

• email address;
• display name or username;
• internal account and user IDs;
• sign-in method (email/password, Apple, or Google), and the Apple or Google account identifier when you use one of those;
• email verification and account status;
• linked IBOMEA apps and membership status;
• if you have merged two IBOMEA logins, the identifiers and email address of the account merged in, kept so the merge can be traced afterwards.

5.2 Security and authentication data

• hashed password data (handled by our authentication provider; we do not store plain-text passwords);
• multi-factor authentication settings, and the one-time codes we send you, stored as hashes with an expiry rather than as the codes themselves;
• password reset and account recovery metadata, again as hashes rather than as the codes or tokens we sent;
• fraud and abuse prevention signals;
• server and API logs. Our application writes the request path, the outcome and how long it took, and in places your account identifier and, on a few lines such as the one recording that your welcome email went out, your email address. Separately, the web server in front of it writes an access line for every request, holding your IP address, the request line including anything in its query string, the page you came from, and your browser's user-agent string.

Your IP address reaches our servers with every request, as it does with any website. We use it at that moment for rate limiting, which keys a counter on it for the length of the window being counted, and it is in every access line above, kept for 30 days like the rest of our logs. On a route you call while signed in, our application's own counter is keyed on your account identifier instead of your IP address, and holds the times of your recent requests for a minute or an hour, depending on the route. A few limits are counted for each email address instead, such as how many password reset emails one address can be sent; those counters are keyed on a one-way hash of the address and last at most a day. One internal support route takes an email address as a query parameter, so on that route an address goes into the line too. In AthleteOS the request that reads your inbox carries your app language and your phone's time zone in its address, so those two are in its access lines as well.

The ibomea.com website keeps an access log of its own, written by the content delivery layer in front of it (section 14). It holds one line for every page and file your browser asks for, with your IP address, the address requested including anything in its query string, the page you came from and your browser's user-agent string, and no cookies. The link in our verification email carries your email address and the code in its query string, and the link in our password reset email carries your email address, so opening either puts them in that line. Those lines are stored in the EU and deleted after 30 days; we keep them so that a fault at that layer can be traced afterwards.

Apart from those logs and counters, the only IP address we hold is a shortened one: on an acceptance record (section 5.12) and, in AthleteOS, on the record of a connection with a trainer (section 5.14).

5.3 Profile data

On the website and linked account we may process your display name, IBOMEA-ID username, account creation date, and preferences and settings such as theme.

The website shows an initial-based avatar only and offers no photo upload. In AthleteOS a profile photo you choose is kept on your phone (section 5.9) and is never sent to Google; it reaches us only in versions of AthleteOS that share it with the people you are connected to, and only while we have that switched on for your account, as section 5.14 describes, so the rest of this paragraph does not apply to it. In Ideal Body Measurements you may choose a profile photo from your photo library; there is no camera path. A photo you upload is sent to Google Cloud Vision to be screened and then stored with your account. The check asks for a safety rating and a list of up to twenty-five words describing what is in the picture, and the photo is refused if the rating comes back as explicit adult content or one of those words is on our blocked list. The four avatars bundled with the app are recognised by their content and are not sent anywhere. Changing your avatar removes it; deleting your account deletes it.

The username and short bio you choose are checked against a word list at sign-up and on every later edit, and refused if they match. That check runs on our own servers, on the text itself, and nothing about it leaves us.

5.4 Ideal Body Measurements and app-specific data

If you use Ideal Body Measurements or a similar IBOMEA app, we process:

• the measurements you enter: height, weight, neck, shoulders, chest, waist, hips, bicep, wrist, thigh, calf, and a body-fat percentage if you choose to enter one yourself;
• your gender, which the calculations use, and, if you choose “other”, the free text you may write instead, which they do not use, because the app will not run a calculation for “other” at all;
• your age, which the measurements form requires and will not take below 18;
• the figures we calculate: body mass index, basal metabolic rate and two variants of it, fat-free mass index, an estimated body-fat percentage and the healthy ranges it is set against, a goal body-fat percentage, five body ratios (waist to height, hip, thigh, chest and shoulders), a ceiling for neck circumference, an ideal weight and an ideal circumference for each body part the method uses, and the fat and muscle change needed to reach them;
• your app profile: nickname, profile photo, avatar frame, short bio, gender, the free text that goes with “other”, and your date of birth;
• progress history, achievements, daily streak and app activity;
• bug reports you send from inside the app. One holds the address on your account, what you wrote, and a short technical line the app adds after you have finished typing, which you are not shown: the app version, your platform and operating system version, and whether an advertisement was available and, if a request for one had just failed, at what stage and with what code;
• subscription or plan status within the app.

A saved entry is not only the three or four numbers you see in your history: it holds every measurement you filled in, your gender, your age, which of the app's three modes you were in (basic, aesthetics or health), and the ideal weight it produced. Your date of birth is part of your app profile; the calculations do not use it. This data is written by the app's backend into its own tables, in the same EU database that holds your website account. The app also keeps your most recent fifty entries in your device's secure storage, separately for each account that has signed in on that device. Signing out does not remove them, and neither does deleting your account, which happens on our servers and does not reach into the phone. On Android they go when you delete the app. On an iPhone secure storage is the system keychain, which iOS keeps when an app is deleted, so they can outlast the app and still be there if it is installed again. Deleting an entry from your history while you are signed in removes it from our servers and from that storage. One more thing sits there for a while: if you open an invite link before you have an account, the referral code waits in the same secure storage until you have signed in and it can be sent, and is cleared once it has been.

Your measurements and the figures we calculate from them are data concerning health. Section 9 says how we treat them and how to delete them.

5.5 Subscription and purchase data

• subscription plan or entitlement status (for example free or paid);
• app-store purchase or renewal metadata (such as product ID or transaction reference);
• trial or restore-purchase events.

RevenueCat, our subscription provider, is how the app knows what you have paid for. In Ideal Body Measurements its component is started the first time the app runs and on every launch after that, before the app has looked for a sign-in and whether or not you ever buy anything, so an installation identity exists there for a free, signed-out install exactly as it does for a subscriber. In AthleteOS it is not started at launch. It starts when you sign in. When the app opens with you already signed in, it stays off until you open your Profile, the subscription screen or a screen that offers a subscription, and it starts then. Once you sign in we re-key that identity to your IBOMEA account identifier. We send it no name and no email address, and the app never asks it to collect a device or advertising identifier.

Payment card numbers are processed by Apple or Google, not directly by IBOMEA.

5.6 Account linking and merge data

If you use Connected accounts to merge two IBOMEA logins, we may process the email addresses of both, one-time merge codes stored as hashes with an expiry, the app scope you select, and the metadata needed to move app access and entitlements to one account. Afterwards we keep a record of which login was merged into which, including the email address of the account merged in, so a later question about your account can be answered.

The login merged in is not erased, and it goes on working. Our authentication provider still holds it, with its email address and its password or its Apple or Google link, and the website account database still holds it as an account of its own. If you sign in to Ideal Body Measurements with it, you now get the surviving account's data. What changes is its row in the app database, which stays as a marker pointing at the account it was folded into. On that row we blank the sign-in details - email address, password, and any Apple or Google link - and replace the display name with a marker; the real email address is kept separately, as the record above. What we do not clear on it is the profile that was there: photo, avatar frame, short bio, gender and the free text with it, date of birth and daily streak. Any bug reports sent from that login stay on it too, each with the email address it was sent with. Those stay while the surviving account exists. Because the two logins stay separate everywhere except the app database, account deletion acts on one of them at a time, and section 16 says what each one removes.

Separately: if you sign in with Google or Apple using an address that already has a confirmed IBOMEA account created with a password, we link the two rather than creating a second account. We do that without asking, because Google and Apple have already verified the address, and we only ever link into an account whose own address has been confirmed. If you would rather they were separate, write to support@ibomea.com.

5.7 Support, the help assistant, and OpenAI

If you email us at support@ibomea.com or use our website contact form, we process what you send: your name, email address, chosen topic, message and attachments. We forward it to our support workflow tool and our internal team workspace so a person can answer you, we send you an acknowledgement, and we store a reference record - a support request ID, a one-way hash of your email address and a fingerprint of your message - so duplicate submissions are threaded together rather than answered twice.

A large language model provided by OpenAI is part of that pipeline. A question the website's help assistant recognises, and a topic you pick from its list, is answered from our own stored answers, in your browser or on our own servers, and goes no further. Anything it does not recognise is passed on and answered by the model, and so is a topic you pick once the assistant has your contact email address for that conversation. The stored answers on our servers are in English only: if you have switched the website to another language, a question your browser does not recognise skips them and goes to the model, so that the answer comes back in your language, and the stored answer is used only if the model cannot be reached. Mail arriving at our support address is sorted by the model, and a suggested reply drafted for a person to review. What reaches OpenAI is your message and up to the last eight messages in the same conversation, at 500 characters each; your email address, and if you are signed in your display name and account identifier; your support request reference; the page you were on; if you have switched the website to another language, an instruction to answer in it; and a short summary of your account, which is which IBOMEA apps are linked to it and whether you are on the free or paid tier. The same set goes to the workflow tool carrying it, and to our team workspace when a conversation is handed to a person. Section 12 says where each of those three providers is. The workflow tool is also told which language to answer in: the one you chose for the website or, if you chose none, a guess between English, German and Czech made from your message and your browser's language setting.

If you rate an answer from the help assistant, we store that rating with up to 500 characters of what you typed and up to 500 of what it replied, and send the same rating and the same two extracts to our support workflow tool and into a channel in our team workspace, so a bad answer is seen the day it happens. We keep the text to find out what the assistant is getting wrong: a job each morning counts the words behind each thumbs-down over the last seven days, a weekly one over the last fourteen, and out of it comes a list of topics to write better answers for. Our internal dashboard shows the same counts, over the same seven and fourteen days. What leaves the database in those reports is the tally - how many people were unhappy, which pages and help topics they were on, which words recur. No report contains your message. The support page of our newer internal dashboard, where it is switched on, makes the same kind of count over the thumbs-down ratings of the last 30 or 90 days, and shows only words that at least five different messages used.

The stored rating holds no account reference at all, and the endpoint receiving it does not look your account up. We are still not going to call it anonymous: you wrote the text, people put an address or an order number into a support question without thinking, and if you were signed in the same message reached the pipeline above a moment earlier with your address on it. What follows is only that we cannot find it by searching for you, and we are not going to start storing your account against it so that we could. Section 16 says what to send us instead.

One report reaches us without you asking. If joining two IBOMEA logins fails on the website, the page sends our support workflow tool your email address, account identifier, display name, which app you were merging, the page you were on and the error our servers returned, and from there it goes to our team workspace and creates the same reference record. It exists so we find the fault before you have to write to us about it.

5.8 Technical and operational data

When you use the Services, we or our providers may automatically collect:

• device type, operating system, app or browser version; language and general region settings;
• server and API logs, timestamps and error information; section 5.2 says what a log line holds;
• error reports from the Ideal Body Measurements app and from our own servers. A report holds the error and limited technical context. Our error-reporting tool is set never to attach your IP address, cookies or account identity of its own accord, and the app deletes any account identity and any request headers, cookies or body before a report goes. On our servers the tool never collects the body of a request or the values of the variables in the failing code, and we remove the query string and every request header except four technical ones (content type, user agent, accept and content length) before a report goes. That is the whole of the stripping: nothing removes an email address or a token that happens to appear inside the text of an error message, and we would rather say so than let you read a wider promise into it. The website's code running in your browser sends none, because no reporting address is configured for it - a switch that is off rather than a door bricked up. If we ever set it, this Policy will say so first. The AthleteOS app carries no error-reporting component of ours and sends us none; the Android versions of AthleteOS that have a QR code scanner carry a library of Google's that reports to Google on its own working, which section 5.14 describes;
• our performance measurements, from the Ideal Body Measurements app only. About one traced operation in ten is measured whether or not anything goes wrong, so within one session some are measured and others are not. They carry how long the app took to start, how smoothly it drew, when it stalled, how long each screen took to appear, and how long each network request took, identified by the address it went to - no measurement, no figure calculated from one, and nothing you typed. The stripping above applies to error reports and nothing else, which is why these carry timings and addresses and nothing more;
• when either app checks for a software update, which it does each time it starts, your device platform, the app version, the update channel, an installation identifier that the update component generates at random and keeps on the device, and your IP address reach our update provider;
• a connectivity check, in Ideal Body Measurements only. The app requests a Google address (www.gstatic.com) that returns nothing but a success code, which is how it tells a real connection from a captive hotel network. It does this when the app starts, then every four seconds for as long as the app is open, and again whenever you bring the app back to the foreground - on a healthy connection as much as a broken one. It sends no data of ours, but each of those requests discloses your IP address to Google, whether or not advertising is ever shown to you.

5.9 Cookies and local storage

Everything the website stores on your device is first party, and none of it is used for advertising or analytics. Most of it is strictly necessary or set because you asked for it: cookies that keep you signed in (ibomea_api), protect form submissions (ibomea_csrf) and record that you completed two-factor authentication for this sign-in (ibomea_login_mfa); local storage holding your appearance and language choices, a note for each moving part of a page you have paused, and a note that you pressed I understand on the help assistant's notice that its answers are AI-generated; and, in session storage, which your browser clears when you close the tab, your sign-in tokens, the working items our sign-in flow needs and, if the address you opened carried our preview switch, which page design that tab shows. Three items fit neither description: the language entry is written on your first visit, as English, before you have chosen anything; a copy of your display name is kept in session storage so the corner of the page can show it while the page loads; and a one-character marker is written when you sign in, so that the next page can play its entrance once, and is removed as soon as that page has read it. An earlier version of the website also kept, in local storage, a list of the IBOMEA apps linked to your account with the email address each was linked under. It no longer writes that list, and it deletes any copy it finds when you sign out or open your profile page. We set no analytics or advertising cookies on the website, and if we ever add one we will update this Policy and, where the law requires it, ask you first.

The Ideal Body Measurements app stores your sign-in token and session, your profile details, your settings, your achievements and streak, your recent fifty entries, and the advertising consent state Google's consent tool saves. Two more things it keeps are worth naming. A copy of your most recent result is kept in the app so the dashboard can show it at once; the app stops showing it once it is 30 days old, but nothing deletes it, and the same is true of the working copies the app makes of a photo while it resizes it, which stay in its cache until you delete the app and never leave it. And three of the components we build on keep files of their own: our subscription provider keeps an installation identifier and a copy of your subscription status, so the app knows what you have paid for offline; our error-reporting tool keeps an installation identifier and any report it has not managed to send; and the over-the-air update system keeps the copy of the app's code it downloaded, which version it is, and the installation identifier it sends when it checks for an update (section 5.8). On an iPhone the items the app keeps in secure storage are in the system keychain, which iOS keeps when an app is deleted (section 5.4).

The AthleteOS app keeps a different set. In the phone's secure storage, while you are signed in: your sign-in tokens, a copy of your AthleteOS profile (your names, your email address and the date you joined), your role and whether the app is in its Free or its Premium mode, alongside the notification items section 5.14 lists; your language, your units and whether the Pro athlete options row in the plan editors is open are kept there too, signed in or not. In files of its own: a copy of your plan, of your inbox with the reports sent to you and of your booked sessions, your trainer's profile as shared with you, your reminder choices including the text of any reminder you wrote yourself, a record of which workout each weekday held so that the calendar can mark past days, and, if you choose a profile photo, the photo itself, which is uploaded only to share it as section 5.14 describes. If you are a trainer the files also hold your client list with each client's name and plan, your private notes, the reports you have sent, your schedule and your clients' booked sessions, and three things that exist nowhere else: a report you have not sent yet (apart from the sets of one drafted from a workout you ran together with a client, which our servers hold as that workout's steps), a session you are in the middle of logging alone, and the technique ratings, notes and flags you give during a workout you run together with a client (section 5.14). The workout you run together is itself not written to the phone's files, a trainer's or a client's: the app holds it in memory while it is open, and reads it from our servers again when it starts. Signing out deletes the copies of what our servers hold, and with them a trainer's unsent reports, unfinished session and those ratings, notes and flags. It leaves on the phone your reminder choices, the weekday record, the photo file, your language, your units and the Pro athlete options choice, the place on the screen where you last left the small circle such a workout is minimised to, and, if the acceptance record in section 5.12 has not reached us yet, a note that it is still owed. Deleting the app removes those files. On an iPhone it does not remove what is in secure storage, which is the system keychain there (section 5.4), so if you delete AthleteOS while signed in, your sign-in and the other items in secure storage can stay on the phone, where the app finds them again if it is installed again. AthleteOS builds on the first and the third of the components above and not the second, and when it shows a YouTube video the player keeps storage of its own inside the app (section 12).

The reminders AthleteOS gives you before a workout, the reminders you write yourself, the alert when a rest ends, and a trainer's morning summary and the reminders before each client arrives are scheduled by the app on the phone and are never sent to us; a trainer's summary and reminders show clients' first names, on that trainer's phone only. A workout or a plan you share as a code is turned into that code on your phone and read on the other person's phone: the code does not pass through our servers and holds nothing about who made it.

5.10 Advertising in the mobile app

Ideal Body Measurements shows rewarded video advertisements and no other kind: no banners, no interstitials, and no advertising of ours anywhere on the website or in AthleteOS. One of them unlocks a calculation for a free user. Close it part-way and the results stay locked; if none is available, the calculation runs anyway. Premium subscribers are never shown one.

For an advertisement we process your IP address and your interactions with it. On Android we also process your device's advertising identifier. On iOS we do not: the app never asks for App Tracking Transparency permission, so the identifier iOS would otherwise provide is withheld from us and from Google, and there is none to process or disclose. The advertisements are served by Google AdMob, which runs an exchange, so the one you see is often bought by another advertising company. So that those buyers can bid, the iOS app lists the identifiers Google publishes for SKAdNetwork, Apple's attribution system, which reports on advertisements rather than on people.

Consent, and where the record of your answer is. When the advertising component starts it asks Google's consent framework to run, wherever you are. Whether a message is then shown is Google's determination: we keep no country list of our own. Until you have answered, and if the framework fails to run at all, the app requests non-personalised advertisements only, and it stays that way if you answer and do not agree. It requests personalised advertisements only where the framework reports that you agreed, or that no message is required for your device. Your answer is kept by Google's framework on your own device and goes to Google with the advertisement request. We keep no copy: no server of ours is told what you chose, and there is no advertising consent record on your account, so if you ask us to produce the consent we acted on, we cannot show you a record of our own. Where Google's framework requires that a way to change your answer be offered, the app carries one in Settings, under Ad privacy choices, which reopens Google's form; what you choose there applies to the next advertisement. Where the framework requires no such form, that row is not shown. On Android your device's own settings reach further than that control: delete your advertising ID there and there is no identifier left to send.

The request that goes before all of that. Google's component is started when the app launches - before the consent check has come back and before the app knows whether your account is free or paid - and it prepares an advertisement then. That request carries your IP address, and on Android your advertising identifier, whether or not you have answered and whether or not an advertisement is ever put in front of you, including on a Premium account. Section 8.1 says what we rely on for it, which in that window is nothing.

5.11 Marketing and email preferences

Separately from the account and security emails we have to send you, we send occasional product tips and updates about the IBOMEA apps you use.

This preference is off for new accounts, and nothing is sent until you turn it on. It used to be on the moment an account existed, and an account created before we changed that keeps whatever setting it has: we have not switched anybody off, because doing so would also have stopped the people who want these emails. If yours is one of the accounts it is on for and you never chose that, the next paragraph is how to stop it, and you need give us no reason. Ask us at support@ibomea.com and we will tell you which it is for your account.

You can turn it off in two places. The foot of every one of those emails carries an Unsubscribe link that needs no sign-in: it names your account in a signature only we can produce, it does nothing else, and pressing it turns the preference off. Your mail app may also show its own unsubscribe button beside the message, which does the same thing. The setting is also under Profile security at https://ibomea.com/profile-security#marketing-emails, which does ask you to sign in. Neither app has a setting for it. Turning it off stops the product tips, the onboarding emails and the win-back offer below; it does not touch account and security emails, which we send whatever the preference says.

If a Premium subscription lapses, our support workflow can send a single win-back offer to the address on the account. It used to go out without reading your preference, and it no longer does: it is sent only where the address still has an account, that account has product tips on, and no deletion has been asked for. If any of those is not so, nothing is sent.

So that we do not send you the same thing twice, we record which of these emails we have already sent you and when. Separately, the queue that sends our email keeps a row for each message, holding the address it went to, your account identifier, or both, and for some emails also your referral code and invite link or your support request reference, so a message survives a restart and is not sent twice while it waits. Once it has gone the row has done its work, but nothing deletes it and account deletion does not reach it; section 16 says what to do about that.

5.12 Consent and acceptance records

When you create an account with an email address and a password, on the website, in Ideal Body Measurements or in AthleteOS, the sign-up form has a box to tick for the Terms of Service and this Privacy Policy, and we store a record of that acceptance: your account reference, which document you accepted (the Terms of Service or this Privacy Policy), which published version of it, the date and time, whether you were in an app or on the website, and a shortened form of your IP address - the network you were on, not the household. The record is written by a separate request straight after your first sign-in. If that request fails, the account exists without it: AthleteOS tries again later, the website and Ideal Body Measurements do not. The website's sign-up form also asks you to confirm you are 18 or over, and that declaration is recorded the same way, as a record of its own carrying the version number of the Terms published at that moment; the apps' sign-up screens do not ask it. Signing up with Apple or Google differs by surface. On the website it produces no record. In AthleteOS the Apple and Google buttons on the Create Account screen do nothing until the same box is ticked, so an account created there gets the record; one first created by pressing Apple or Google on the Log In screen is not asked and gets none. In Ideal Body Measurements those buttons do not wait for the box, so a record is made only if the box on the sign-up tab was already ticked when one of them was pressed.

The address on these records is the one our own servers work out, counting back through the proxies we run. It used to be taken from a header the caller sends, which meant the one field saying where an acceptance came from could be set by the person the record is evidence about. A record that can be written by its own subject proves nothing, so it is no longer written that way.

The same table holds a consent that can be taken back, and where one is withdrawn the row is stamped with the date rather than deleted: Article 7(3) says a withdrawal works from then on and does not unmake what was lawful before it, so the record has to be able to show both. These records are held against your account, so they are deleted when your account is, and you can ask us for a copy of the ones we hold.

5.13 Prize draw and referral data

Opening the prize draw screen creates a referral code on your account, whether or not you go on to enter, and that code stays afterwards.

If you enter, we record your entry and its status, the version of the rules you accepted and when, and, if we ever have to disqualify an entry, when we did it, why and when we told you. For each ticket you hold we record how it was earned (joining, a social follow, or a qualifying referral), which particular follow or referral it is for, when it was awarded, and, if it is later voided, when and why. We do not ask you to declare a country when you enter and the app does not send one; where we need to know where you live we ask you before a prize is paid. An address from a disposable or throwaway inbox service is refused automatically. Entering sends you one email, to the address on your account, confirming the entry and carrying your referral code, a link you can share and the prize table.

A referral is recorded as a link between the person who referred and the person referred, with the code used and the dates on which the referred account verified its email address, ran its first calculation, and thereby qualified. Checking that second condition asks the app database one question - whether that account has any saved calculation at all - and reads nothing that is in one. Your code sits on your account rather than on a single entry, so referral records outlive the draw they were earned in; deleting either account deletes the record. One trace stays: a ticket earned by referring someone carries the internal identifier of the account it was earned for, and a ticket already earned is not cancelled, so that identifier stays on the referrer's ticket after the other account has gone. It is an internal identifier and nothing else, and once the account is deleted there is nothing left for it to point at.

If you win, our system records the place, the prize amount and which of your tickets won, and nothing after that. Whether we wrote to you, whether you replied, when we paid, and any forfeit and its reason are correspondence between us: there are fields for them and nothing fills them in. There is a field for whether you agreed to be named publicly; it starts as no and nothing in the app or on the website changes it, so silence means we do not name you. To pay you we collect the payment details you give us, a bank account or a PayPal address, and, for the identity, age and residence checks the Giveaway Rules describe, confirmation of who you are, that you are old enough and where you live. That confirmation stays with us and is not passed to whoever moves the money. While the record of a prize exists it also stops your account from being deleted, until a person settles it by hand; section 16 says what happens.

The Giveaway Rules govern the draw itself. This section is the data notice for it.

5.14 AthleteOS: training data, what a trainer can see, status and notifications

AthleteOS is our training app. It uses the same IBOMEA account as everything else, so what sections 5.1, 5.2, 5.6, 5.7, 5.11 and 5.12 say about your account applies to it as well. Other parts of section 5 were written about Ideal Body Measurements and do not carry over. AthleteOS takes no body measurements, so section 5.4 does not apply to it. It has no advertising component in it and shows no advertising of ours, so section 5.10 does not apply to it either, and it has no prize draw screen, so neither does section 5.13. Sections 5.3, 5.5, 5.8 and 5.9 say where the two apps differ. In short: a profile photo you pick in AthleteOS is copied into the app's own storage on your phone, is never sent to Google, and is sent to us only to share it with the people you are connected to, as described below; its subscription component is started only once you have signed in, not at first launch; it has no error-reporting or performance-measuring component of ours and makes no connectivity check, so of the reports and checks in section 5.8 only the update check, and what our own servers log and report, apply to it; in the Android versions of AthleteOS that have a QR code scanner, the library that reads the code is Google's and reports to Google on its own working, as described below; and section 5.9 has a list of its own for what AthleteOS keeps on your phone. The rest of this section is what AthleteOS adds.

What we hold about your training. If you use it as an athlete we hold: the first name, last name and nickname you set for it, and when you last changed the name and the nickname; your role, your units and language; your training plan, which is the document the app reads to build your workouts: its name, its workouts and the days of the week they fall on, its exercises and the targets set for them, any note you write on an exercise, any video link on an exercise or a workout, and whether a trainer was the last to change it; a row for every finished workout, with the exercises, the sets, the weights and repetitions you logged and an effort rating where you gave one, the calendar day, when it started and ended, how long it took and the total weight moved, and a timed record of it, which is when each set started and how long it lasted, the order you did the exercises in, how each one ended and what it was called at the time; your personal bests, which we recompute from those workouts rather than accept from the app; and your inbox of notices, described below. In the app's Free mode a finished workout reaches us without its sets, weights, repetitions, effort ratings or total weight, so for those workouts we hold the day, the times and the timed record, and no personal best is worked out from them. A workout you run together with a trainer is not one of those rows, and it is the exception: we hold each set logged in it with its repetitions, weight and effort whichever mode the app is in, as described below. Where you subscribe, we also hold which tier you are on and what our subscription provider reports about the subscription behind it: the product, the store and whether the purchase was made in the store's test environment, whether it is a trial, when the current period started and when it ends, and whether it is set to renew. None of it is a measurement of your body and none of it is derived from one; where you also use Ideal Body Measurements, the two sets of data are not combined.

Whichever way you use it, we hold the connect codes you create for the other person to enter: a code works for 7 days or until you ask for a new one, and an old code stays on your account, no longer usable, until the account is deleted. If you use it as a trainer we hold, in addition, the reports you send; the weekly gym sessions and booked sessions you set with a client; the workouts you start with a client to run together, described below; the time of each reminder to train you send; the profile described below, if you fill one in; and the private notes you write about a client, each up to 2,000 characters and at most 500 for one client. A private note is never shown to the athlete it is about. It is still personal data about that athlete, and it is still within their right of access: if they ask us for a copy of what we hold about them, a note written about them is part of the answer.

Connecting to a trainer is a disclosure of your training plan, and it happens only once you have agreed to it. A connection can start from either side, and each way uses the other person's connect code. A trainer who enters a connect code of yours sends you an invitation, which you answer on a screen that names the trainer and lists the permissions being asked for. Or you enter a trainer's code and send that trainer a request to join. You choose the permissions on that screen and your agreement is recorded when you send the request, before the trainer has answered and before the app has shown you whose code it was: the trainer's name comes back only once the request has gone. The trainer then accepts or declines, and cannot change what you allowed. You can be connected to one trainer at a time, you can have one request waiting at a time and none while you are connected, and you can withdraw a request until it is answered.

Your name is the one thing shown earlier than that. As soon as an invitation or a request exists, each of you is shown the other's name, which is the nickname if one is set and otherwise the first and last name, or whichever of the two was given, and a notice carrying that name goes into the inbox of whoever has to answer. Where somebody has neither a name nor a nickname (section 5.15 says when that can happen), the app shows general wording, such as Client or Your coach, in its place. A trainer looking at your request also sees when you sent it and which permissions you chose. Nothing else of yours is shown until the connection is active. One thing can be learned without your name: a trainer who enters your connect code while you are connected with another trainer sends no invitation, and is told that you already have a trainer.

Accepting an invitation, or sending a request, records who started it, the date and time, which permissions you granted and the shortened network address it came from, in the same form as section 5.12. When a trainer accepts your request we add the time they accepted and nothing about their network. An invitation or a request that is declined or withdrawn is closed, not deleted, and is kept like any other connection record.

The camera, a photo you choose, and Paste. In versions of AthleteOS that have a scanner, a trainer's app shows the trainer's connect code as a QR code as well as in writing, and the screen where you enter a trainer's code has a Scan QR Code button. That QR code holds the connect code, inside a link to AthleteOS, and nothing else. If that link is opened on your phone, for example because your phone's own camera read the QR code, your phone opens AthleteOS, which takes only the code from the link, does not store it, and puts it in the field on that screen or does nothing with it. AthleteOS asks your phone for the camera only when you tap Scan QR Code, never when the app or that screen opens, and uses the camera for nothing else. While the scanner is open, what the camera sees is searched, on your phone, for a QR code. AthleteOS takes no photograph, records no video and no sound, and never asks for the microphone. The picture is not stored and is not sent to us. Choose a Photo, in the scanner, opens your phone's own photo picker: AthleteOS asks for no access to your photo library for it and is handed only the one picture you pick, searches that picture, on your phone, for a QR code, and then deletes the copy it was handed. That picture is not sent to us either; if the copy is not deleted, because the phone refuses or because AthleteOS is closed before it gets that far, it stays in the temporary files AthleteOS has on your phone until the phone clears them or you delete the app. All that AthleteOS keeps from a scan is the trainer's code, which it puts in the field on that screen. Reading the code sends us nothing: it reaches us only when you press Send Request, with the permissions you chose, as described above. You do not need the camera at all, because the code can be typed or pasted, and you can take the camera permission back from AthleteOS at any time in your phone's settings. In those versions the same screen has a Paste button, and the screen where you add a workout or a plan somebody shared with you as a code has had one in every version of AthleteOS that has that screen: AthleteOS reads your phone's clipboard only when you tap Paste, never when a screen opens, and uses what it reads only to fill the field in front of you.

What searches the picture depends on the phone. On an iPhone it is software that is part of iOS. On an Android phone it is Google's ML Kit barcode-scanning library, which is built into the Android versions of AthleteOS that have the scanner. Google's terms for that library say that the picture, and what is read from it, are processed on the phone and are not sent to Google. They also say that the library may contact Google's servers from time to time, for things like fixes and updated models, and that it sends Google measurements of how it performed and how it was used. Google's published list of what the library collects, which it gives for the current version, is: information about the phone, such as its make, model, and system version and build, and the hardware it can use to run the library; the package name and version of AthleteOS; identifiers for the installation, which Google says are not intended to uniquely identify a person or a device; performance figures, such as how fast the library ran; the settings AthleteOS runs it with, such as the format and resolution of the picture; the size of what went in and of what came out; the library's version; which kind of event took place, such as the library starting or a detection; and error codes for those events. Each of those requests also shows Google your IP address, as any request does. Google says it uses this to measure, debug, maintain and improve the library and to detect misuse, under its own privacy policy (section 12). AthleteOS gives the library nothing about your account or your training, so none of it is about either. The library is in those versions of AthleteOS whether or not you ever scan, and when it reports is Google's doing: we do not promise that it reports only while the scanner is open. An identifier that belongs to an installation has to be kept between one use and the next, so the library keeps those identifiers on your phone, in storage of its own inside AthleteOS that we do not read.

What a trainer can see and do. There are three permissions. The first, view, is always part of a connection: it lets the trainer read your whole training plan, including any note and any video link in it, and shows them the time your most recent workout ended. It does not show them your finished workouts themselves or your personal bests: our servers give a trainer neither. A workout the two of you run together is different, and is described below. The second, edit, lets the trainer change your plan or write you a new one, and when they do you get a notice with the trainer's name and the plan's name on it. The third, reports, lets them send you reports, which the next paragraph describes. Edit and reports are yours to grant or refuse, and refusing them does not stop the connection. Both start switched on, on the invitation screen and on the request screen, so they are granted unless you switch them off before you accept or send. Nothing in the app changes a permission once the connection exists: to change one, you end the connection and start a new one. Whatever the permissions, a trainer you are connected with also sees your name, the date the connection began and, where it is shared as described below, your profile picture, can set the sessions described below, and can send you reminders to train, which the paragraphs on notifications cover.

What a report holds. A report is a trainer's account of a session they logged for you, or of a workout the two of you ran together. It holds the name of the workout and of the plan, when the session started and ended, and for each exercise: its name; how it ended, for example done, skipped, put off or swapped, and the name of what it was swapped for; each set that was logged, with the repetitions and weight that were planned and those that were done, and an effort rating where one was logged; a rating of your technique, which is good, ok or needs work; a note of up to 280 characters; and any of three flags the trainer set, which are pain, limitation and reason for change. It ends with the trainer's comment and recommendation, of up to 4,000 characters each. The notes, the comment and the recommendation are free text, and we hold whatever the trainer typed. Until the trainer sends it, a report exists only on the trainer's phone. The sets of a workout the two of you ran together are the exception: our servers hold those as the list of steps described below, while the trainer's ratings, notes and flags for it stay on the trainer's phone until a report is sent. A trainer can correct a report after sending it: you are shown the corrected version, and we keep the earlier one, which neither of you is shown again. We record when you first open a report, and the trainer is not shown that. Each time a report is read it carries the names the two of you have then, not the ones you had when it was written.

Sessions with your trainer. A trainer you are connected with can set regular weekly gym sessions for you: a weekday, a start time and a length, up to 14 for one client. You see your own. The trainer sees all their clients' sessions together, as one weekly schedule with each client's name on it. We delete yours when the trainer replaces them or the connection ends.

A trainer can also book a single session with you on a date. You accept or decline it, either of you can cancel it before it starts, and the trainer can move it, which asks you again. For each one we hold the date, the start time and the length; the time zone it was booked in, which is the one the trainer's phone was set to; whether it is waiting for your answer, accepted, declined or cancelled; when you answered; when it ended, and whether you, the trainer or the ending of the connection ended it; if it was moved, the date and time it was moved from, when it was moved and how many times; and when it was made and last changed. Whoever declines or cancels can type a reason of up to 280 characters, and the other person reads it in the app; a reason is never put into a notification or an inbox notice. Only the two of you are shown a booked session, the trainer with your name on it, and only while the connection is active. We delete a booked session 400 days after its start time, or sooner if either account is deleted.

A workout you and your trainer run together. In versions of AthleteOS that have it, a trainer you are connected with can start one of the workouts in your plan with you, so that it runs on both phones at once; below we call that a shared workout. The trainer chooses the workout and waits. The app on your phone then shows a full screen that names the trainer and the workout, with Join and Cancel, and tells you before you choose that your trainer sees everything either of you does in that workout. While that screen waits for your answer, the trainer learns nothing new about you: the workout is one from the plan the view permission already lets them read, and their phone shows only that it is waiting for you. It is not told whether the screen has reached your phone or whether you have looked at it. The workout does not start, and neither of you can make a step in it, before you tap Join. If you tap Cancel, a second screen asks you to confirm, and there you can type a reason of up to 280 characters, or none. Once you confirm, the trainer is told that you cannot join, and that answer is counted, as the paragraph on what a trainer's app counts says below. The reason is shown to that trainer only, in the app, and is not shown to you again; it is never put into a notification or an inbox notice. The trainer can also stop waiting; your screen then says so, and that is not counted.

Once you have joined, the workout is open on both phones and either of you can do any of these in it: start and finish a set; skip a set, a rest or an exercise; put an exercise off until later; swap an exercise for another; choose which exercise comes next; change the repetitions, weight and effort for a set, where your screen shows them; undo the last step, whoever made it; and end the workout. Each of those but the last is a step, ending it closes the record instead, and whatever one of you does appears on the other's phone as soon as that phone next asks our servers, which is described below. You are shown your own workout screen with the trainer's name on it, and the trainer is shown theirs with yours. Your trainer therefore sees everything that is logged in that workout as it is logged, whichever of you logs it. That is more than the view permission shows them, and it applies only to a workout you joined: it adds nothing of your other workouts or your personal bests to what a trainer can read. All of it is shown whatever status either of you has chosen: Invisible, described below, does not hide that you joined or cancelled, or any step you make. What the trainer keeps to themselves while coaching stays out of it. The rating of your technique, the note on an exercise, the flags and the draft of the report are not put on our servers by a shared workout, and it never sends them to your phone: they stay on the trainer's phone, as they do when the trainer logs a session alone, and they reach our servers and you only inside a report, if the trainer sends you one. The private notes a trainer writes about a client are a separate thing, held as described above, and are never shown to you.

What we hold of a shared workout. We hold a record of each one from the moment the trainer starts it, whether or not you join. It holds which connection it belongs to and which of you is the trainer and which the client; which workout it is, by its reference in your plan, its slot and its name; a copy of that workout from your plan as it was at that moment, with its exercises, the targets set for them and any note or video link on them, so that a later change to your plan cannot change a workout that is under way; whether it is waiting for your answer, open, cancelled by you, cancelled before you answered by the trainer or by the ending of the connection, or ended; when the trainer started it, when you joined, and when and by whom it ended, which is you, the trainer or the ending of the connection; your reason, if you cancelled it and typed one; and when the record last changed, with the counters the two phones use to stay in step. The copy does not follow your plan: if you later change or remove something there, the copy stays as it was until the record is deleted, and while you are connected our servers go on giving it to that trainer's account, also for a workout you did not join. If you are the trainer in one, the same record names you, and each step you make says that the trainer made it.

Once you have joined, we hold the workout itself as a list of its steps, in the order our servers accepted them. A step holds which of you made it, the time it was made and the time it reached us, what kind of step it is and what it changed: for most steps nothing more, for a swap or a choice of the next exercise a reference to the exercise, and for a logged set or a change of the figures the repetitions, weight and effort. A step holds no words either of you typed. Undoing a step takes it out of the workout both of you see; in the list the undone step stays, marked as undone, and the undo is a step of its own. The list is held in the same way whether the app is in its Free or its Premium mode. In a shared workout each logged set is held with its repetitions, weight and effort even in Free mode, where your own screen shows neither those figures nor the controls for them, and where your own finished workouts reach us without them. The figures held with a set you finish there are not ones you entered: they are the starting figures the app takes from the targets set for the exercise, with a default effort rating, unless your trainer changed them. We delete a shared workout, with its steps, the copy of the workout and your reason, 45 days after the trainer started it, whatever state it is in by then, or sooner if either account is deleted. The notice in the client's inbox that the trainer started it is deleted with it, when we delete it after 45 days; the notices to the trainer that the client joined or cannot join are not deleted with it: they stay as the paragraphs on the inbox describe below. Ending the workout does not delete it sooner, and neither does ending the connection. Nothing of it is added to your own finished workouts, and no personal best is worked out from it.

To keep the two phones together the app makes calls of its own, apart from the ones described below under your status. While an invitation is waiting, your phone and the trainer's phone each ask our servers about every four seconds whether it has been answered or cancelled; while the workout is open, each phone asks about every two seconds for new steps. Two seconds is the standard setting, and we can move it between one and five seconds without an app update; the waiting interval is twice that, and never more than five seconds. The calls are made only while the app is open in front of you, which includes the time the workout is minimised to a small circle while you use the rest of the app, and they stop when the workout ends or is cancelled. Each is an ordinary request: it leaves the log lines described in section 5.2, the access line with your IP address among them, kept for 30 days like the rest of our logs, and because the address of each of these requests holds the reference of the shared workout and, while it is open, the number of the last step that phone has, those two are in its access line as well, and it counts towards a rate limit, which keys a counter on your account for the minute being counted. At the standard setting that is about 1,800 requests an hour from each phone while a shared workout is open. Beyond those lines and that counter, asking stores nothing; a step you make is one more request of the same kind, and what it stores is the step. The app also asks once, each time it opens or comes back in front of you, whether a shared workout is open or waiting for you. It asks again when one of the calls described below under your status answers that a shared workout has appeared or changed.

A shared workout ends when either of you ends it, or when your connection with that trainer ends. Finishing its last exercise does not end it, and neither does closing the app or signing out: it stays open on our servers and for the other person. When it ends, or when the trainer's app is next opened after that, it reads the steps from our servers and builds the draft of a report from the sets that were logged, if any were, and keeps it on the trainer's phone with the ratings, notes and flags held there, as it does with a session the trainer logs alone. That draft exists only on the trainer's phone: a deletion on our servers does not reach it, and a report reaches you only if the trainer sends one. A screen you have not answered stays until you answer it, the trainer stops waiting or your connection with that trainer ends. Nothing else times it out, and one still unanswered 45 days after the trainer started it is deleted with the rest.

A trainer's app is told, yes or no, whether it can ask you. The answer turns on whether a phone of yours has a version of the app that can show the screen, registered in the last 60 days, and on whether we have switched shared workouts on for both of you. If the trainer asks while you already have a shared workout open or waiting with someone else, which can only be so if you coach clients of your own, the trainer's app is given the same answer as for a phone that cannot show the screen, that you cannot join from your phone, and never with whom. A trainer whose app had just been told it could ask you may still work out that something else of yours is open. A trainer can start a workout with you at most 5 times in 10 minutes and 20 times in any 24 hours. When one does, a notice goes into your inbox with the trainer's name, and if you allow notifications and have left that kind switched on, a notification is queued for each phone of yours that has such a version; its text names nobody and no workout. When you join, or answer that you cannot, the trainer gets a notice with your name and a notification, and neither holds your reason. No notice is written and no notification is sent when the trainer stops waiting, when either of you ends the workout, or for a step; the other phone learns of those from its own calls. The notification that a trainer is waiting for you waits out your quiet hours like any other, and we go on trying to send it for 15 minutes only: if it is still held back then, by your quiet hours or anything else, or if the invitation has been answered or cancelled in the meantime, it is not sent at all. An invitation that is still waiting shows its screen when you next open the app, whether or not a notification was sent. The trainer is not told whether one was.

What a trainer's app counts. A trainer's app shows that trainer, for each client and for the last 30 days, how many booked sessions the client cancelled, declined or left unanswered, beside how many were booked; and, in versions that have shared workouts, how many of them the client cancelled, beside how many the client answered at all, by joining or by cancelling. It is counted on the trainer's phone: the booked sessions from the ones that trainer is already shown, and the shared workouts from a list our servers give that trainer's app of the ones they started in the last 42 days with clients they are still connected with. For each one that list holds which client it was with, whether it is waiting, open, cancelled or ended, when the trainer started it, when the client joined, and when and by whom it ended. A workout the trainer cancelled, one nobody answered, and one that was closed because the connection ended are not counted. No reason is in that list or in the count, and you are not shown the count.

The inbox of notices. AthleteOS has an inbox, and we write a notice into it when something happens that concerns you. Everyone gets one when they set the app up. As an athlete you get one when a trainer invites you; when a trainer accepts or declines your request to join; when a trainer ends the connection; when a trainer adds or changes your plan; when a report is waiting for you; when a trainer reminds you to train; when your weekly gym sessions change; when a trainer books, moves or cancels a session; and when a trainer starts a shared workout with you. As a trainer you get one when an athlete asks to join you; when a client accepts your invitation; when a client leaves; when a client accepts, declines or cancels a booked session; and when a client joins a shared workout you started, or answers that they cannot join. A notice holds its kind, whether it is for you as an athlete or as a trainer, when it was written, whether you have read it, a reference to the thing it is about, and the few words the app needs to show it: the other person's name as it was at that moment; for a plan or a report, the name of the plan or of the workout; and for a booked session, its date and time. It holds no comment, no reason and nothing else from a plan or a report.

We keep the 500 newest notices for each person and delete the oldest as new ones arrive; the app is sent the newest 200. A newer notice about the same booked session, the same reminder to train or the same weekly schedule replaces the older one. A newer invitation to a shared workout from the same trainer replaces the notice about the older one, whatever the connection, and once an invitation has been answered, cancelled or closed we mark its notice read. The notice about an invitation is deleted together with the shared workout it is about, when we delete that after 45 days (section 15). You can mark a notice read or remove it yourself, and all of yours are deleted with your account. A notice in somebody else's inbox that names you is theirs and not yours: it stays there, with your name as it was, until they remove it, newer notices push it out past the 500, or their account is deleted. Changing your name does not change it, and deleting your own account does not remove it.

Ending a connection, and what stays. Either of you can end a connection at any time from the app. Ending it stops the trainer reading your plan at once, and neither of you is shown a booked session any longer; the same goes for your status and the trainer's profile, described below. A shared workout the two of you were running ends at that moment, and an invitation to one that is still waiting is cancelled. Our servers go on letting that trainer's account read what was logged in a shared workout you joined, under the name you have then and with the copy of the workout it was run from, until it is deleted (section 15). That copy is a part of your plan as it was when the workout was started, and it is the one part of your plan that trainer can still read; the trainer's app builds the draft of its report from the steps. Our servers accept no new report over a connection that has ended, so that draft is not sent to you and stays on the trainer's phone. Of one you did not join they go on answering only the bare record, which is the name you have then, the workout's slot and name, when it was started, and how and when it was closed, without the copy of the workout and without any reason you typed. The client's account, for its part, can go on reading any shared workout with that trainer, joined or not, with the copy of the workout, every step the trainer made in it and the name the trainer has then, until it is deleted. It deletes the weekly gym sessions set for you and cancels any booked session still ahead, and the other person gets a notice, with your name on it, that the connection ended. It does not delete the record of the connection, for the reason in section 5.12: it is what shows the disclosure was one you agreed to, and when.

Other things stay as well, and not only on your side. Reports already sent to you stay in your app. The trainer keeps the same reports on their side, shown under the name you have now. The private notes the trainer wrote about you stay on our servers, which still let that trainer's account read them and add to them, although the trainer's app stops listing you as a client. Booked sessions that are past, declined or cancelled stay in our records until 400 days after their start time, shown to neither of you. And the notices each of you already has stay in your inboxes as the paragraphs above describe.

The connection record, the reports and the private notes last until one of the two accounts is deleted, and then they go for both of you. Deleting your account deletes every connection you were part of and everything attached to it: the reports a trainer sent you, that trainer's private notes about you, the weekly gym sessions, the booked sessions and any shared workouts we still hold. It works the same in the other direction: if your trainer deletes their account, the reports they sent you are deleted with it. A plan a trainer wrote for you is yours and stays. Sections 15 and 16 give each period and say what a deletion leaves behind.

Your status, and when you were last active. While you have an active connection, each of you can see whether the other is around. For that we hold one record per person, with three things in it: the status you chose, which is Online until you change it, Busy or Invisible, and when you chose it; the time the app was last open in front of you, rounded down to the minute; and the moment up to which you count as having the app open. Each time we record it we set that moment 90 seconds ahead; if we slow the app's calls down, which the next paragraphs describe, it is set further ahead, and never more than 199 seconds. When the app tells us it is leaving your screen, we set it to the moment that call arrives instead. It is kept exactly, not rounded, and it stays in the record after it has passed, until the next one replaces it. Each new value overwrites the one before, so this record holds no history of when you used the app. We record the minute, and open or extend that window, only while you have an active connection; a status you choose is recorded when you choose it, with or without one.

Only the other side of an active connection sees any of it. Your trainer, whom the app calls your coach, sees yours and you see theirs; if you are a trainer, each client you are connected with sees yours. A trainer's other clients never see you, nothing is shown over an invitation or a request that has not been accepted, and it stops being shown the moment the connection ends. The other person's app is told whether you are active, busy or offline, and that minute; it is never sent the exact moment above. What they see is that you are active now, or busy, while the window is open, and after that when you were last active: in minutes for the first hour, then in hours for the rest of that day, then as yesterday, and after that as a date. Nobody is sent a notification when your status changes.

Invisible is how you switch that off, under Profile and then Your status. It erases both times and stops us recording them, and the other person sees you as offline with no time, which is exactly what they would see if you had never opened the app. Invisible hides your status and those two times, and not what you do: in a shared workout, starting it, joining or cancelling it, and each step you make in it are shown to the other person as they happen whatever your status, as the paragraphs on those workouts say above. The choice itself, and when you made it, stay in the record. Whichever status you chose, the record lasts until your account is deleted. It does not expire by itself, so if you stop using the app while a connection is still active, the other person goes on seeing when you were last there. It is not erased when a connection ends either: nobody sees it then, but if you connect with someone new, they see the last time recorded before, until the app is next open in front of you.

To keep these screens current the app calls our servers while it is open in front of you: about every fifteen seconds if you have a connection, or an invitation or a request still waiting, or are a trainer, and about once a minute otherwise. Fifteen seconds is the standard setting, and we can move it between ten seconds and two minutes without an app update. As the app leaves your screen it makes one last call to say so, and then no more of them while it is in the background. Each call is an ordinary request: it leaves the log lines described in section 5.2, the access line with your IP address among them, kept for 30 days like the rest of our logs, and it counts towards a rate limit, which keys a counter on your account for the minute being counted. Beyond those, we store nothing about a call apart from the record above. Choosing Invisible does not stop these calls or those log lines. In versions of the app that have shared workouts, the answer to each of these calls also tells the app whether one is open or waiting for you, which is how an open app learns of one. While one is open or waiting, the app makes a second and faster set of calls, which the paragraphs on those workouts describe above.

What a trainer chooses to show their clients. A trainer can fill in a profile: a headline, a short bio, up to three specialties from a fixed list, years of coaching, up to five certifications, the name of their gym, their city, up to six languages they coach in, and, if they want to be reached outside the app, a contact email address, a phone number, an Instagram username and a website. Every field is optional and entered by the trainer; we never fill the contact email in from the address they sign in with. Each field has its own switch for showing it to clients, and we hold which switches are on and when the profile was last changed. For the first eight fields the app turns the switch on by itself when the trainer fills in one that was empty, unless they have just set that switch themselves, and the trainer can turn it off again. The four contact details are different: they start switched off and stay off until the trainer switches each one on. A client with an active connection sees the fields that are both filled in and switched on, together with the trainer's name and status, and nobody else sees any of it. That client's app is also told when the profile was last changed, so that it knows when to fetch it again; it does not show that time. There is no photo in that profile. Profile pictures. In versions of AthleteOS that offer it, and only while we have switched it on for your account, a profile picture you choose in the app is sent to us and kept on our servers at Amazon Web Services in the EU, so that you, and the other person on each active connection you have, as a trainer or as a client, can see it; nobody else is shown it, and ending a connection stops that person seeing it within an hour. It must be a JPEG file of at most 2 MB, with each side between 64 and 2048 pixels. Before we store it we remove everything in the file other than the picture itself, such as the camera details, the date, any location the phone recorded, colour profiles, comments and any small preview image. We keep it until you replace it, which deletes the earlier one, until you remove it, which you can do at any time, or until your account is deleted, which deletes it too. If we switch the feature off, nobody is shown it from an hour later, and you can still remove it. The profile stays until the trainer changes it or deletes their account; ending a connection does not delete it, because it belongs to the trainer, but that client stops seeing it. A trainer who switches their account back to an athlete's keeps the profile, and a client still connected to them goes on seeing it, but the app lets them edit it only while the account is a trainer's. They can ask us to change or remove it at any time (section 19).

Notifications, and the record of your phone behind them. While you are signed in, the app registers that installation with us, whether or not you allow notifications. We use the record so that a notification is written in your language and waits out your quiet hours; so that a phone is sent only the kinds of notification its version of the app can show; so that we stop sending to a phone you no longer use; and so that we can tell a trainer you are connected with whether a reminder to train, a session they book or a shared workout they want to start can reach you. What the trainer's app is told is a yes or a no, which turns on whether a phone of yours has a recent enough version of the app, registered in the last 60 days and, for a reminder, told us its time zone; and, when a reminder has to wait because it is between 22:00 and 08:00 where you are or because the day's limit there is used up, the time from which one can be sent.

The record holds an identifier the app generates at random, which is not your advertising identifier or anything else that came with the phone; a one-way fingerprint of a random secret the app also makes and keeps on the phone, so that only that installation can change or remove its record; whether the phone is an iPhone or an Android phone; the app's version and build, and which kinds of notification that version can show; your language and time zone; whether the app on that phone is in its Free or its Premium mode; whether notifications are allowed; the day on which the app last registered, which is what the deletion periods below count from; and three exact times: when the record was first made, when the app last registered, and when its push token was last registered. The app sends us the secret itself with each registration and when you sign out, as proof that it is the same installation; we keep only the fingerprint. The app registers when you sign in, each time it starts, when something in the record changes, and when you come back to it after a day. We also hold your notification choices: which kinds are switched on, your quiet hours, when you last saved those choices and, separately, when you last changed the reminders choice, and whether you have muted a trainer's reminders to train and since when. A trainer whose reminders you have muted is shown that you turned them off, and not when.

If you allow notifications, the record also holds a push token, the address that lets a message reach that one phone. Where we have switched a token off or removed it ourselves, the record says why, for example because Expo reported that it no longer works, because another installation registered the same token, or because the account already had five phones receiving notifications. We hand each notification to Expo, which passes it to Apple for an iPhone or to Google's Firebase Cloud Messaging for an Android phone. To get the push token, Expo's component in the app sends Expo the token Apple or Google issued for that phone, the app's identifier, our project identifier, and an installation identifier that the component generates at random and keeps on the phone, and in doing so shows Expo your IP address. The app asks for the token each time it registers while notifications are allowed. Expo's component also renews that registration by itself when the app starts, if the token has changed or seven days have passed, and nothing in the app switches that renewal off when you stop allowing notifications or sign out. After that Expo receives each notification we send, addressed to the push token, and Apple or Google receive what they need to deliver it. On Android, Google's Firebase component in the app creates an installation identifier of its own for that copy of the app, at the latest when notifications are first allowed on it. We have set the app not to create it earlier, and we do not promise that the setting holds on every phone. That identifier belongs to the copy of the app, not to your account, and signing out does not remove it.

The notification's text is deliberately generic: it says what kind of thing happened, for example that a report is waiting for you or that your trainer booked a session. With it travel the kind, whether it is for you as an athlete or as a trainer, and references to the inbox item and to the thing it is about, such as a report, a connection, a booked session or a shared workout, which the app uses to open the right screen and to replace an older notification about the same thing; and, on an iPhone, the number of unread items to show on the app's icon. It never carries a name, a comment, or the contents of your plan, your workouts or your reports. You can stop notifications at any time in your phone's settings, and choose which kinds you get under Profile and then Notifications.

The record of an installation is deleted when you sign out on that phone: the app asks us to delete it then, and if that request does not get through it tries again the next time the app is opened. It is also deleted 60 days after the app last registered on that phone if it holds no token, 180 days after it last registered in any case, when an account passes 20 installations, starting with the one used longest ago, and with your account. A token Expo tells us has stopped working is cleared as soon as we learn it. We keep a log of the notifications we queued for sending. For each one it holds the kind, which installation it was for, references to the inbox item, to the thing it was about and to the connection, which for an invitation includes the internal identifier of the other person's account, the receipt number Expo gave us, a short one-way fingerprint of the push token, how many times we tried, the outcome with any error code, and the times; it never holds the text. An entry is deleted once it is 30 days old, and sooner if you sign out on that phone or the inbox item it belongs to is removed. We also keep the time of each reminder to train a trainer sends, and the connection it was sent on, for 30 days, because the limits on those reminders are counted from that record; it holds no text.

On the phone itself the app keeps, in its secure storage, the identifier and the secret above, the last push token it was given and the Apple or Google token behind it, whether you said yes to notifications in the app, when and how often we have asked you, and any sign-outs it has not yet been able to report to us. Signing out replaces the identifier and the secret with new ones and clears your answer and the record of our asking.

Apart from the person or people you are connected with, a trainer or a client you were connected with, whose account can still read the reports and, until it is deleted, a shared workout, each under the name you have then (the paragraphs on ending a connection, above, say what stays), the person on the other end of an invitation or a request, who is shown your name, a trainer who enters your connect code and is told that you already have a trainer, and the notification providers above, we disclose this data to no one. One other company comes into it only when a video is shown: when an exercise or a workout has a YouTube video, the app loads it in YouTube's own player, and during a workout it starts playing, muted, without your tapping anything. The video is one you added by pasting a link, one of our recommended videos that you chose to use, one a trainer with the edit permission put in your plan, or one that came with a plan or a workout somebody shared with you as a code. Google then receives your IP address and which video it is, and is told that the player sits in a page of ibomea.com; the player can also keep storage of its own inside the app (section 12). All of that is under Google's own terms, and Google receives nothing about your account from us. YouTube may show advertisements of its own inside its player. Those are YouTube's and not ours, and we do not choose them. Apart from that, this data reaches no advertising provider, it is not read into our support tools, and the subscription that unlocks AthleteOS is handled by RevenueCat exactly as section 12 describes for our other apps, which is told what you paid for and nothing about your training.

5.15 Whether you have to give us any of this

You need give us nothing to read ibomea.com. To hold an IBOMEA account you have to give us an email address and set a sign-in method; that is a requirement of our contract with you, because without it we cannot create the account, keep it secure, or tell you about it.

To run a calculation you have to fill the form in: an age of 18 or over, a gender of male or female, and every measurement the form lists except the body-fat percentage, which is the one field you can leave blank. The formulas produce nothing without the rest.

Apart from the names AthleteOS asks for, everything else you give us is optional: a display name, a profile photo, a bio, a date of birth, and the product tips in section 5.11. Not giving us an optional item costs you only the feature it belongs to. AthleteOS asks for a first name and a last name. If you add a nickname, which is optional, the nickname is what a trainer or a client is shown in place of them. Unless your account was created with Sign in with Apple or has Sign in with Apple linked to it (section 5.6), AthleteOS will not set up without both names. If you signed in with Apple, versions of AthleteOS that allow it let you leave either name, or both, empty, and the same can happen when you sign in another way to an account that has Sign in with Apple linked to it; if you leave both empty and set no nickname, a trainer or a client you connect with is shown general wording, such as Client or Your coach, in place of your name. In AthleteOS, connecting to a trainer, the edit and reports permissions, notifications, a profile picture and a trainer's profile are optional as well, and Invisible switches off the recording and showing of when you were last active; the record of your installation in section 5.14 is made whenever you are signed in to that app, and is not optional. Joining a workout a trainer starts to run together with you is optional too, and so is the reason if you cancel one; the cancelling itself is told to that trainer and counted in their app (section 5.14). Being asked is not something the app lets you switch off while you are connected: a trainer can ask within the limits in section 5.14, and ending the connection is what stops it. No law obliges you to give us any of this.

6. Sources of personal data

We collect personal data from you, when you register, use an app, update your profile or contact us; from your device and browser; from Amazon Web Services, which hosts our authentication and account database in the EU; from our app backend when you use Ideal Body Measurements or account merge; from Apple Sign In or Google Sign In when you use them; from RevenueCat, which tells us your current plan and the App Store or Google Play purchase metadata behind it; from another user, when someone hands you a referral code you choose to enter, and in AthleteOS from the person on the other side of a connection: a trainer writes the reports, private notes, weekly gym sessions, booked sessions and reasons that concern a client, and can change the client's plan where the client allowed it, and a client sends the request, the answers and the reasons that concern a trainer, while in a workout the two of them run together each makes the steps that both are shown (section 5.14); from Expo, our notification provider, which tells us whether it accepted each notification, whether Apple or Google then accepted it, and when a push token has stopped working; and from our email provider when we send account, security and product emails.

7. How we use personal data

We use personal data to:

• create and manage your account, authenticate you, and provide two-factor authentication;
• provide the features you request, sync your account across web and mobile where supported, merge duplicate IBOMEA accounts when you ask, and manage subscription status;
• in AthleteOS, keep your training plan and your finished workouts and work out your personal bests from them; let you and a trainer connect, show a trainer you are connected with your plan, and let them change it or send you reports where you allowed that; keep the private notes a trainer writes about a client, which are shown to that trainer only, and the record of each connection; keep the weekly gym sessions and booked sessions the two of you arrange and the notices in your inbox; keep a workout that you and a trainer run together in step on both phones, with the list of steps it is made of, and give a trainer's app the list it counts a client's cancelled workouts from; keep the record of your installation, deliver the notifications you have allowed, tell a trainer you are connected with whether a reminder, a booked session or such a workout can reach you, show your status to the person or people you are connected with, and show a trainer's profile to that trainer's clients (section 5.14);
• send account and security emails (welcome, verification, password reset, two-factor codes, security notices, deletion confirmations);
• send product tips and updates about the apps you use, including the single win-back offer after a subscription lapses, all of which you can turn off at any time and none of which is sent while the preference in section 5.11 is off;
• run our prize draws and referral programme: checking eligibility, awarding and voiding tickets, sending one confirmation when you enter, drawing and notifying winners, and paying prizes;
• show advertising in Ideal Body Measurements, which is what funds its free tier (section 5.10);
• respond to support requests you send us;
• maintain security, prevent fraud and abuse, and troubleshoot errors;
• comply with law and enforce our Terms of Service;
• improve reliability and fix bugs, using the logs, error monitoring and performance measurements in section 5.8;
• measure how the product is used, by counting saved calculations, unlocked achievements and completed profiles in aggregate on an internal dashboard, which reads the number of rows and no individual entry. For AthleteOS the same dashboard counts how many people have set it up, how many finished a workout in the last day, 7 days and 30 days, and how many hold a paid subscription; for that it reads whose workout a row is, its calendar day and when it ended, and nothing else in it. Where our newer internal dashboard is switched on, it counts more about AthleteOS, and shows it as totals, never as one person's records: new accounts, accounts by role, and how many accounts are in both apps; workouts by day and by the weekday and hour they started, and their median length; plans by sport, by days a week and by whether a trainer last changed them; personal bests set; connections by state, how many were accepted or declined, and how many trainers have an active one; reports sent and how many have been opened; notices by kind and how many are unread; and subscriptions by state, store and product.

Section 9 sets out what we do with your measurements, and the short list of things we never do with them.

8. Legal bases, and the advertisement request we have no basis for

Where required, we rely on one or more of the following.

• Contract: to provide the account, sign-in, profile, subscription and account-merge features you ask for; to run the calculations you ask for and keep the history that makes them worth having; in AthleteOS, to keep your training plan, your finished workouts, your personal bests and your inbox, the weekly gym sessions and booked sessions you and a trainer arrange, and a workout a trainer and a client run together, which opens only once the client has tapped Join; to deliver the AthleteOS notifications you allow, to keep the record of your installation that those notifications and a trainer's reminders, bookings and such workouts depend on (section 5.14), and to show a trainer's clients the profile that trainer chose to share; and to run a prize draw you enter under its published rules.
• Legitimate interests, in each case balanced against your rights:
  • keeping accounts secure: detecting suspicious sign-ins, rate limiting, two-factor checks, fraud and abuse prevention;
  • keeping the Services running: server and API logs, error reports and fault diagnosis;
  • in AthleteOS, showing your status and when you were last active to the person or people you are connected with, and theirs to you, so that each of you can tell whether the other is around. Invisible is how you object; it needs no reason and takes effect at once (section 5.14);
  • in AthleteOS, keeping the private notes a trainer writes about a client, while the trainer coaches that client and after the connection ends, as the trainer's own record to coach from, and keeping in each person's inbox the notices that name the other person (section 5.14);
  • in AthleteOS, keeping the record of a shared workout from the moment a trainer starts it, before the client has answered, with the copy of the workout it would be run from; giving that trainer's app the list it counts a client's joined and cancelled shared workouts from; and, after a connection ends, letting that trainer's account go on reading a shared workout the client joined, and the client's account any shared workout with that trainer, until it is deleted, so that the trainer's app can still build its draft of the report, which our servers do not accept over a connection that has ended and which therefore stays on the trainer's phone as the trainer's own record (section 5.14);
  • receiving, routing and answering the support enquiries you send us, which is what puts your message, your address and the account summary in section 5.7 through our workflow tool, our language model provider and our team workspace;
  • threading duplicate support requests so you are not answered twice;
  • working out from the ratings people leave which of the help assistant's answers are failing;
  • screening a profile photo you upload, and the username and bio you choose, before they are stored or shown;
  • creating and keeping a referral code on your account the first time you open the prize draw screen, so it is ready if you share it and so the rule that a person may be referred only once can be enforced across campaigns;
  • sending account holders product tips and updates about the IBOMEA apps they use, which you can stop at any time without giving a reason;
  • sending a lapsed Premium subscriber the single win-back offer in section 5.11, where they still have an account and have product tips on;
  • counting activity in aggregate on our internal dashboard;
  • keeping a durable queue for the email we send you, so a message survives a restart and is not sent twice while it waits;
  • establishing, exercising or defending legal claims.
• Consent: for advertising in Ideal Body Measurements where Google's consent message is shown, whether the advertisement is personalised or not; in AthleteOS, for letting a trainer read your training plan and, where you allowed it, change it and send you reports, which you agree to when you accept an invitation or send a request and take back by ending the connection (section 5.14), except that a shared workout you joined stays readable to that trainer until it is deleted, as that section says; and for anything else we describe as optional and ask you about first.
• Legal obligation: to comply with applicable law, tax, accounting and regulatory requirements; to answer lawful requests from authorities; and to show, as Articles 5(2) and 7(1) require of us, that you were given the Terms and this Policy and which version of each, which is what the acceptance record in section 5.12 is for and why it holds a shortened IP address. The record of what you agreed to when you accepted an AthleteOS invitation or sent a request is kept for the same reason (section 5.14).

We do not rely on legitimate interests for advertising, anywhere. In the EEA, the United Kingdom and Switzerland the only thing we rely on for it is the answer you give to Google's consent message (section 5.10).

Body measurements and every figure we calculate from them need one of the bases above and something further, because Article 9 prohibits processing data concerning health unless a condition in Article 9(2) is met as well. Section 9.1 says which basis covers them and why the further condition is one we do not have.

8.1 The launch-time advertisement request, which we have no basis for

The app does not wait for the consent check to finish before it starts Google's advertising component and asks for an advertisement. So on a launch where your answer is not already on record - a first launch, or the first after you withdrew - a request can reach Google before there is an answer to rely on. Asking for a non-personalised advertisement does not put that right: the request still goes, still carries your IP address, and on Android can still carry your advertising identifier, which has to be read off your device to get there.

Consent counts only if it comes first. Section 89(3) of Act No. 127/2005 Coll., which implements Article 5(3) of the ePrivacy Directive here, allows us to reach into your device without it only where doing so is strictly necessary for something you asked for. An advertisement request is not that. Having ruled out legitimate interests for advertising, we are not going to reach for them in this one window either. So for it we have no lawful basis to give you.

The same launch does not check whether you have paid, either, so the request goes on a Premium account too. You are never shown the advertisement it was preparing, and that part of what you paid for holds, but the request still leaves your device with the same IP address and, on Android, the same advertising identifier. Advertising is the only purpose it serves, and on an account that will never be shown one there is no purpose left to attach a basis to.

Both are defects in the app: it has to read your consent answer and your entitlement before starting the component, not after. Until it does, this is the accurate description, and Addendum B says what it means for paying subscribers under US state law.

8.2 Email, where Article 6 is not the whole question

Whether we may send you a commercial email at all is decided somewhere else: by section 7 of Act No. 480/2004 Sb., which implements Article 13 of the ePrivacy Directive here. That lets a trader email its own similar products to someone whose address it obtained in connection with a sale, so long as that person was given a clear chance to refuse when the address was taken and again in every message since; where the address did not come from a sale, it wants consent, given first.

A free account has bought nothing from us, so for most of the people holding one the sale route is not open, and the sign-up form does not ask about email either way. An account created now starts with the preference off, so nothing is sent unless you turn it on yourself (section 5.11). An account created before we changed that had the preference started on without being asked, and keeps that setting until it is turned off. Having a way out is not the same as having asked you first, and we are not going to write as though it were. The win-back offer sits differently: it goes only to someone who bought a subscription and let it lapse, so it is the one case where the sale route is open to us, and it carries the opt-out link that route requires.

8.3 Decisions taken without a person, and your right to object

A few things happen to what you give us with nobody looking, and it is better to list them than to let you find them. An address from a disposable or throwaway inbox service is refused at sign-up, and again if you try to enter a prize draw with one. A username or short bio is refused if it matches our word list. A profile photo is refused if the check in section 5.3 comes back as explicit adult content or its description matches a blocked term. Each can be put to a person: write to support@ibomea.com and we will look at it and tell you the outcome. None of them is a decision based solely on automated processing that produces legal effects concerning you or similarly significantly affects you within the meaning of Article 22, and we do not profile you.

You may withdraw consent where processing is based on consent, without affecting prior lawful processing. Where we rely on legitimate interests, you can object at any time on grounds relating to your particular situation: email us and tell us what you object to. We will stop unless we can show compelling legitimate grounds that override your interests, rights and freedoms, or unless we need the data to establish, exercise or defend legal claims. Where the processing is direct marketing, you do not have to give us a reason and we stop.

9. Body measurements: health data, and the consent we do not ask for

Your body measurements, and every figure we calculate from them, are data concerning health under Article 9 of the GDPR. That is not a courtesy classification. The app places your BMI against the World Health Organization's adult cut-offs, sets your body fat, waist-to-height and waist-to-hip figures against published health bands, and tells you which side of each one you are on. Putting a number against a health threshold and reporting the answer is what makes the number health data. We apply the same classification everywhere we operate, whether or not your local law requires it, and it is what makes this data sensitive personal information in California and consumer health data in Washington and Nevada. One rule, applied everywhere, is easier for you to hold us to than three.

Being health data is a fact about how the numbers have to be handled; it is not a verdict on you. The app compares what you enter with published population reference ranges and shows you where you sit against them. It gives no medical advice, diagnosis or treatment, and section 10 says so in terms. The one inference it draws about your health from your numbers is the waist milestone in section 9.2. Nothing is measured for you and nothing is read from your device's sensors: every number we hold is one you typed into the form and asked us to calculate on, or a figure worked out from those numbers at that moment.

9.1 What we rely on, and the condition we do not have

This data needs two things rather than one, and we have one of them. Producing the figures you asked for and keeping the history that makes them worth having is the service you came for, so our basis for it is the contract between us, the same basis section 8 gives for the rest of the account.

Article 9 then adds a requirement of its own: data concerning health may not be processed at all unless one of the conditions in Article 9(2) is met as well, and for a product like this one the only condition capable of covering the ordinary running of it is your explicit consent under Article 9(2)(a). Explicit consent has to be put to you as its own question, in plain words, and answered before the processing starts; an act that is only the act of using the feature is not it, however deliberate. The app never asks you, so we do not have it, and we are not going to name a condition that does not fit. The box you tick when you create an account is not it: it records that you were given the Terms and this Policy to read, and the endpoint behind it will not store a health consent sent alongside them, exactly so that the two can never be run together. That is a defect in the app and not something this page can put right; the app has to ask you separately, before your first calculation. The place to record such an answer now exists on our side, separately from the box above and with a route to take the answer back again, and it is empty: a record of a question nobody has been asked is not a consent, and we will not describe it as one until the app asks. If there are measurements you would rather we did not process, do not enter them, and delete the ones already saved.

One narrow case is different, and saying so is not a way of widening the rest. If a court or a public authority compelled us to produce this data, or if we needed it to defend a claim someone brought about it, the condition would be Article 9(2)(f), which covers legal claims and courts acting in their judicial capacity. It reaches nothing outside that, and it has never been used.

9.2 What we do with it, and what we never do

We use this data to produce the figures you asked for and to keep your history. Three smaller things touch the same numbers, and a list that calls itself complete has to carry them. Your achievements are worked out from them: the waist milestone sets the first waist and body mass index you logged against the published healthy range and asks whether your later measurements moved toward it, which is an inference about your health drawn from your own numbers; it is worked out on your device, and the achievement that comes out is saved to your account. We count entries on an internal dashboard - how many calculations were saved in a week, how many achievements are held, how many profiles are complete - which reads the number of rows and no measurement and no figure from any of them. And when a referral ticket is checked we ask the app database one yes-or-no question, whether the account has saved any calculation at all, and read nothing that is in one.

With those three, that is the whole list. This data is not used to secure your account, and it is not read into our support tools: the account summary our help assistant is given carries which apps you have and whether you are on the free or paid tier, and no measurement and no calculated figure at all. Nobody on our side opens your measurements to answer a support message; if a measurement reaches support, it is because you typed it into the message yourself. We do not build a profile of you from it, we make no automated decision with it that has a legal or similarly significant effect on you, and we do not sell it.

None of it is ever sent to an advertising provider, in any region: not the measurements, not the figures, not your gender, and not your date of birth.

9.3 Deleting your measurements

You can delete saved measurements yourself, at any time, and this is the fastest route there is. Open your history in the app and delete entries one at a time, or select several and delete them together. That removes them from our servers and not only from the screen, and if the device is offline when you do it, the deletion reaches us as soon as the app can send it.

We record the deletion as well as carrying it out, so a copy still sitting on a second device you have signed in on cannot put the entry back the next time that device syncs. That record holds a one-way fingerprint of the entry and the date it covers, never the measurements themselves: enough to recognise the same entry arriving again and refuse it, not enough to rebuild it. The second device goes on listing its own copy until you delete it there too; what it can no longer do is return it to us.

Deleting your account deletes all of them, with two exceptions that section 16 sets out: if you have won a prize, nothing is deleted until a person steps in, and if you merged two logins, only a deletion asked from the surviving login removes your measurements. You can also email support@ibomea.com and ask us to erase your measurement records.

10. Health and wellness disclaimer

Ideal Body Measurements and similar products are for informational and tracking purposes only. They do not provide medical advice, diagnosis, or treatment. Consult a qualified healthcare professional before making health or fitness decisions.

11. Children and age

You must be at least 18 to hold an IBOMEA account. Where the age of majority where you live is higher, that higher age applies instead. That is our rule, and the reason for it is the product: every reference figure Ideal Body Measurements compares your measurements against comes from adult populations, and none is valid for anyone younger. The Services are not directed to anyone below that age, and we do not knowingly collect personal data from them.

Nothing verifies your age. The website's sign-up form for an email address and a password will not go on until you tick a box saying you are 18 or older, and we record that declaration (section 5.12); the apps' sign-up screens, and signing up with Apple or Google, ask nothing about age. The limit is our rule, not something we check. Where Ideal Body Measurements does ask for an age it holds the line at 18: the measurements form will not run a calculation below it, the two body-fat calculators that ask for an age refuse anything lower, and the date-of-birth picker on your app profile neither offers nor accepts a date that would make you younger. AthleteOS asks for no age and no date of birth.

If you believe someone under 18 holds an account or has given us personal data, contact support@ibomea.com. We will close the account and delete the data held under it.

12. Third-party service providers

Processors acting on our instructions. These providers handle personal data only as we tell them to, under a contract that requires it.

| Provider | Role | Typical data | Where |
| --- | --- | --- | --- |
| Amazon Web Services EMEA SARL | Identity (Amazon Cognito), account database (Aurora PostgreSQL), our APIs, content delivery, logging | Email, account IDs, hashed credentials, two-factor state, profile, measurement and progress records, AthleteOS training plans, workouts, reports and notes, prize draw records, server logs | EU (eu-central-1, Frankfurt); the delivery and firewall layer answers from the location nearest you |
| IBOMEA app API (our own backend, listed so you can see where app data lives) | Ideal Body Measurements data and account merge | Measurement and progress records, merge codes, app user records | EU (on AWS) |
| RevenueCat | Subscriptions and purchases | Purchase and subscription status, an identity for each installation, your account identifier once you sign in | United States |
| n8n | Support and operations workflow | Contact and help-assistant messages, email address, support request IDs, account lifecycle events, ratings with short extracts, and the mail it reads out of our support mailbox | EU (Germany; its hosted service stores data in Frankfurt) |
| OpenAI | The website help assistant; sorting support mail and drafting a reply for a person to review | Your message and the last few in the conversation, email address, account identifier and display name if signed in, support reference, the page you were on, a summary of your account | United States |
| Slack Technologies (Salesforce) | Internal support triage and routing | Support message content and recent history, email address, support request IDs, ratings with short extracts, deletion notices with a masked address and partial account identifier | United States |
| Google Cloud Vision | Safety rating and labelling for profile photos you upload | The image, for the duration of the check | United States |
| Mailgun | Email delivery | Email address, message metadata, and the content of account, security and product emails | EU (Mailgun's European region) |
| Cloudflare | Authoritative DNS for ibomea.com | DNS queries for our domain names | United States |
| Sentry | Error monitoring (app and servers) and performance monitoring (app) | Error reports and limited technical context; app start, drawing, screen and request timings from a sample of traced operations | United States |
| Expo, Inc. | Over-the-air app updates; passing AthleteOS notifications on to Apple and Google | Device platform, app version, update channel, IP address, and an installation identifier generated by Expo's update component in the app; for notifications, the push token, the token Apple or Google issued for the phone, the app's identifier, an installation identifier generated by Expo's component in the app, and the notification itself, which holds no name and none of the contents of your plan, workouts or reports | United States |

The mailbox behind support@ibomea.com is hosted by an email provider, which therefore holds the correspondence you send to it and the replies we send back, and our support workflow tool reads that mailbox. Ask us and we will tell you who that provider is and where they hold it.

Open and click tracking is turned off on the email our website and account systems send, so for those we do not record whether you opened one or which link you followed. Two other paths do not set it: the app's own account mail, and the verification and password-reset codes our sign-in system sends. Those take whatever our email provider's account default is, which is not fixed anywhere in our code, so we are not going to make you the same promise for them until it is.

Independent controllers. These companies decide for themselves how they use what they receive, under their own privacy policies. We cannot instruct them on that processing, and this Policy does not cover it.

| Company | Role | Typical data | Where |
| --- | --- | --- | --- |
| Google Ireland Ltd | Rewarded video advertising in the app (AdMob) and the consent message shown before it | IP address, device and advertisement interaction data, the consent choice you record, and on Android your advertising identifier | Ireland (EU) |
| Apple and Google | Sign in with Apple, Sign in with Google | Account identifiers and email address, as authorised by you | United States |
| Apple and Google | App distribution and in-app subscriptions | Purchase and subscription metadata | United States |
| Apple and Google | Delivering notifications to your phone (Apple Push Notification service; Firebase Cloud Messaging) | The token they issued for the phone, and the notification; on Android, the installation identifier Google's Firebase component creates | United States |
| Google LLC | The address the app requests to tell a real connection from a captive network (section 5.8) | Your IP address and the fact that a request was made. No account data | United States |
| Google (YouTube: Google Ireland Ltd for people in the EEA and Switzerland, Google LLC elsewhere) | The video player AthleteOS loads when an exercise or a workout has a YouTube video (section 5.14) | Your IP address, which video it is, the address of our website, which the player is told it is embedded in, and whatever the player keeps in its own storage inside the app. No account data | Ireland (EU) or United States, by where you are |
| Google | The library that searches a picture for a QR code in the Android versions of AthleteOS that have the scanner (section 5.14) | What the library reports about its own working: information about the phone and the app, identifiers for the installation, performance figures, settings, and event and error codes, with your IP address. Google says it includes no picture and nothing read from one. No account data | Google LLC, which provides the library, is established in the United States |
| PayPal | Paying a prize to a winner paid that way | The winner's name, the PayPal address, the amount and the payment reference | PayPal's European entity is in Luxembourg; its group is established in the United States |

Where a prize is paid by bank transfer instead, it goes through our bank and the winner's. Those banks act on their own account and under banking law, not on our instructions.

We run no advertising or marketing analytics tool of our own, in the apps or on the website, and we host no public user-to-user content. What we learn about where installs come from, we learn from the stores' own reports, which count installs against the labels our own links carry (section 13). The only measurement we take of how the product runs is the error and performance reporting in section 5.8. We may add or change providers as the Services evolve, and we will update this Policy where a material change affects how we process personal data.

13. When we share personal data

We may share personal data with the service providers listed above, only as needed to operate the Services; with Apple or Google when you sign in or purchase through their platforms, or when an AthleteOS notification is delivered to your phone; with authorities or advisors when required or permitted by law; and with successors in a merger, acquisition or asset sale, subject to applicable law.

One disclosure is to another person rather than to a company, and you decide it: in AthleteOS, a trainer you connect with, whether you accepted their invitation or they accepted your request, can read your training plan and sees when your most recent workout ended, and can change the plan or send you reports if you allowed that. Before either of you has accepted, each of you is already shown the other's name. While the connection is active each of you also sees the other's status and when they were last active. That part is on from the start; either of you can switch your own off by choosing Invisible. You also see the profile your trainer chose to share, the two of you see the weekly gym sessions and booked sessions the trainer sets, with any reason one of you typed when declining or cancelling one, and a notice in the other person's inbox carries your name. In a workout the two of you run together, each of you sees the steps the other makes as they happen, the trainer sees every figure that is logged, and the trainer reads any reason you typed when cancelling one. After a connection ends the trainer still has the reports they sent you and their private notes about you, and can still read what was logged in such a workout, if you joined it, until it is deleted. Section 5.14 says exactly what all of that covers and how to end it.

Where Google's consent framework reports that you agreed to personalised advertising, or that no message is required for your device, the app requests personalised advertisements. Google then receives your IP address, information about your device and the app, and your interactions with the advertisement, and on Android your advertising identifier. Under some US state laws, including California's, that disclosure is sharing personal information for cross-context behavioural advertising, and because Google pays us for the advertising it supports, it is also a sale. Addendum B says so in those words and sets out what you can do about it.

Two places on the website and in Ideal Body Measurements hand you off to somebody else's site. If you use the contact page's draft helper and have no mail app set up, the buttons for Gmail and Outlook open those services with your draft already in the link, which puts the text you wrote into a web address sent to Google or to Microsoft. And claiming a social-follow ticket in the prize draw opens Instagram, TikTok or YouTube before the ticket is recorded. In both cases you are visiting those companies' own sites under their own terms, and we send them nothing about your account.

AthleteOS has three more. Watch, on the recommended video for an exercise, opens that exercise's page on muscleandstrength.com, a site we do not run, in a browser window inside the app. On the page about your trainer, an Instagram name or a website the trainer chose to share opens Instagram or that website, and a shared email address or phone number opens your mail or phone app. And a link inside YouTube's player, such as its logo, opens YouTube itself. In each case you are visiting somebody else's site under its own terms, and we send it nothing about your account.

Links on our website that open Google Play carry a label of ours in the address, saying which of our pages the link was on: the app page, an invite page or the QR code beside the store buttons. Where we share a download link of our own, which sends a phone straight to its own store, Google Play or the App Store, the link passes that store the short tag it was shared with, for example the name of the place it was posted, or a standard label when it was shared with none. The store receives the label when you follow the link, and its own reports show us installs counted against it. The label describes the link and not you: nothing about your account is in it.

14. International data transfers

IBOMEA is based in the Czech Republic and your account data is stored in the European Union (AWS eu-central-1, Frankfurt).

Some of our providers are established in, or transfer data to, the United States: Sentry, Slack Technologies, OpenAI, RevenueCat, Expo, Inc., Cloudflare (DNS for our domain names), Apple (sign-in, distribution, subscriptions and notification delivery) and Google (sign-in, distribution, subscriptions, image safety screening and notification delivery). Mailgun sends our email from its European region and its operator is established in the United States, so the safeguards below cover any access from there. The Where column in section 12 gives the position for every recipient. The content delivery and firewall layer in front of our website and APIs is Amazon CloudFront with AWS WAF, under the same contract as the rest of our AWS use; it is a globally distributed network, so your request is answered by the location nearest to you, which outside the EEA will be outside it.

Four things there are not provider relationships at all. The connectivity check in section 5.8 sends a request to a Google address every few seconds while the app is open; we have no contract with Google for it and no clauses covering it, because nothing is entrusted to Google - what reaches it is your IP address and the fact that the request was made. The YouTube player in AthleteOS (section 5.14) is the same kind of thing: when a video is shown the app loads the player from YouTube's servers, we have no contract with Google for that and no clauses covering it, and section 12 lists what reaches it. The library that searches a picture for a QR code in the Android versions of AthleteOS that have the scanner (section 5.14) is one more of the same kind: it is Google's own software reporting to Google on its own working, we entrust nothing to Google through it, and section 12 lists what Google says it reports. And where a prize is paid through PayPal, PayPal decides for itself what it does with the payment under its own terms and its own obligations as a payment institution, as do the banks at either end of a bank transfer. Google Ireland Ltd, the entity behind AdMob and the consent message, is established in the European Union; it receives that data as an independent controller and may transfer it further under its own safeguards, and we are not a party to those transfers.

For our own transfers we rely on the European Commission's standard contractual clauses in the version adopted on 4 June 2021, and on the EU-US Data Privacy Framework where the provider is certified under it. Alongside the clauses we rely on encryption in transit, encryption at rest, access controls, and sending each provider only the fields it needs. You can ask us which mechanism applies to a particular provider, and for a copy of it.

15. Data retention

We keep personal data only as long as reasonably necessary for the purposes in this Policy.

• account data, and everything held under your account: while the account is active. That includes bug reports, merge records, the profile left on a login that was merged in, marketing preference and send records, and the shortened IP address on an acceptance record.
• measurement and progress data: while your account is active, or until you delete the entries yourself (section 9.3).
• AthleteOS installation records and push tokens (section 5.14): until you sign out on that phone, 60 days after the app last registered on it if it holds no token, 180 days after it last registered in any case, until your account passes 20 installations and this is the one used longest ago, or until your account is deleted, whichever comes first. An entry in the log of notifications queued for sending is deleted once it is 30 days old, or sooner as section 5.14 describes.
• your AthleteOS status: only the latest value, overwritten each time, until your account is deleted. Choosing Invisible erases the two times at once; the status itself, and when you chose it, stay.
• a trainer's AthleteOS profile: until the trainer changes it or deletes their account. Your AthleteOS profile picture, if you shared one (section 5.14), is kept until you replace or remove it or your account is deleted. Each time it is fetched or changed, our storage writes an access line with the requesting IP address and the picture's random file name, deleted after 30 days like our other logs; the line holds no picture.
• your AthleteOS names and settings, training plan, finished workouts and personal bests (section 5.14): until your account is deleted. Saving your plan replaces the copy we hold, so of the plan itself we keep the latest version only. A shared workout is different (section 5.14): the copy of the one workout that is taken when a trainer starts it stays as it was at that moment, with any note or video link it then held, for up to the 45 days given below, whether or not you joined and whatever you change or remove in your plan afterwards. Nothing in the app or on our servers deletes a finished workout, so each one stays until the account goes; to have one erased sooner you have to ask us (section 18).
• AthleteOS connection records (section 5.14): until either of the two accounts is deleted. Ending a connection, declining an invitation or a request, or withdrawing a request closes the record and does not delete it. It holds who started it and when, the permissions granted, and, where the athlete agreed, the time of that agreement and the shortened network address it came from.
• AthleteOS reports and private notes: until either of the two accounts is deleted. Ending the connection deletes neither. The reports stay with both people, and where a trainer corrected a report the earlier version is kept as well. Our servers go on holding the private notes a trainer wrote about a former client, and still let that trainer read them and add to them, up to 500 notes for one client.
• your AthleteOS inbox: the newest 500 notices. Once you have more, the oldest are deleted as new ones arrive. A newer notice about the same booked session, the same reminder to train or the same weekly schedule replaces the earlier one, as a newer invitation to a workout you run together replaces the notice about an older one from the same trainer, whatever the connection, and you can remove any notice yourself. The notice about an invitation is deleted together with the workout it is about. A notice in somebody else's inbox that names you follows their inbox, not yours (section 16).
• weekly gym sessions a trainer sets for a client: until the trainer replaces them, the connection ends, or either account is deleted.
• booked sessions: 400 days from the session's start time, after which a job that runs every hour deletes them, or until either account is deleted if that is sooner. When a connection ends, sessions still ahead are cancelled and kept as cancelled. Neither person is shown a session of an ended connection again, and each one is deleted on the same 400 days.
• a workout you run together with a trainer (section 5.14): the steps, the copy of the workout, whether you joined or cancelled and when, your reason if you typed one, and when and by whom it ended, for 45 days from when the trainer started it, after which the job that runs every hour deletes it, or until either account is deleted if that is sooner. Ending the workout or the connection does not shorten that, and one nobody answered is deleted on the same 45 days. The client's inbox notice that the trainer started it is deleted with it when the job deletes it after 45 days, but not when the trainer's account is deleted (section 16); the other notices about it follow the inbox rule above, not this one.
• AthleteOS connect codes: a code works for 7 days, or until you ask for a new one. An old code stays in our records, no longer usable, until your account is deleted.
• the record of reminders to train a trainer sent (section 5.14): 30 days.
• server, API and error logs, including every access line described in section 5.2: 30 days, which is how long our log stores keep them, extended only where a specific investigation or a legal obligation requires it, and then only for as long as that reason lasts.
• the record that a measurement was deleted (section 9.3): while your account exists, because a device that has been offline for a year is exactly the case it exists for. We keep at most 500 per account; when we pass that, the ones we drop are those covering the oldest entries, not the ones written longest ago.
• support and contact-form correspondence: for as long as we may need it to answer you, to answer a follow-up about the same thing, and to defend a claim arising from it. There is no fixed timetable, so if you want a thread erased, ask us.
• the ratings people give the help assistant (section 5.7): the rating, and the page, route, app and time it came from, are kept indefinitely; on their own they are a tally mark. The text stored alongside is not, and no job deletes it. Nothing we run on a schedule reads it after a fortnight, because the two reports in section 5.7 look no further back than that. The one thing that can is the support page of our newer internal dashboard: where that page is switched on, it counts the words in thumbs-down ratings from the last 30 or 90 days, and shows a word only when at least five different messages used it. Either way, what you typed stays until we clear it by hand. We would rather write that down than quote you a retention period we do not run.
• prize draw entries, tickets and awards: until the draw is complete and any related legal, accounting and tax obligations have been met. Nothing deletes them automatically at that point, so this is something we do rather than something that happens. Deleting your account before then deletes your entry and tickets with it, unless you have won a prize, in which case section 16 says what happens instead.
• referral codes and referral records: while the accounts they link exist; deleting either account deletes the record.
• subscription status and the purchase events we record: while your account exists; they are deleted with it. The record our subscription provider holds is separate and outlasts the account (section 16). Where Czech accounting or tax law obliges us to keep a document about a payment, we keep that document for the period the law sets.
• backups: our database backup rotation is 35 days, so an automated backup holding your data has been overwritten 35 days after the deletion. Snapshots we take by hand before a risky change are not on that rotation: they are kept until someone deletes them, and we have set no age at which that happens.

Some records outlast an account deletion, because nothing above deletes them on a clock and the deletion does not reach them; section 16 lists them and says what to send us.

Every period above is ours. Our providers keep their own copies on their own clock: our error-monitoring provider keeps the error and performance reports, our email provider keeps what it sent for us and its content, and our support workflow tool and team workspace keep the threads in section 5.7. We have set no period on any of those, so each runs at its provider's default. Ask us and we will tell you what each of them holds about you. Expo, Apple and Google likewise keep the tokens in section 5.14, and whatever they record of a notification we handed them, on their own clock: signing out or deleting your account deletes our record of a push token, and nothing tells them to delete theirs.

16. Account deletion, and what only happens when you ask

You can schedule account deletion yourself in three places: in Ideal Body Measurements under Profile and then Security; in AthleteOS under Profile, then Privacy & Data, then Delete account; and on the website under Profile security. There is one IBOMEA account behind all three, so each of them deletes the whole account, with what every app holds under it, and none deletes one app's data and leaves the rest. Each starts the same waiting period. You can cancel it on the website or in AthleteOS. Ideal Body Measurements has no cancel of its own: when you schedule a deletion in it, it signs you out, and for as long as a deletion is scheduled it shows only a notice and sends you to https://ibomea.com/account/delete to stop it.

You can also ask by writing to support@ibomea.com. That route is different. A person carries it out by hand, and it does not start the waiting period: we have no tool that starts it for you, and the one we have for deleting an account by hand deletes it at once, with no reminders and nothing to cancel. We may ask you to show that the account is yours first. If you want the 14 days in which to change your mind, start the deletion yourself.

• Scheduling deletion in an app or on the website starts a 14-day waiting period. You can cancel at any point before it ends, and we email you reminders while it runs. Through those routes deletion is never immediate: none of them erases an account on the spot.
• When the period ends, a job that runs once a night permanently deletes your account from our active systems: your sign-in with Amazon Cognito, your account in the website database, and your records in the app backend. An account goes at the first run after its 14 days are up, which can be most of a day later, and if a run fails for an account it is tried again the following night. If our authentication provider holds no sign-in that we can prove is yours, everything else is still deleted, that sign-in is left in place, and an alert goes to our support workflow tool.
• Deleting your IBOMEA account does not cancel an Apple or Google Play subscription. Cancel that in your Apple or Google account settings, or you will keep being charged.
• Copies may survive in backups for the 35 days described in section 15, and in a snapshot taken by hand until that snapshot is deleted.

What it removes. From the website account: your email address, display name and username, your two-factor setting and your marketing preference, the record of which product emails we have sent you, your acceptance records, your referral code, the referral records you are on either side of, and your prize draw entry and tickets. From Ideal Body Measurements: your profile and its photo, your measurements and progress history, the records of entries you deleted, your achievements and streak, your bug reports, the purchase events we recorded, and the marker and profile left by a login that was merged into this one. From AthleteOS: your names and settings, your profile picture, your subscription status, your plan, finished workouts and personal bests, your inbox, your status, your trainer profile, your connect codes, your installation records with their push tokens and notification log, and every connection you were part of, including invitations and requests that were declined or withdrawn, with its reports, private notes, reminder records, weekly gym sessions, booked sessions and the workouts you ran together, with their steps.

What it removes from other people. An AthleteOS connection belongs to two people, and deleting your account deletes it for both. If you were someone's client, that trainer, and any earlier trainer of yours, loses the record of the connection, the reports they sent you, the private notes they wrote about you, the sessions between you and any workout you ran together that we still hold. If you were someone's trainer, your clients and former clients lose the record of the connection, the reports you sent them, the sessions between you and any workout you ran together that we still hold; a plan you wrote for a client stays with the client. In the prize draw, a referral record is deleted whichever of its two accounts is deleted.

What deletion does not reach. Six kinds of record survive it, and each has to be removed by hand:

• the rows our mail queue keeps of emails already sent to you. A row holds the address it went to, your account identifier, or both, and for some emails also your referral code and invite link, or your support request reference;
• any rating you gave the help assistant, and the copy of it in our team workspace. Neither carries an account reference, so there is nothing in them for the deletion to match on: tell us roughly when you used the assistant and what you asked, and that is enough for us to search the stored text, delete what we find, and tell you if we find nothing;
• the reference record in section 5.7 - a request ID with a one-way hash of your address and a fingerprint of your message - which is keyed by that hash rather than by your account;
• the record our subscription provider holds against your account identifier, with your purchase and renewal history on it, which nothing tells them to delete;
• the two notices our support workflow tool and our team workspace receive about the deletion itself, one when you schedule it and one when it is carried out. Each holds the first letter of your email address followed by its domain, and the first eight characters of your account identifier;
• in AthleteOS, the notices in other people's inboxes that name you. A notice written to a trainer or a client of yours, or to someone you invited or asked to join, holds your name as it was when it was written, and one about a booked session holds its date and time as well. It belongs to that person's account, so it stays until they remove it, newer notices push it out past the 500 we keep for them, or their account is deleted.

Write to support@ibomea.com and we will do all six. None of them happens on its own; asking is what makes it happen. The same is true everywhere else in this Policy where we say we will do something by hand: erasing a support thread, a bug report or a measurement record, sending you a copy of your acceptance records, telling you what a provider holds about you, or naming our email provider. One message covers as many of them as you want.

Other things outlast a deletion without being on that list, because they run out by themselves or were never on our servers. Log lines written before the deletion, including an access line that holds your IP address or, where you opened a verification or reset link, your email address (section 5.2), last the 30 days in section 15. So does the entry in another person's AthleteOS notification log for a notice that named you; it holds references, for an invitation the internal identifier of your account among them, and no name. The copies our providers keep run on their own clock, as section 15 says. A prize draw ticket somebody earned by referring you keeps the internal identifier of your account (section 5.13). And deletion happens on our servers, not on your phone: it does not itself remove what an app has stored on a device. The same goes for a trainer's phone: a report the trainer has not sent you, the draft built from a workout the two of you ran together included, exists only there (section 5.14). Section 5.9 lists what each app keeps there, and section 5.4 says how the measurement entries Ideal Body Measurements keeps there go.

If you have won a prize, nothing is deleted until a person steps in. Czech accounting and tax law requires us to keep a record of a prize and of who we paid it to, and today that record blocks the whole deletion, not part of it. When your waiting period ends, nothing is removed: your sign-in goes on working, and your measurements and everything else under your account stay as they were. The nightly job tries again each night and is refused each time, and each refusal sends our support workflow tool an alert holding an internal reference to your account. Ideal Body Measurements, which still sees a deletion as scheduled, stays closed to you. If that is your situation, write to us: we will tell you exactly what is held under your name, and remove by hand everything the law does not require us to keep.

If you merged two logins (section 5.6), a deletion acts on the login it was asked from. A merge joins your app data. It does not join the two logins, which our authentication provider and the website account database go on holding separately, and a deletion removes one of them. Asked from the login that survived the merge, it removes everything listed above for that login, your measurements and history among them, with the marker left by the merged login and our record of the merge. It leaves in place the merged login's own sign-in and its account in the website database, with anything AthleteOS or a prize draw holds under that login. Asked from the login that was merged in, which the app can go on using after a merge, it removes that sign-in, that login's account in the website database with anything held under it, and our record of the merge, and it does not touch your measurements, which stay under the surviving login. To delete everything, schedule the deletion from both logins, or write to support@ibomea.com and name both.

17. Security

We use reasonable technical and organizational measures to protect personal data, including access controls, secure authentication, encryption in transit, encryption at rest for the database and its backups, password hashing, logging, and rate limiting. One-time codes and reset tokens are stored as hashes with an expiry, never as the value we sent you. No system is completely secure.

If you discover a security issue, report it to support@ibomea.com. Do not publicly disclose vulnerabilities before we have had a reasonable opportunity to investigate.

18. Your rights

Depending on where you live, you may have rights to access your personal data; to correct inaccurate data; to delete it; to restrict or object to certain processing; to receive a copy of it (portability); to withdraw consent where processing is based on consent; to opt out of direct marketing, at any time and without giving a reason; and to complain to a supervisory authority.

Some of those you can exercise without us: you can delete measurement entries (section 9.3) and your whole account (section 16), turn off product emails (section 5.11), change your advertising answer in the app where Google's form is offered (section 5.10), and, in AthleteOS, choose Invisible (section 5.14). For anything else, email support@ibomea.com. We may need to verify your identity. There is no self-service download of your data: a person assembles the answer by hand, which is why an access or portability request takes the time section 19 describes rather than arriving instantly.

19. Privacy requests

When you contact us about privacy, include enough information to identify your account, such as your account email.

If the GDPR or UK GDPR applies to you, we answer within one month. Where a request is complex, or where you have made several, we may extend that by up to two further months. If we do, we will tell you within the first month, and tell you why.

If a US state privacy law applies to you, we answer within 45 days. We may extend that once, by a further 45 days, where reasonably necessary. If we do, we will tell you within the first 45 days, and tell you why.

Someone acting for you. If you are covered by a US state privacy law, you may appoint someone to make a request for you. Have them email support@ibomea.com with written permission signed by you, or a power of attorney. We will ask you to confirm directly that you gave that permission, and we will ask them to verify who they are, before we act on it. For an opt-out of sale or sharing we will not ask you to confirm separately.

Appeals. If we refuse your request and you are covered by a US state law that gives you an appeal, email us with the subject "Appeal" and tell us why you disagree. We will decide within 45 days, or within 60 days if you are in Texas, and write to you with the outcome and our reasons. If we refuse the appeal, we will tell you how to complain to your state Attorney General.

20. App stores and platforms

If you download an IBOMEA app or subscribe through the Apple App Store or Google Play, Apple or Google may process personal data under their own privacy policies. Subscription billing, refunds and cancellation are handled according to their rules, not ours: there is no cancellation control inside the app. Review Apple's and Google's privacy information and your device settings for platform-specific choices.

21. Changes to this Privacy Policy

This Policy is a notice explaining what we do with your personal data. It is not a contract, and accepting it is not what makes our processing lawful; section 8 gives the basis for each purpose, and for almost all of them that basis is not your consent. We do ask you to confirm that you have been given it to read when you create an account with an email address and a password, and we record which version you were shown and when (section 5.12). That confirmation is not consent to anything. For an account created with Apple or Google, a record is made only in the cases section 5.12 describes, and on the website none is made.

A version of this Policy takes effect on the day we publish it at https://ibomea.com/privacy, and stays in effect until we publish the next one. If we make a material change we will tell you before it takes effect, by email, in-app notice or website notice. The version at the top shows which text you are reading and which it replaces. Where a change concerns processing that relies on your consent, we will ask you again rather than treat your silence as an answer.

22. Contact us

IBOMEA s.r.o.
Hasova 3091/2, Modřany, 143 00 Praha, Czech Republic
Email: support@ibomea.com
Website: https://ibomea.com
Contact form: https://ibomea.com/contact

Language. We publish this Policy in English only, although the website and both apps are offered in twenty-one languages. If you would like it in another language, write to us and we will send you a translation. Where the law of the country you live in entitles you to this information in your own language, that right applies and nothing here takes it away.

Accessibility. This Policy is published as ordinary web text, so screen readers and browser zoom work on it. If you have a disability and need it in another format, whether large print, plain text or read aloud, write to us and we will send it to you at no cost.

Regional Addendum

This addendum applies where required by local law. If it conflicts with the main Policy for users protected by that law, this addendum controls for those users.

A. European Economic Area, United Kingdom, and Switzerland

Nothing in this Policy limits your mandatory rights under GDPR, UK GDPR, or Swiss data protection law. You may have the right to access, rectify, erase, restrict, object to processing, and data portability, and to lodge a complaint with a supervisory authority. You may complain to the authority in the EU or EEA country where you live, where you work, or where you think the problem happened; you do not have to come to ours. In the Czech Republic that is the Office for Personal Data Protection (ÚOOÚ), Pplk. Sochora 27, 170 00 Praha 7, uoou.gov.cz. In the United Kingdom it is the Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF, ico.org.uk. In Switzerland it is the Federal Data Protection and Information Commissioner, Feldeggweg 1, 3003 Bern, edoeb.admin.ch.

Three things in the main Policy matter most here, and they sit there rather than being repeated: section 9.1, on the Article 9(2) condition we do not have; section 8.1, on the advertisement request we have no basis for at all; and section 8.2, on whether we may email you.

B. United States: what we sell and share, and the opt-in we do not ask for

We sell and share personal information, as those words are defined in California and in several other states, and we would rather say so than leave you to work it out. The app discloses to Google your IP address, information about your device and the app, your interactions with an advertisement, and on Android your advertising identifier. Section 12 identifies Google as an independent controller and not as our service provider, and Google pays us for the advertising those disclosures support. That payment is consideration, so the disclosure is a sale as well as a share for cross-context behavioural advertising.

This applies to you whatever you pay us. Section 8.1 describes the request the app makes at launch, before it has checked which tier your account is on. A Premium subscriber is never shown an advertisement, which is what the subscription buys and it holds, but that request still goes, so a paying subscriber's IP address, and on Android their advertising identifier, is disclosed to Google on the same footing as anyone else's. We are not going to describe the paid tier as switching that off while it does not.

In the twelve months before this version was published, the only category we sold or shared was identifiers - an advertising identifier on Android, an IP address on both platforms, and the advertisement interaction data that goes with them - and the only recipient was Google. We have never sold or shared your measurements, the figures we calculate from them, your gender or your date of birth, and we never will. You must be at least 18 to hold an account, so we do not knowingly sell or share the personal information of anyone under 18, which is stricter than the 16-year threshold in California Civil Code § 1798.120(c).

Stopping it. Two controls act on the disclosure without waiting for us, and they reach different distances. Where Google's framework requires that a way to change your answer be offered, the app carries Settings → Ad privacy choices, which reopens Google's form; whatever you choose applies to the next advertisement. It changes what an advertisement may be based on, and it does not hold back the launch-time request, because that goes before the form has been consulted. On Android, deleting your advertising ID in your device settings goes further: there is then no identifier to disclose, in that request or any other. Resetting it rather than deleting it changes the value and nothing else. Neither control takes your IP address out of a request that is made, and paying us is not one of the two.

Beyond those, write to support@ibomea.com with "Do Not Sell or Share My Personal Information" as the subject, and we will answer within the time section 19 gives. We would rather say this plainly than imply a switch we do not have: today the disclosure is governed by Google's consent framework on your device and by your device's own advertising settings, and those are the two places it actually stops.

Sensitive data, and the opt-in the app does not ask for. If you live in Virginia, Colorado, Connecticut, Texas, Montana or Oregon, your body measurements and the figures we calculate from them are sensitive data, and where those laws apply to us they require your opt-in consent before we may process them. The app does not ask for it: it runs the calculation as soon as you have filled the form in. So we do not have it, in the same way and for the same reason section 9.1 gives for Article 9 of the GDPR, and we are not going to describe the box you tick at sign-up as something it is not. If you live in Oregon, the gender you type into the optional “other” field is sensitive data under your law as well. Putting this right means the app asking you before your first calculation, which is a change to the app and not to this page.

Nevada. If you are a Nevada resident you may tell us not to sell your covered information. Our designated request address is support@ibomea.com. We answer within 60 days, and may take a further 30 days where reasonably necessary, in which case we will tell you.

Opt-out preference signals. ibomea.com does not read an opt-out preference signal such as Global Privacy Control today, and we will not tell you it does. The website itself sells and shares nothing, because the advertising is in the app, but we do not treat a signal as irrelevant merely because of that. If you send one and want it acted on, email us as above so that there is a record of it, and we will treat it as a request under this section.

Depending on your state, you may have rights to know, access, delete, correct and appeal. Contact support@ibomea.com to exercise them. Section 19 gives our deadlines and how to appeal if we refuse.

C. California

California residents have rights under the CPRA to know what categories of personal information we collect and use, to request deletion or correction, to limit the use of sensitive personal information, and to opt out of sale or sharing. Addendum B states what we sell and share, to whom, and how to stop it; it applies to you and is not repeated here.

We treat your body measurements, and every figure we calculate from them, as sensitive personal information. Section 9 is the whole account of what we do with them, including the one inference we draw - the waist milestone, worked out on your device and saved to your account. We do not disclose them to anyone to infer anything about you, and we never use them for advertising. If you want us to limit our use of sensitive personal information, or to remove that achievement from your account, write to support@ibomea.com.

D. Brazil, Canada, Australia, and other regions

Nothing in this Policy limits mandatory rights under LGPD, PIPEDA, Australian Consumer Law, or similar local privacy and consumer laws. Contact support@ibomea.com for requests under those laws. If mandatory local law gives you rights we have not described above, we will honor them where required.

E. Washington and Nevada consumer health data

If you live in Washington, or used the app while you were in Washington, your body measurements and every figure we calculate from them are consumer health data under the My Health My Data Act. If you live in Nevada, the equivalent provisions of NRS 603A apply.

Section 5.4 lists what we collect, and section 9 says why, where it comes from and everything we do with it; section 9.2 lists the three uses beyond producing your figures and keeping your history. It comes from one source, which is you, typing it into the form. We do not share it with anyone for any purpose, so there is no category of third party to list here. We do not sell it and we will not; that would require your signed authorization, and we have never asked for one and do not intend to.

You may ask us to confirm whether we hold consumer health data about you and who has received it, to stop collecting and sharing it, and to delete it. Write to support@ibomea.com. We answer within the deadline in section 19, we delete it from our active systems, and section 15 says what happens to the backups holding it.