Privacy Policy

Version 2.16.0

Privacy Policy — version 2.16.0 1. Who we are and what this app is Astras is an educational healthy-lifestyle app (wellness); Karina AI is the AI assistant inside it. The app runs on iOS, on Android and in a browser at https://astras.club; this Policy covers all of them equally. The app is not a medical device, it does not make diagnoses and it does not prescribe treatment. We explain what a marker means and what such values usually indicate — informationally, as common knowledge. We do not tell you the reason for YOUR deviation and we do not prescribe next steps: the conclusion in your case is your doctor’s. This is not a medical app. Here is what we do with your lab results and what we do not do: • We DISPLAY what is printed on your report and keep it in digital form. The marker name (translated into the language of the app), the value, the unit and the collection date are transferred from the report. If the report carries no collection date, the history shows the date the file was uploaded. • We take the reference range from your report — the one your laboratory stated. We do not substitute a range of our own and we do not recalculate your results against our own tables. If the report says “13–150”, you will see “13–150”. • The “in range / out of range” label comes from comparing your value with the range printed on your own report. It is not an assessment of your health but the result of comparing two numbers from the same sheet. If the report carries no range, the marker is labeled “not evaluated”, and we do not turn that into “in range”. For markers you entered by hand, the comparison uses the limits you entered yourself. • To that we add a description of what such values USUALLY mean: “most often this has to do with…”. This is an account of common knowledge, not a conclusion about you personally and not a diagnosis. • Checking and deciding are for you and your doctor. The report is read by recognition software, and it can get a number, a name or a range wrong, so check the transferred data against the original. We keep the original of your file, and you can open it at any time. Data controller (controller within the meaning of GDPR Art. 4(7)): KARINA NA MORE LLC (Karyna Trygubchak, sole member), address: 254 CHAPMAN RD STE 208-24515, NEWARK DE 19702, USA, Delaware File Number: 10313175. Data protection contact: info@karinamore.com. The data protection officer (DPO, GDPR Art. 37) and the controller’s representative in the EU (Art. 27) is Vitalii Tsepilov, tsepvital@gmail.com. You can contact him directly about anything to do with how your data is processed and about any of your rights under section 6; the controller also still answers the same questions at info@karinamore.com. A request sent to either address counts as filed on time. 2. What data we process • Profile: name, email, sex, age, height, weight, goal. • How you sign in: with a one-time code sent to your email, or with Apple, Google or Facebook. For those three we keep which service you used and the identifier of your account in that service, so that your next sign-in opens the same account (section 4); for Apple also a token with which, when you delete the account, we ask Apple to revoke the app’s sign-in. • Health data (special category, GDPR Art. 9), processed only with your separate consent (section 3): uploaded lab reports and the markers recognized from them, cycle logs with pregnancy (when you turn pregnancy mode on: the first day of your last period that you entered; when you mark that you gave birth or turn the mode off: the date the pregnancy ended, whether it was a birth, and the first day of the last period of that pregnancy) and the day marks (symptoms among them), training calendar marks — the days you yourself marked as strength training, cardio, stretching or a sugar-free day — plus daily activity totals from Apple Health / Health Connect — steps and active energy burned, per day (details in section 4). • Your food, water and weight diary: what you log yourself — meals with their names, calories, protein, fat and carbohydrates, water, weigh-ins. It is kept in your account on our server so that a second device and the web version show the same diary. What you eat and what you weigh can say something about your health, so we say plainly how this diary is handled: it works without the separate consent to the processing of health data, under the general consent to these documents (section 3); it is not used for advertising or analytics; apart from us it reaches only the AI providers named in section 4 — together with your questions to Karina AI; and it is not erased by “Turn off and delete the data” but goes when the account goes. • Personal messages — to Karina and to the Club authors you can write to in the app: a private conversation with a person, not with the AI assistant: the text of your messages and the photos, videos and files you attach to them. They are kept on our server rather than on your phone alone — otherwise they would disappear when you reinstall the app and would not open on a second device. A conversation with Karina is read by you and by Karina (and by a manager she appoints); a conversation with an author is read by you, by that author, and by the owner and the managers, who can see and answer every conversation with authors (section 8). Your chat with Karina AI is a different thing and is not covered by the line above: it is a conversation with a model, we do not keep it on our server at all, it stays on your phone, and how it works is described in the AI Use Notice. Where the two are mentioned below, we call them “personal messages” and “chat with Karina AI” and never mix them up. • Files you attach to course assignments (progress photos, for example). They sit on our server under your account together with the file name. • Comments in the Club. What you write under a publication is seen by the other people who read it, together with the name and the picture from your profile. Along with each comment, the app of every reader also receives a technical identifier of its author’s account; it is not shown on screen. For an account opened by email this identifier is a one-way hash of that email address: the address itself is not passed on, but someone who already knows it could check whether a comment is yours. If you report a comment, we keep the report together with a copy of that comment’s text: the owner and the managers read it to decide what to do with it. If you block a person, their comments disappear for you under every publication, and the list of people you blocked is kept in your account. Reports and blocks are kept for as long as the accounts they concern exist; the app does not yet have a button to lift a block. When the account is deleted, the reports and blocks you made, and those made about you, are erased, and the text and the name are wiped from your comments; an empty line stays in their place so that other people’s replies keep their thread. • Your voice, if you dictate instead of typing. We do not record it, do not store it and in fact never receive it: your operating system turns the sound into text, and what reaches us is the finished text. Where exactly that happens depends on your phone: if it can recognize speech on its own, the sound goes nowhere; if it cannot, the sound is sent to Apple’s or Google’s cloud. The app states which of the two cases is yours right under the microphone button. Details are in section 4. • Technical data: language, theme, an anonymous device identifier, the app build. For the phone that counts your steps we also keep its model (“iPhone 15 Pro”, for example) and a one-way fingerprint of that phone — a hash made from your account and the identifier the system gives the phone; the identifier itself never leaves the phone. The fingerprint has one job: after the app is reinstalled the server recognizes the same phone and keeps it as your main phone for activity. Both go when the account goes. • Daily summary: for each day you open the evening summary we keep the date, the badge you received and its material (series of days or a personal step record), so that your badges stay with your account. To choose a badge that fits, the app sends your profile gender and, if you consented to health data processing, a rough rating of the day; we do not store them. We also keep a mark that the summary was opened today, so that the 21:30 notification is not sent needlessly; that mark is erased after 3 days. • Purchases and subscriptions: which package you paid for, where (App Store, Google Play, our website) and when, the amount and currency as the store itself named them, the period you paid for, renewals and refunds. For a payment on our website we also keep the country (and, where tax rules need it, the region) — including the country worked out from the address of your connection; the address itself is not stored in this record. We hold no card details and never do: in the app the payment is run by the store, on our website by Stripe or PayPal. This record lives on our server because it is the server that checks the receipt is genuine, not the app — the app is never the one that decides whether something was paid for. • Where you came to us from. If you opened the site or the app through an ad link, that link carries a tag: the source (facebook, for example), the campaign, the ad set and the specific ad. We keep TWO such tags — the first one, which brought you to us in the first place, and the last one, after which you made the purchase — and we link them to your account and your purchase. On their own these are names and numbers of ads, not information about you; but next to your account they become part of your profile, so we name them plainly. These tags do not go anywhere outside — see section 4.2. • How often you use the app: two counters per day — how many times you opened it and how many minutes you spent in it, kept per day and per device under your account. Nothing else goes into them: not which screens you opened, not what you tapped, not the time of day you came in, not what you wrote or read. We need them to see whether the app is useful to people at all; the owner sees only totals across everyone, never one person’s figures. • How much AI resource your account has spent: one number per day (internal tokens, the unit your paid allowance is counted in) and the number of model calls. This record holds no questions, no answers, no marker values and no file names. We need it to enforce that allowance and to understand our costs; the owner sees only averages across everyone from it, never one person’s spending. • IP address and connection data. We do not keep the IP address itself in our own database, with one exception: when you start a payment on our website (even if it does not go through) and ad measurement is allowed, the server keeps the IP address, browser data and page address of that payment for 30 days (section 4.1). To notice mass attacks on sign-in, each sign-in code we send also leaves a salted hash of the IP address and the country for 2 hours, not linked to your email or account; our security alert uses them only as totals. Our hosting provider Cloudflare processes IP addresses and connection data every time the app contacts the server — this is necessary to deliver the response and to fend off attacks. An IP address counts as personal data under the law, so we say so plainly. • Problem reports. If you tap “Report a problem” in Settings, we receive the text you write (up to 2,000 characters), your account identifier, the time, and technical details of your device: platform, app version, operating system and its version, phone model and the app language. We do not attach your messages to Karina and to authors, your chats with Karina AI, lab results, health profile, screenshots or your email address. Whatever you type into the text yourself is sent as written, so please do not include health details that are not needed to describe the problem. If you tap “Report” next to an error message, the field starts with the error code, the time, the app version and the platform; you can edit or delete that line before sending. We do NOT collect: location, contacts, calendar. The app does contain two third-party kits (SDKs) that report to Google and Meta: Google’s Firebase Analytics and Meta’s SDK. Meta’s SDK does not start without the ad measurement purpose — and in the Astras app on iPhone and iPad also not before you tap “Allow” in Apple’s tracking prompt. Google’s Firebase works when app analytics or ad measurement is on. These purposes are on only after you agree on the consent screen — in every country (see section 4.1) — and can be switched off in Settings. With ad measurement on, the kits read your device advertising identifier and report the app install and the purchase to the platforms. In the Astras iPhone app, until you tap “Allow” in Apple’s tracking prompt, nothing that links your data to you for advertising — no e-mail hash, no account ID, no advertising identifier — is shared with ad platforms (Meta, Google), and no ad events are sent. App analytics is a separate switch in Settings. The Astras app on iPad works the same way. The details are in section 4.1. Apart from those, there is third-party code in the app of two kinds, neither of which has anything to do with advertising: Google’s notification delivery service (FCM), which carries the delivery address and the text of the notification (what that text can be is described in section 4), and crash reporting (Sentry) — what exactly is in a report is described in section 4. Playlists in the Meditations section. Only YouTube plays inside Astras — in YouTube’s official embedded player: when you open such a playlist, YouTube receives your IP address and device data and may use its own cookies under its own privacy policy; nothing from your Astras account is passed to it. Apple Music and Spotify playlists do not play inside the app: tapping one opens the Apple Music or Spotify app (or its website), where that service’s own policy applies. If you never open a playlist, none of this happens. Apple Health / Health Connect data (steps, activity). The app reads it on your phone with your permission and, with your consent to health data processing, stores DAILY TOTALS in your account on our server: steps and active energy burned, per day (up to 90 days). Why: so that the web version and a second phone show the same numbers as the phone that counted them — otherwise one account would show different steps on different devices. These numbers are yours: they are not used for advertising or analytics, are not uploaded to iCloud (in the Astras app on iPhone and iPad the app storage that holds them is excluded from the iCloud backup), and are erased by the “Turn off and delete the data” button in Settings and together with the account. Other Astras users see one thing out of them — your step total per day and when it was last updated, in the step leaderboard described below (the table opens for today and the two previous days); your active energy and older days are shown to no one. With renewed explicit consent to Privacy Policy and AI Use Notice version 2.0 or later, daily totals may also go to the AI processors described below (Microsoft Azure and fallback Google/Anthropic) to personalize educational nutrition and activity explanations. Old consent does not authorize this new use. Withdrawing health consent stops this AI transfer. Nothing else from Health leaves the phone: no separate workouts, no heart rate, no sleep, no route. The training calendar is different: you set its marks by hand, and they are not read from Apple Health / Health Connect. They are stored in your profile on our server so that a second phone and the web version show the same calendar; only you see them, the app makes no forecasts from them, and they are erased by “Turn off and delete the data” and together with your account. Separately — the step leaderboard. After you connect Health you take part in the step leaderboard: other Astras users see your name, picture, daily steps and when they were last updated. You can leave at any time. Taking part starts by itself, without a button: once you are signed in with a name in your profile, have given your consent to health data processing and connected Health (even before any steps today) — the text of the consent checkbox says so too. Along with the number the others see WHEN it was last updated (“updated 5 minutes ago”, “yesterday at 9:40 PM”) — otherwise the table would present stale numbers as current. Steps may also be read when the app is in the background or closed. We request periodic background checks at an interval of about an hour; the system decides when to run them and may delay checks. Additional checks can occur when health data changes, a silent push arrives or you open the app; background reads cover today's and the previous two days' steps only, nothing else. On iPhone, if Health can't be read at that moment (for example, while the phone is locked) and you have allowed Motion & Fitness, the app reads only your iPhone's own step count for the same days instead (it does not include steps from a watch); such a number can only raise the day's total in the leaderboard and never lowers a total already received from Health, and once Health can be read again its number is used. You can turn Motion & Fitness off at any time in iPhone Settings (the Motion & Fitness row in the app's Settings opens it). Withdraw your consent to health data processing, and the server stops accepting new step totals from your devices, the phone stops sending them and stops background reading, and it sends the server a request to take you out of the leaderboard together with its days. If that request does not get through (no network, for example), the days already shown stay visible until they drop out of the table — it covers only today and the two previous days — and no new ones are added. The totals already stored in your account stay, like the rest of your health data, until you delete them with the “Turn off and delete the data” button or together with the account. You can leave the overall “Top” table with the “Leave the overall ranking” button in the Activity section and come back with the same button: while you are out of “Top”, nobody sees you there, and in “Friends” your steps are seen only by the people you yourself keep in your “Friends”; your participation and days of steps stay. To leave the leaderboard completely, turn off health data processing in Settings: your participation and the days of steps kept for the leaderboard are deleted from the server, nothing is shown to others, and the app does not put you back in on its own. Top and Friends. The leaderboard has two views: “Top” — everyone taking part, except those who left it — and “Friends” — only the people you added and you. We do not read your phone’s contacts: Friends are only the people you added in Astras. You can add someone in two ways. With the star next to their row in “Top”: this works one way — without their confirmation and without notifying them, and we do not show anyone who added them; for this the row carries a label that is issued anew with every table and is valid for a day — by the label nobody can tell which account it is or link rows together. With an invitation: every account has a personal invite code — eight letters and digits, random, not derived from your email or account number; only you see it, in the Activity section, and you share it yourself with the “Invite” button (it sends the code and the link astras.club/f/<code> through the share window of your phone) or in any other way. An invitation is accepted only when the invited person confirms it in the app (“Accept the invitation”, or “Add” after entering the code by hand) — then they land in your Friends, and you in theirs (if your list is already full, only you get added to theirs); by sharing the code you agree to that, so give it only to people you want to compete with. If someone opens your link before signing in, the code waits on their device for up to three days, and after they sign in Astras asks them whether to accept. If you install Astras from such a link on Android, Google Play passes the invitation code to the app; on iPhone the link page copies the code, and the app reads the clipboard only when you tap “Paste”. In Friends a person sees about you exactly what “Top” shows (name, picture, daily steps and when they were last updated), and only while you take part in the competition; while you do not take part — or after you leave — your steps are not shown in anyone’s Friends: people who have you there see only the name and picture of your public profile card with the note “not in the competition right now”, and if you come back you are visible again to those who added you earlier. If you block someone in the comments, that person no longer sees you in their Friends and cannot add you; in “Top” they still see your row, but without the star. Your own Friends list (up to 100 people) is kept on our server in your account, and only you see it. The code and the lists are kept until you delete the account: leaving the competition and “Turn off and delete the data” do not delete them — they are a list of people, not health data. The code and the lists are part of how the service works (performance of the contract and our legitimate interest in running the competition); you can object at any time — remove people from Friends, leave the competition or write to info@karinamore.com. Showing your steps still rests on your consent to health data processing. 3. Why we process it (legal bases) • Health data — lab reports and markers, the cycle log with pregnancy and day marks, training calendar marks, daily activity totals from Health, and, when they go to the AI, the pregnancy, cycle day and allergies from your profile — only on the basis of your separate explicit consent (Art. 9(2)(a) + Art. 6(1)(a)). Without it, lab report analysis and the related health sections (“Labs”, “Cycle”, “Training calendar”) are unavailable. That same consent covers the transfer of these data to the AI providers, including transfers outside the EEA — who exactly receives what, and which of them processes it in Europe and which outside, is set out in section 4, and the same is named in the text of the checkbox itself so that you are not consenting blindly (Art. 49(1)(a)). • What goes to the AI without that separate consent — and we say so plainly, because it can also say something about your health. With every question to Karina AI, the rest of your profile (name, sex, age, height, weight, goal, the diet you mentioned and the app’s targets) and your food, water and weight diary (section 4) go to the AI providers; a food photo or a written line you ask the app to count goes to Google. This rests on a separate permission you give in the app: before the first use of the chat, lab report recognition, marker explanations or food recognition, Astras shows a permission screen that names what is sent and to whom, and nothing goes to an AI provider until you tap “Allow” (Art. 6(1)(a) and, insofar as this information reveals something about your health, Art. 9(2)(a)). The decision is recorded in the consent journal, like your acceptance of these documents. You can withdraw it at any time in Settings → “Sending data to AI providers”: the chat, recognition and explanations then stop working until you allow it again. Withdrawing the health consent does not by itself stop this transfer, and withdrawing this permission does not delete the diary entries. The same applies to what you write about your health in the chat yourself: that text is processed to produce an answer under the same permission. • Running the account and the subscription — performance of a contract (Art. 6(1)(b)). • Security, protection against abuse and troubleshooting — legitimate interest (Art. 6(1)(f)). • Problem reports — performance of a contract (Art. 6(1)(b)): we need to know what is broken in the service you use in order to fix it. If you choose to describe health details in a report, you do so voluntarily and we use them only to handle that report. • Ad measurement (the events about app use, section 4.1) — your separate consent only (Art. 6(1)(a)), in every country; you can withdraw it at any time. It contains no health data. • App analytics (which screens are opened and where people give up, Google Firebase) — a SEPARATE consent of yours, asked and stored apart from the one above (Art. 6(1)(a)), in every country, with the same right to switch it off at any time. Allowing one of these two purposes and refusing the other is a normal, fully supported answer: the app works in full either way, and neither of them ever carries health data. • Keeping track of where buyers came from (the tags from section 2 and the owner’s sales report) — our legitimate interest in measuring our own advertising (Art. 6(1)(f)): without knowing which ads pay for themselves we spend money blind. This record is passed to no one and touches no health data, and you may object to it at any time (Art. 21) by writing to info@karinamore.com. One caveat: when the tag reaches us from the app (the app store reports it at install time), it arrives only while ad measurement is on — that is, only after your consent. • Translating Club publications and section names (section 4) — our legitimate interest (Art. 6(1)(f)) in letting readers of any language understand the Club; authors may object at any time (Art. 21) by writing to info@karinamore.com, and a club author who refused the AI providers is not translated. • The two usage counters (opens and minutes per day) — legitimate interest (Art. 6(1)(f)): we need to know whether the app is used at all and whether a change made it better. There is no advertising, no profiling and no third-party analytics SDK behind them, and health data is not involved. You may object to this processing at any time (Art. 21) by writing to info@karinamore.com; the app keeps working in full without these counters. • The AI spending counter per account — performance of a contract (Art. 6(1)(b)): you bought a plan with an allowance, and without counting the spend that allowance does not exist. Watching the average spend on top of that is our legitimate interest in understanding our costs (Art. 6(1)(f)); you may object to it at any time (Art. 21) by writing to info@karinamore.com. • The email typed on the checkout page before a payment (section 4) — keeping it, to match a later payment and to know about unfinished checkouts, is our legitimate interest (Art. 6(1)(f)); you may object at any time (Art. 21) by writing to info@karinamore.com, and we then erase it. Emails about the app — only while the “send me tips, news and offers” box is ticked, as your consent (Art. 6(1)(a)), which you can withdraw at any time by unticking it or with the unsubscribe link. Separately about sex and age. The sex and age you entered in your profile are used when a lab report is processed. Reports often print several ranges — separately for men and women, for different ages, for pregnancy; the app picks the range row that matches your profile data and builds the marker explanation from it. The app does not check whose name an uploaded report was issued in and does not compare it with your profile. So if your profile holds someone else’s sex and age, or you uploaded another person’s report, the range from your profile will be applied — and the explanation will be wrong. Please keep your profile filled in with your own data, and upload only your own reports. 4. Who we pass data to (processors) and where • Microsoft (the Azure platform) — the primary provider of chat answers. What you write to Karina AI goes to it, and along with the question we pass a set of facts so that the answer takes your data into account. Always: your profile — name, sex, age, height, weight, goal, the diet you mentioned and the app’s targets; your weight journal — the latest weigh-ins, the change and the trend; and your food and water diary for the last 7 days — calories, protein, fat, carbohydrates and water per day, plus the names and calories of the meals logged today. Only with your consent to the processing of health data: the markers already saved in the app and their history, your cycle (cycle day, delay) and pregnancy (while pregnancy mode is on: the first day of your last period, the gestational age, the estimated due date and the gestational age on the collection dates of your lab results; after you marked that you gave birth: the date you gave birth and the number of days since), the allergies you reported, and daily activity totals. The answer is generated by an AI model from a third-party developer; it is hosted, run and operated by Microsoft itself on Microsoft’s servers — the model’s developer does not receive your data. Alongside it, on the same platform, in the European data zone, we keep a backup model: your question goes to it when the primary model is busy or does not answer. It also comes from a third-party developer and is hosted and run by the same Microsoft — the model’s developer does not receive your data. We may replace the specific model inside this platform with another one hosted there: the recipient, the processing region and the rules of this section stay the same. Where this request is processed: our Azure resource is created in Sweden (Sweden Central). Once you have accepted this version of the Policy and given your consent to the processing of health data, the primary model may answer you on Microsoft’s “Global Standard” tier: your question may be processed in any country where Microsoft runs the model, including the USA, while everything that is stored — including the abuse-monitoring samples described below — stays in the European Union. Until then, your questions are processed on the “Data Zone Standard” tier and do not leave the European data zone. The backup model always works in the European data zone. Reports are not sent to it. Privacy policy: https://www.microsoft.com/privacy/privacystatement. • Google (its AI services) — recognition and everything to do with images: it reads the lab report you upload, recognizes food from a photo, counts calories from your voice or from a written line and translates marker names. It is also the first backup for chat: when Microsoft does not answer, that same question, with the same set of facts, goes to Google instead. It also translates the texts of Club publications and the names of Club sections into each reader’s language: for this translation Google receives only those texts as written by the publication’s author or by us; we do not add comments or data about readers to them. We use the paid tier: the provider does not train its models on your data. Privacy policy: https://policies.google.com/privacy. • Anthropic — the last backup for chat answers, used when both providers above are unavailable; in that case your chat question is passed to it with the same set of facts. It does not receive lab reports. Privacy policy: https://www.anthropic.com/legal/privacy. • Supabase — the app’s database. This is where your profile, the markers from your reports, the app’s state, the log of your consents, your paid access and the list of your conversations physically sit. The database is hosted in the European Union, in Germany (Frankfurt): this data is stored inside the European Economic Area. The provider itself is a US company, so we treat access by its staff for maintenance as a transfer outside the EEA and say so below. Privacy policy: https://supabase.com/privacy. • Cloudflare — servers and file storage: this is where the originals of your reports, the photos and files from your personal messages, the messages themselves, the files you attach to course assignments and Karina’s materials physically sit. A separate service, Cloudflare Stream, stores and delivers Karina’s videos — course lessons and clips in the club — and the videos sent in personal messages, by you or to you; the videos from your messages are deleted together with your account. When you play a video, the phone contacts Stream directly, and Stream sees the address of your connection. Karina’s own videos hold none of your personal data. Privacy policy: https://www.cloudflare.com/privacypolicy/. • Shopify — the shop on karinamore.com. If you bought there, we take from your order the email, the item, the amount, the date and the ad tag of the order: the email is how your access in the app is opened, and the tag goes into our internal sales record (section 4.2). Shopify receives no health data. Privacy policy: https://www.shopify.com/legal/privacy. • Stripe and PayPal — payment on the website astras.club. If you subscribe on the site, the payment provider receives the email you enter (or the email of your account), the name on the card or in your wallet or PayPal account, the country of your connection and the payment details themselves — the card number never reaches us. From the provider we keep the subscription identifier, the plan, the amount, the date, the country of the card or payment account (needed for tax records) and the name on the card — if you had no account yet, it becomes the name of the new one, and when you first set up your profile the app offers the first word of it as your name; you can change it there. If you paid before you had an account, the account is opened by that email once the payment is confirmed, and the download link is sent to it. The email you enter on the checkout page is saved as soon as you type it, even if you do not finish paying — together with the plan you looked at, the page language, the country of your connection and the state of the “send me tips, news and offers” box. We use it to match a later payment and, only if that box is ticked, to write to you about the app; untick the box or use the unsubscribe link in any such email, and we stop writing. This record has no fixed period: we keep it until you ask us to delete it (at info@karinamore.com) or delete an account registered to that same email, and then it is erased. An address different from your account’s email is not linked to the account — to have it erased, write to us; if you have no account with us, we then also delete the customer record Stripe created for you at checkout. They receive no health data. Privacy policies: Stripe — https://stripe.com/privacy; PayPal — https://www.paypal.com/us/legalhub/paypal/privacy-full. • Resend — email delivery. Through it we send the one-time sign-in code, the code that confirms an email address you add to your account and, after a purchase on the website astras.club or in our shop on karinamore.com, the confirmation email: the plan you paid for, the order number, the amount, how long the access lasts and the link to the app. It receives your address and the text of that email. It also delivers the problem reports you send from Settings (section 2) to our support mailbox info@karinamore.com: then it receives the text of the report, your account identifier and the device details, but not your email address. Resend receives no health data from us, except whatever you choose to type into a problem report yourself. Privacy policy: https://resend.com/legal/privacy-policy. • Apple, Google and Meta — sign-in, if you choose to sign in through one of them. The service confirms who you are and passes us the identifier of your account in it, your email (if you allow it to be shared) and the name you use there. We send that service nothing about what you do in the app and nothing about your health. Privacy policies: Apple — https://www.apple.com/legal/privacy/; Google — https://policies.google.com/privacy; Meta — https://www.facebook.com/privacy/policy. • Google (Firebase Analytics) and Meta (an SDK on your phone) — advertising, under the rules of section 4.1: only after you agree on the consent screen, in every country, with an off switch in Settings. Meta’s kit does not start without the ad measurement purpose — and in the Astras app on iPhone and iPad also not before you tap “Allow” in Apple’s tracking prompt. Google’s Firebase kit works when app analytics or ad measurement is on; it does not collect the identifier Apple gives the app’s developer (IDFV). With ad measurement on, the kits report the app install and the purchase to their platforms and pass your device advertising identifier — in the Astras app on iPhone and iPad only after “Allow”; until then Google’s kit receives every advertising signal as “denied”. They receive no health data: we send them no event about markers, lab reports, the cycle or nutrition, and opened screen names reach Google only under your separate consent to app analytics, and only in a cleaned form: substituted values — a marker name, a course or lesson number — are replaced with “:id”, so “/marker/ferritin” becomes “/marker/:id”. The detailed breakdown is in section 4.1. Privacy policies: Google — https://policies.google.com/privacy; Meta — https://www.facebook.com/privacy/policy. • Sentry — crash and error reports from the app. When the app crashes or catches an error, the error stack, the build version, the platform, the device model and the system version go there. Who you are does not: the report is cleaned inside the app before it is sent, and the account identifier, the email address, the IP address, URL parameters and records of network requests are removed from it. There are no markers, no lab reports, no text of your messages and no screenshots in the report — screenshots and interface snapshots are switched off in the configuration, not merely promised. Storage is in the provider’s European region (Germany). The legal basis is legitimate interest (Art. 6(1)(f)): without a crash report we learn that something is broken only when a person writes to tell us. Privacy policy: https://sentry.io/privacy/. • Expo — notifications and app updates. So that you can receive notifications, your phone obtains a delivery address (push token) from Expo’s servers; we keep that address on our side and send every notification through Expo, after which Apple (the APNs service) delivers it on iPhone and Google (the FCM service) on Android. That means Expo receives data about you, and we say so plainly: the delivery address, the text of the notification and the label of the screen to open. Privacy policy: https://expo.dev/privacy. For every notification but one, that text is a phrase taken from a closed catalog on our server, not composed at the moment of sending: the code that sends a notification passes the NAME of a phrase, and the title and body are picked up from that catalog. The catalog holds short phrases of the “Karina replied”, “Your analysis is ready”, “New comment” kind, and it grows as new features appear in the app — we deliberately do not copy the full list here, so that this document does not become untrue on the day a phrase is added. Neither your own text, nor your markers, nor a report analysis, nor a file name can get into such a notification. The one exception is a personal message from Karina. When she (or a manager answering for her, see section 8) replies to you in personal messages, the first lines of HER message — up to 140 characters — are shown in the notification, so that you can see what the reply is about without opening the app. These lines pass through Expo and through Apple’s or Google’s delivery service and appear on your lock screen; if Karina mentions your health in her reply, those words are among them. What you wrote yourself never goes into a notification, and a reply from a Club author carries only a phrase from the catalog. The preview is on by default; you can switch it off in Settings → Notifications → “Show message text in notifications”, and then this notification, too, carries only a phrase from the catalog. Reminders about water, meals and the cycle are a separate matter: those phrases are set inside the app, and your phone shows them itself, at the appointed hour, without our server and without Expo. The app also asks Expo whether an update is available; in doing so Expo sees the address of the connection and the build version. • Apple and Google — purchase verification. When you take out a subscription, the store issues a receipt to the app, and our server contacts the App Store (on iPhone) or Google Play (on Android) to make sure the receipt is genuine and the subscription is active. Only the receipt itself and the product identifier go there; none of your markers, personal messages or reports. We do not see and do not receive your card details at all — for purchases in the app, payment is run entirely by the store; for payments on our website, see Stripe and PayPal below. Privacy policies: Apple — https://www.apple.com/legal/privacy/; Google — https://policies.google.com/privacy. • Apple and Google — speech recognition, and not always. When you dictate, the app first asks your phone whether it can recognize speech on its own, without a network. If it can, the sound stays on the phone and is passed to no one, including us. If it cannot (an older system version, no language pack downloaded, recognition refused to work), the sound goes to the cloud of the system your phone runs on: on iPhone that is Apple’s service, on Android Google’s speech recognition service, in a browser the browser’s own recognizer. There it is processed under those companies’ rules rather than under our contract, and what exactly they do with it is determined by their own documents. Privacy policies: Apple — https://www.apple.com/legal/privacy/; Google — https://policies.google.com/privacy. So that you do not have to guess, the app states this right under the microphone button — for example, “Recognized by Apple’s service — the voice recording goes to them”. It is easy to say something about how you feel out loud: if you do not want that to go to Apple or Google, type the text by hand — then there will be no sound at all. Where the processing happens is not the same for everyone, so we name it provider by provider. Chat answers are produced by Microsoft; our Azure resource is created in Sweden (Sweden Central). Since version 2.2 of this Policy the primary model may run on the “Global Standard” tier for people who have accepted this version and given their consent to the processing of health data, so a chat question may be processed in any country where Microsoft runs the model, including the USA; stored data, including abuse-monitoring samples, stays in the European Union. Until then, your questions are processed on the “Data Zone Standard” tier and do not leave the European data zone; the backup model always stays there. Everything else takes place on servers in the USA and in other countries where the providers operate, that is, outside the EEA and the United Kingdom: the reading of reports and food photos by Google, file storage at Cloudflare, email delivery by Resend. The database holding your profile and markers is the exception: it is hosted in Frankfurt, that is, inside the EEA (see Supabase above). If neither Microsoft model answers and the question goes to a backup provider outside Azure — to Google or Anthropic — that question is processed outside the EEA. Crash reports at Sentry are stored in the European region (Germany), so we do not send them outside the EEA; the provider is a US company, it publishes a data processing agreement with the European Commission’s Standard Contractual Clauses, and we have no separately signed agreement with it. Transfers to Google, Cloudflare, Anthropic and Resend rely on the data processing agreement (DPA) of each of them and on the mechanisms it provides for: the European Commission’s Standard Contractual Clauses and/or the provider’s participation in the EU-US Data Privacy Framework. We checked this against the current terms of all four. About Supabase we will speak separately and honestly. We moved the database to it on 16 August 2026, and the most important part of that is in your favour: previously the database sat in no fixed country, and now it is in Germany. This provider publishes a data processing agreement, but we have not yet checked it against the original source, and we will not claim what we have not verified; once we have, this paragraph will change. With Microsoft it is the same, except that the agreement works differently: it is not signed separately. The data processing agreement (DPA) is part of the Azure subscription terms and applies from the moment the subscription is taken out, and with it the European Commission’s 2021 Standard Contractual Clauses for any transfer outside the EEA; where it conflicts with other subscription terms, the data processing agreement prevails. The region of our resource is set in our own configuration, and it is European; on the “Global Standard” tier Microsoft may process a chat question outside the EEA under these clauses and under the EU-US Data Privacy Framework, in which Microsoft participates. Separately, about abuse monitoring at Microsoft. So that nobody uses the model to do harm, Microsoft watches how it is being called. Normally that is done by software, and the content of the requests is kept nowhere. But if the system suspects a violation, a sample of questions and answers may be selected, stored in a separate data store and read by authorized Microsoft employees. For our deployment this happens inside the European Economic Area: the store and the reviewers are both there. We say this plainly, because a question about your health is not something you want to learn after the fact could have been read by a person. Turning this monitoring off requires separate approval from Microsoft; until we have it, this is how it works, and once we do, this paragraph will change. About Expo we will say separately and honestly: its data processing agreement is not published, we have requested it and there is no answer yet. We therefore do not claim that such an agreement has been concluded with it. Expo receives no markers and no reports, and of your messages it receives nothing but the preview of Karina’s reply described above — otherwise only the notification delivery address, a phrase set in advance and a screen label. We name the split of roles plainly, because it differs. Microsoft, Google, Cloudflare, Supabase, Anthropic, Resend and Sentry process data ON OUR INSTRUCTIONS — they are our processors and we answer for them. Apple and Google, in the part covering notification delivery, purchase verification, speech recognition and sign-in, and Meta in the part covering sign-in, act under THEIR OWN rules rather than under our contract: here we can only say honestly what goes to them, and not promise on their behalf what we do not control. We keep a list of providers stating what each one receives and on what basis data travels to it. You have the right to request a copy of that list and a copy of the transfer safeguards at info@karinamore.com (GDPR Art. 13(1)(f), Art. 46(2)). The list of providers may change. If we replace a provider or add a new one that receives health data, we will update this list and tell you before the transfer begins. If the provider that reads your reports changes, the app will ask your permission to send them again — you consented to a specific recipient, not to any AI whatsoever. We do not sell your data for money and do not pass it to data brokers. The only transfer to advertising systems is the events about your use of the app described in section 4.1, and only after your consent; for California residents we treat that transfer as both “sharing” and a “sale” under the CCPA/CPRA (not for money), and you can opt out with the switch in Settings, with “Your Privacy Choices” at the bottom of the landing pages of astras.club, or with the GPC signal. 4.1. Advertising: what goes to Meta and Google We advertise on Facebook, Instagram and Google. To tell which advertising brings people in and which only spends money, these events are reported to the platforms: app install, registration, starting and renewing a subscription, a course purchase and, once a trial period exists, its start (for money events — the amount and currency; events are sent as the corresponding features appear in the app). None of them touches your health. There are TWO consents here, not one, and they are asked and kept separately: ad measurement (the events named above, sent to Meta and Google) and app analytics (Google Firebase: which screens are opened and where people give up, so we can fix what is confusing). You may allow both, one of them, or neither — the choice screen shown at the end of the first sign-up has three equally prominent buttons — “Accept all”, “Accept only essential” and “Decline all” — plus “Choose what to allow” with a switch per purpose, and every switch starts off. To be exact about the middle one: “Accept only essential” turns on app analytics and nothing else — Meta and Google receive no advertising events after it. Nothing in the app depends on any of the three: everything works in full even after “Decline all”. The same two switches live in Settings and can be changed at any time in either direction. Refusing costs you nothing: no feature of the app depends on either answer. These two purposes stay off until you tap “Accept all” — or turn on the purpose you want under “Choose what to allow” — on the consent screen. The rule is the same in every country. One technical detail, so that the switches do not promise more than they do: if you allow ad measurement but not app analytics, Google’s kit stays running on your phone, because it is what ties your install to the ad you came from; its analytics storage is closed in that case, so no product reports about you are built. You can switch either purpose off at any time in Settings; once off or withdrawn, nothing is sent and the app keeps working in full. Apple’s system tracking question works as a lock on top of that. In the Astras iPhone app, until you tap “Allow” in Apple’s tracking prompt, nothing that links your data to you for advertising — no e-mail hash, no account ID, no advertising identifier — is shared with ad platforms (Meta, Google), and no ad events are sent. App analytics is a separate switch in Settings. The Astras app on iPad works the same way. Our server does not send such an event at all, Meta’s kit does not start, and Google’s kit receives every advertising signal as “denied”. App analytics works differently, and we describe it honestly: when it is on, Google’s Firebase kit reports which screens are opened (with the substituted values replaced by “:id”, see section 4), together with its own identifier of the app installation — the app instance ID; the identifier Apple gives the app’s developer (IDFV) is not collected — the phone model, the system, the app version and the country, and like any network request it sees the address of your connection. On the website’s payment page (not in the app), under the app-analytics consent, the steps of paying — viewing and choosing a plan, starting a checkout, adding payment details, a subscription activated, a payment failed — with the plan, the payment provider, the amount, the currency, the region and the error code may be passed to Google Analytics if its tag is on that page; no email, no account identifier, no free text. This does not depend on Apple’s tracking prompt: app analytics has its own switch in Settings and, like ad measurement, works only after you allow it. In the app there are two senders, and they differ (in the Astras iPhone app both of them only after “Allow” in Apple’s tracking prompt, as said above). OUR SERVER reports the install, the registration, the start of a free trial, the first payment (as the start of a subscription and as a purchase), renewals and one-off purchases (as purchases): the event carries your email and our internal account identifier (if you signed in) — ONLY as an irreversible hash (sha256), your IP address, the client string, the event name and its id, the app passport (platform, app identifier, app version and system version), and for money events the amount, the currency and the expected value of a customer, which we calculate from our own payment records (how many payments a subscription brings on average). A purchase made in a store test environment (TestFlight, Google Play licence testing) is never reported as real money: it goes to Meta only as a test event, or not at all. What goes here is fully determined by our code, and anything not written there never leaves. THE SDKs ON YOUR PHONE additionally report the app install and the purchase: they pass your device advertising identifier, the phone model, the system, the app version and the country — that composition is determined by Google and Meta, not by us, and is described in full in their own documents. On the website astras.club there is a third sender — your browser. The landing page carries the Meta pixel and Google’s tags (Google Analytics and Google Ads); the pages where a plan is chosen and paid for carry the Meta pixel and the same Google tag. There is no Apple tracking prompt on the website; the consent rule works instead, the same in every country: the Meta pixel is not loaded at all until you allow it — with “Allow” in the banner on the landing page or on the consent screen in the web app — and Google’s tag is not loaded either; the Global Privacy Control signal of your browser counts as a refusal. When they are on, they set their own cookies (_fbp, _fbc, _ga) and report page views and the steps towards a purchase — looking at the prices, starting a checkout, adding payment details, signing in on the landing page. Meta’s automatic advanced matching is switched on for our pixel: on a page where the pixel is on, it can read the contact details you type into that page’s forms — on the landing page the email in the sign-in window, on the payment page the email, the name on the card and the postal code (ZIP) — and sends them to Meta only as an irreversible hash (sha256), so that Meta can match the event to an account; the card number, expiry date and CVC are inside Stripe’s window, and the pixel cannot read them. The website also keeps in your browser the campaign marks and click tags of the link you came by (utm, fbclid, gclid, gbraid, wbraid, ttclid) — only after “Allow”; “No thanks” erases them together with the _fbp, _fbc, _ga and Google Ads cookies of our domain. Without your “Allow” none of this happens: the pixel is not there, it reads nothing and none of this is kept. When you subscribe on the website and ad measurement is allowed (by your account, or on the page if your account has not decided yet), our server also reports the purchase and its renewals: to Meta — the IP address and the browser string of the connection you paid from, the _fbp and _fbc cookies, the page address, the event name and its id, the amount and the currency, hashes of the country, region, city and postal code you gave the payment service, and, if the permission came from your account, a hash of your email, of our account identifier and of the name on the payment; to Google Analytics — the _ga client identifier, in the same case a hash of our account identifier, the purchase number, the event name, the amount and the currency; to Google Ads — likewise only with your permission for ad measurement, and only if you came from a Google ad and its click tag (gclid, gbraid or wbraid) was kept on the site: the click tag, the purchase number, the amount, the currency and, if the permission came from your account, a hash of your email. For this the server keeps, from the moment you start a payment on the website (even if it does not go through), next to that payment, the IP address and the browser string of the connection you paid from, the _fbp, _fbc and _ga cookies, the Google click tag, the visitor number and the page address — only if ad measurement was allowed when the payment was started, and for 30 days; the purchase and the renewals within that time are reported with them. After 30 days the record erases itself: renewals of an account that allowed ad measurement are then reported without these data, and those of a buyer who allowed ad measurement only on the payment page and has not decided in the account are not reported at all. Nothing about your health is among them. The landing page and the payment form, including the card fields in Stripe’s window, load their fonts from our own domain — not from Google Fonts. PROOF OF YOUR DECISION. So that we can show — to you, to a regulator or to a court — that you agreed before anything was sent, and that nothing was sent after you said no, our server keeps a journal of evidence. For every decision it records: when you decided and when it was recorded (to the millisecond), for which purpose (ad measurement, app analytics), yes or no, where you pressed (the consent screen, Settings, the banner on the landing page; the Global Privacy Control signal of your browser is recorded as a refusal), a fingerprint of the exact text you saw, the version of this Policy, the IP address and the country of that connection, the browser or app version you decided from, and your account identifier or, on the website before you sign in, a random visitor number stored in your browser, together with a hash of your email so that the record can be found if the account no longer exists. For every report our server sent to Meta, Google Analytics or Google Ads it records the event name and number, the time, the channel and which of your decisions it relied on; the pixel and tags in your browser and the kits in the app follow your decision on the device and are not reports of our server. Every record carries the fingerprint of the previous one, and every hour in which the journal grew, the fingerprint of its end is sealed by an independent timestamp service (DigiCert or FreeTSA, RFC 3161) — they receive only that 32-byte fingerprint and nothing about you. Changing or removing a record inside a sealed stretch breaks the chain and shows, even if we did it; a record removed when its retention period ends leaves its fingerprint in the chain. The seals are kept in our database, so whoever controls it could still delete the most recent records together with their seals — we do not do that, and every seal in a court file can be verified with the timestamp service's certificate, without us. Legal basis: our obligation to be able to demonstrate consent (GDPR Art. 7(1), Art. 6(1)(c)) and our legitimate interest in defending legal claims (Art. 6(1)(f)). How long: 4 years after the last record we rely on; your latest decision on each purpose is kept for as long as we rely on it. These records stay after you delete your account (GDPR Art. 17(3)(e)), your records are part of the export of your data in Settings, and you can ask us for a copy at any time (Art. 15). What these events do NOT and WILL NOT contain: anything about your health. No markers or lab reports, no cycle or pregnancy, no weight, food or activity, not even the fact that you uploaded a report or opened a health section. This is forbidden both by the platforms' own rules and by the law on special categories of data (GDPR Art. 9). Legal basis — your consent (Art. 6(1)(a)), in every country. Recipients: Meta Platforms Ireland Limited (Ireland) and Google Ireland Limited (Ireland). For collecting data with the Meta pixel on our website and passing it to Meta, we and Meta are joint controllers (GDPR Art. 26, under Meta’s Controller Addendum, https://www.facebook.com/legal/controller_addendum): we answer for the pixel being on only after your consent and for telling you about it, Meta answers for its own processing under its Privacy Policy (https://www.facebook.com/privacy/policy), and you can exercise your rights with us or with Meta. For what it does with the data afterwards, Meta acts as an independent controller under its own rules. With Google the roles differ by product: in Google Analytics (on the website, and Firebase Analytics in the app) Google processes the data on our behalf, as our processor under the Google Ads Data Processing Terms — sharing Analytics data with Google for its own products is switched off on our side; in Google Ads — what our website’s Google tag and our server send there, and the conversions imported from Analytics through the link between them — Google is an independent controller under its own rules. Transfers outside the EEA are covered by the EU Standard Contractual Clauses in both cases. You can switch advertising analytics off (and thereby withdraw consent, if you gave it) at any time in Settings (in the app and in the web app), and on the landing pages of astras.club with “Your Privacy Choices” at the bottom of the page; for US residents the same withdrawal means opting out of the “sale/sharing” of personal information under CPRA. We honour the Global Privacy Control browser signal: when it is on, advertising analytics in the web version is off even if the toggle is set to “yes”. What happens to this data when you delete your account. On our side we erase everything: profile, markers, lab reports, messages and the record of the advertising consent itself (see section 7). The one exception is the data of a website payment kept for ad measurement (above): it is not erased at deletion but erases itself 30 days after the payment was started, and no new events are sent with it. But the events that already went to Meta and Google sit with them, not with us — we cannot call them back. From the moment of deletion not a single new event about you is sent. If you want the platforms to erase what was already sent, write to info@karinamore.com: we will pass your request on to both (GDPR Art. 19) and tell you what they answer; you are equally entitled to demand erasure from them directly — Meta and Google Ads dispose of their own copies as independent controllers; in Google Analytics, which processes the data for us, it is deleted when the retention period we set there runs out — if you want it gone sooner, write to us before you delete the account, while we can still find your records there. As a reminder, this is what sits there: a hash of your email and of our account identifier, the IP address, the app passport (platform, app identifier, app and system versions), the event name and its id, for money events the amount and currency, for a purchase on the website also the _fbp, _fbc and _ga identifiers and the page address, and from the SDKs the device advertising identifier, phone model, system and country. And not one word about your health. 4.2. How we learn which ad worked — and why this stays with us Section 4.1 is about what goes OUTSIDE. This section is about what stays INSIDE and does not leave in a single line. To understand which advertising pays for itself we have to connect two things: the ad a person came through, and the money they later paid. We get the ad tag in two ways. If you bought on the site, it is already written into your order and we take it together with the order. If you installed the app through an ad link, the app store reports the tag at install time, and that works only while ad measurement is on (section 4.1). TWO tags are kept, not one: the first — the one you first reached us through — and the last — the one after which you made the purchase. These are often different ads, and the difference between them is exactly what shows which advertising brings people in and which one closes the sale. Who sees this: the owner only, and only as a report — how much money, how many purchases and how many subscriptions a source, a campaign, an ad set or a single ad brought over a chosen period. The report is computed across all buyers at once. What is not here: not one word about your health. The tag is not linked to markers, to lab reports, to the cycle or to nutrition — only to the fact of a purchase and its amount. 5. How long we keep it • Profile and health data — for as long as the account exists. • The record of purchases and renewals — as your record, for as long as the account exists; it is included in the data export you can download. When the account is deleted, this record is not erased but cut off from you (what is removed from it and what stays is listed in section 7) and kept for financial and tax records (GDPR Art. 17(3)(b)): purchases made through the App Store, Google Play and our Shopify store, and access opened by hand — for three years from the date of the purchase; payments made on the website through Stripe or PayPal — for ten years from the end of the year of the payment. After that the line is deleted. • Ad tags (section 4.2) — for as long as the account exists: they go when the account goes and are part of your data export. The exception is the copy of the two tags written into the record of a purchase: it stays with that record for the period named above. • The email typed on the checkout page without a payment (section 4) — until you ask us to delete it or delete the account registered to that email. • The proof of your consent decisions and of every report sent to Meta and Google (section 4.1) — 4 years after the last record we rely on; your latest decision on each purpose is kept for as long as we rely on it. It stays after the account is deleted (section 7). • The proof that you accepted the documents when paying on our website: the versions of the Terms of Use, this Policy and the Refund Policy, the time, whether the box was unticked before you paid, the language, the order number, a hash of the payment number, the payment method and the item, and whether you were signed in, next to a pseudonymous identifier. No email, name, IP address or document text. 4 years; it stays after the account is deleted, and by the time of the purchase it can be matched to the record of purchases. • The IP address, browser string, _fbp, _fbc and _ga cookies, Google click tag, visitor number and page address of a payment started on the website (even if it did not go through), kept for ad measurement (section 4.1) — 30 days from the start of the payment, and only if ad measurement was allowed when it was started. • Recognized markers on the device (cache) — 30 days. • Daily summary badges — until you delete them with your account or your health data. Marks that the summary was opened — 3 days. • Sign-in security: a salted hash of the IP address and the country — 2 hours. • Technical records about report processing — 90 days. They normally hold no marker values: the record takes the file type and size, error codes and processing steps, and the file name does not go into this record — only the extension is left of it (elsewhere the file name is kept, see below). One exception: if the server finished recognizing a report itself, the recognized rows sit in that record temporarily — until the app collects them, or until the next nightly cleanup. This server-side completion is currently switched off by a server setting; if the owner switches it on, the exception starts to apply. • Model usage counters (without text or values) — 90 days. There are two of them: an anonymous ledger by model and price, and the daily spending counter of your account. The second one is linked to you: it disappears together with your account and is included in the export of your data. Beyond 90 days nothing about your spending is kept. • The two app usage counters (opens and minutes per day) — 90 days on the server, after which they are erased by the nightly cleanup. They also go when the account goes, and they are included in the data export you can download. • The original of the report you uploaded — on the server under your account, until you delete it yourself or delete the account. The period here is neither “minutes” nor “a month”: the file sits there for as long as your account exists, because we keep it on purpose — in Settings → “My files” you can open, download and delete each report separately. Separately and briefly there lives the working copy the server prepares for recognition: it is erased as soon as processing has finished or failed — usually within minutes. • We leave the file name as you gave it. It is part of the address at which the file sits in storage and may end up in the server’s service log. We will not anonymize it: it is your file and your name for it. But we warn you honestly — laboratories often put a surname into the file name (“Ivanova_ferritin_2026.pdf”). If you do not want a surname kept together with the file, rename it before uploading. • The result of the analysis — on the server, tied to your account, for up to two weeks. This is so that you can close the app and pick the markers up later, even if you do not come back right away. After that the result is erased from the server. • The markers you accepted on the review screen — for as long as the account exists. They live in your profile and on the server, so they survive reinstalling the app and changing phones: there is no need to upload the report again. • Personal messages — to Karina and to authors — with the photos, videos and files in them — for as long as the account exists. These messages are erased neither by the passage of time nor by the “Turn off and delete the data” button; they go when the account goes. The chat with Karina AI is not in this list because we do not store it on the server at all — it lives on your phone. • Files attached to course assignments — until you delete them yourself, press “Turn off and delete the data” (they sit in the same storage folder as your reports and are erased with them) or delete the account. • The food, water and weight diary — for as long as the account exists. • Reports about comments and the list of people you blocked — for as long as the accounts they concern exist. • Problem reports — on our server for 90 days from sending, after which the nightly cleanup erases them; they also go when the account goes and are part of your data export. The copy that arrives in our support mailbox is not erased automatically when you delete the account: write to info@karinamore.com and we will delete it. “Turn off and delete the data” does not erase problem reports. • Consent records and what remains after the account is deleted — see section 7. Separately about the server’s service logs. So that we can fix report processing when it breaks, the server writes the course of the work into a log — including the names of the sections of your report (“Thyroid hormones”, “Biochemistry”) and the file name. Without that it is impossible to see where the report stopped being readable. Marker values, your name from the report and the content of the document are not in these logs: they are stripped before writing. The logs are kept by our hosting provider Cloudflare, and their retention period is set by its settings for our plan rather than by our code — we cannot state an exact number of days here without inventing it. Report processing runs in a queue on our server rather than inside the app window: that is why the app can be minimized or closed without losing the analysis. The job and its result are tied to your account, and they can only be opened with your session token — knowing the job number is not enough. 6. Your rights Access, rectification, erasure, restriction of processing, export (portability), objection and withdrawal of consent at any time — in Settings or at info@karinamore.com. Restriction of processing (Art. 18) means that we keep your data but stop using it — while we look into your objection, for example. We respond to requests within one month; if a request is complex, we have the right to extend the period by a further two months, having told you (Art. 12(3)). Deleting the account erases your data from the device and from the server. This action is irreversible: there is no grace period for recovery. After deletion only service records remain, holding none of your markers, reports or personal messages: one indefinitely, two more for no longer than 90 days — those erase themselves — and the record of purchases, cut off from you, for the period required by financial and tax records; besides these, for no longer than 30 days after you started a payment on the website (even if it did not go through), the data of that payment kept for ad measurement. What those records are and why they are needed is listed in full in section 7. Withdrawing consent to the processing of health data does not affect the lawfulness of processing before the withdrawal. Deleting your health data (“Turn off and delete the data” in Settings) erases it from the server immediately — the reports, markers, analyses, cycle log, training calendar marks, activity totals and the files attached to course assignments (they sit in the same storage folder as the reports). In the same operation the server removes your place in the step leaderboard with its days, and the phone also sends its own request to leave. From that moment the server no longer accepts health data into your account from any of your devices, so a phone that was offline cannot bring the deleted data back; a weekly automatic check removes anything that might still have slipped through. For this the server keeps a note of when you erased the data — only the date — until you delete the account; once you give consent again, the note no longer has any effect. Health data can come back into your account only after you give your consent again yourself. Database backups exist only to recover from a failure; deleted data is never restored from them into your account. If you report one of Karina’s answers, we keep a copy of that answer (not your question) and the explanation you wrote, up to 500 characters, for the team to review. A reviewed report is deleted 90 days after it was filed — but not before it has been reviewed, so a report still waiting for review stays until then; all your reports go when the account goes. You have the right to lodge a complaint with the data protection supervisory authority of your country. Automated decisions. We do not take decisions concerning you based solely on automated processing that produce legal effects or similarly significantly affect you (Art. 22). The app explains markers and produces educational texts — it decides nothing for you and does not restrict you in your rights. 7. What remains after the account is deleted Deletion erases the profile, the food, water and weight diary, markers, analyses, original reports, personal messages to Karina and to authors with their photos, videos and files, course files, the text of your comments in the Club, the reports and blocks you made and those made about you, your steps in the leaderboard, your invite code, your Friends list and your place in other people’s Friends lists, your reports about Karina’s answers, notification delivery addresses and all issued sign-in tokens. A subscription bought on the website (Stripe, PayPal) we cancel at the payment service as part of the deletion. If the payment service does not answer at that moment, the account is deleted anyway, and the subscription is cancelled when the service next reports a charge for it to us; if you see a new charge after deleting your account, write to info@karinamore.com from the same email, and we will cancel the subscription at the payment service by hand. A subscription bought in the App Store or Google Play we cannot cancel: only you can do that, in the store — deleting the account does not cancel it, and the store keeps charging until you do. Deletion also erases your problem reports on our server (section 5); their copies in our support mailbox we delete at your request. Four service records remain, and for no longer than 30 days after you started a payment on the website (even if it did not go through) one more record (described at the end of this section). Three of them the law allows keeping for the establishment of legal claims (Art. 17(3)(e)); the fourth, the record of purchases, we are obliged to keep for financial and tax records (Art. 17(3)(b)). The main point first: not one of them holds your health data — no markers, no reports, no personal messages, no name, no email. These are records of actions, not your health data. Indefinitely we keep one record: • The record of your consents and withdrawals. What is in it: a pseudonymous identifier, the date and time you gave or withdrew consent and the time our server received it, the versions of the documents you accepted, the language, a flag showing whether you gave separate consent to the processing of health data, a hash of the text of the checkboxes you agreed to, the app version and the platform. What is not in it: your name, email, IP address, markers, reports and personal messages. Why indefinitely — this is our deliberate choice, not forgotten housekeeping. A consent record is the proof that you permitted the processing of health data. Erasing it together with the account would leave no confirmation that the permission ever existed — exactly when it is needed: in a dispute or during an audit. That is why such records are customarily kept longer than the data they relate to. For no longer than 90 days after the account is deleted, two more records live on, and they erase themselves: • The log of access being opened and closed: who opened or closed which package for you, and when. Direct data — email, name, phone — is wiped as soon as the account is deleted; a pseudonymous identifier and the action itself remain. • One technical row about the “generation” of sign-in tokens. It is needed so that a token from an old or lost phone does not come back to life if you later register with the same email address. Apart from a pseudonymous identifier and a number, there is nothing in it. Both are erased by the nightly cleanup on the server — automatically, without a request from you and without a human involved (there is no one left to ask: the account is gone). The 90-day period was not chosen at random: a sign-in token lives 60 days, so by day 90 any old token is invalid on its own and there is nothing left for this row to protect. For the period required by financial and tax records we keep one more record: • The record of purchases, cut off from you. At the moment of deletion we remove from every line your account identifier and the purchase number given by the store or the payment service, and replace the key of the line with a random one. There is no IP address in this record at all: for a payment on the website only the country and region used for tax are kept. What stays: the amount and the currency, the date, the paid period, the plan and the product, the store or payment service, the country and region used for tax, and the two ad tags of that purchase (section 4.2). How long: three years from the date of the purchase for the App Store, Google Play, our Shopify store and access opened by hand; ten years from the end of the year of the payment for Stripe and PayPal. After that the line is deleted by the same nightly cleanup. We say it to the end: for us this becomes a line about money without a buyer, but the store or the payment service keeps its own record of the same purchase, with your details, under its own rules. For no longer than 30 days after you started a payment on the website (even if it did not go through) one more record may remain: • The data of that payment kept for ad measurement (section 4.1): the IP address and browser string of the connection you paid from, the _fbp, _fbc and _ga cookies and the page address, next to the website subscription. It exists only if ad measurement was allowed when the payment was started. We do not erase it at deletion: it erases itself when its 30 days run out, and after the deletion no new events are sent with it. Separately about advertising: if ad measurement was on (by your consent, or, before 3 October 2026, by the regional default that was in place outside the EEA, the UK and Switzerland), the events sent to Meta and Google BEFORE the deletion stay with them and are kept under their rules — we hold no copies of them and cannot erase them on the platforms’ behalf. How to demand erasure there too is described in section 4.1. After the account is deleted, no new events about you are sent. The journal of evidence (section 4.1) is not erased with the account: it is kept for 4 years after its last record so that we can show your consent if it is ever disputed (GDPR Art. 17(3)(e)). Separately, about the model usage counters. There are two. The general ledger of spending by model and price is anonymous: it holds no text, no marker values and no link to a person, so there is nothing to delete there. The spending counter of your account — how many internal tokens it used, day by day — is linked to you and is erased together with your account, like everything else personal. Once the account is gone, nothing of it remains. 8. Security and who has access on the inside Data in transit is protected by TLS. Cloudflare storage and the Supabase database encrypt data at rest. Access to account data requires your session token: knowing a job number or a record identifier is not enough, every request is checked for belonging to you. Health answers are not cached on intermediate servers. Inside the team, access is held by the owner of the app and by the managers the owner appoints personally (appointing yourself is not possible, and a manager cannot appoint another manager). A manager is an assistant who answers your personal messages and opens or closes access to paid sections; publishing anything is beyond what they can do. We will say plainly what the owner and a manager see: • the list of people: email, name, registration date, sign-in method and access status. This is needed in order to open and close access to paid sections; • your personal messages to Karina and the photos, videos and files you attached to them — otherwise there would be no one to answer your message. If you write about your health in those messages, whoever answers you — the owner or a manager appointed by them — will see it; • your conversations with Club authors, with everything attached to them: the owner and the managers can see every conversation with an author and answer in it. An author sees only the conversations with themselves, with your name and picture, and not other people’s conversations; • the reports about comments, with the copy of the reported text (section 2), and the reports about Karina AI’s answers, with the copy of the answer and your explanation (section 6); • the problem reports you send from Settings, with your account identifier and device details: they arrive in our support mailbox and are read by the owner of the app and the managers; • service statistics on recognition failures: file type and size, error codes, processing steps. It shows neither the report itself nor the markers recognized from it — the server strips them and does not hand them even to the owner, and saving files for failure analysis is switched off. There is no route in the app that would hand the owner someone else’s profile or someone else’s markers: every personal request is checked for belonging to you. But we say it honestly and to the end: the owner holds the hosting account where the database and the files physically sit, and technically has access to them. The limits above are a separation inside the product, not a prohibition. We cannot guarantee absolute security; in the event of a breach creating a risk to your rights, we will notify you and the supervisory authority within the periods set by law. 9. Age The app is not intended for children under 16. We deliberately do not collect children’s data. Before your profile is created, the app asks how old you are — with the same slider you use for height and weight, and the scale deliberately goes below 16, so that answering “14” is possible and leads to an honest refusal. If the age is under 16, the profile is not created and no data is saved. We do not ask for a date of birth when you sign up and we store none: all that stays is a note on the device that the check was made — without a date of birth, name or email address, and without leaving the phone. That note survives deleting your data, otherwise a refusal could be undone with two taps. We understand that such a check can be bypassed by naming someone else’s age, and that reinstalling the app clears the note: this is an age check on the device, not identity verification. Requiring a document from a healthy-lifestyle app would be disproportionate — we would then have to process your passport, and that is a greater risk than the one we are trying to close. If you have learned that a child under 16 is using the app, write to us at info@karinamore.com — we will delete the account and the data. 10. Changes If these documents change materially, we will ask you to review the new version and confirm your consent again. 11. Contact info@karinamore.com