Privacy Policy

Version 1.37.1

Privacy Policy — version 1.37.1 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. • Health data (special category, GDPR Art. 9): uploaded lab reports and the markers recognized from them, cycle logs, pregnancy, symptoms, nutrition and water, plus daily activity totals from Apple Health / Health Connect — steps per day and active energy burned today (details in section 4). • Your personal messages to Karina — a private conversation with a person, not with the AI assistant: the text of your messages and the photos 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. They are read by you and by Karina (and by a manager she appoints — see 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. • 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. • 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. We hold no card details and never do: the payment is run entirely by the store. 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 them in our own database, but our hosting provider Cloudflare processes them 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. We do NOT collect: location, contacts, calendar. The app does contain two third-party advertising kits (SDKs): Google’s Firebase Analytics and Meta’s SDK. By build configuration both are switched off and collect nothing while advertising analytics is off — and whether it is on depends on your region (see section 4.1): in the EEA, the UK and Switzerland only after you agree on the consent screen, elsewhere on by default with an off switch in Settings. When analytics is on, they read your device advertising identifier (on iPhone only if you also allowed tracking in Apple’s system prompt) and report the app install and the purchase to the platforms. 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 a phrase set in advance, and crash reporting (Sentry) — what exactly is in a report is described in section 4. Playlists in the Meditations section from YouTube Music and Apple Music play inside a built-in player of that service — the service’s own web page shown inside the app (on iPhone, Apple Music plays through the system MusicKit under the phone’s subscription): when you open a playlist, the service receives your IP address and device data and uses its own cookies under its own privacy policy; nothing from your Astras account is passed to it. If you sign in to Apple Music from the player, you sign in with the service directly — your login goes to it, not to us — and that sign-in stays in the app’s browser storage until you delete the app or its data. Spotify playlists do not play inside the app: tapping one opens the Spotify app or website, where Spotify’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 per day (up to 90 days) and active energy burned today. 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 and only you see them: they are not shown to other people, are not used for advertising or analytics, are not passed to third-party services, are not stored in iCloud, and are erased by the “Turn off and delete the data” button in Settings and together with the account. Nothing else from Health leaves the phone: no separate workouts, no heart rate, no sleep, no route. Separately — the step leaderboard: if you join it yourself, your step total for the day is shown to the other participants (that is the whole point of a leaderboard), and along with the number they 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 are also read while the app is in the background or closed: roughly once an hour on iPhone and every 15–30 minutes on Android, so that your total does not depend on how often you open the app; background reads cover today's and the previous two days' steps only, nothing else. Withdraw your consent to health data processing, and the phone stops sending totals, background reading stops, and your leaderboard participation is removed together with its days; 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. Leave the leaderboard, and nothing is shown to others. 3. Why we process it (legal bases) • Health data — 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”) are unavailable. That same consent covers the transfer of health 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)). If you write about your health in chat yourself, that text will be processed to produce an answer under the general consent you give by accepting these documents. • 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)). • Ad measurement (the events about app use, section 4.1) — in the EEA, the UK and Switzerland your separate consent only (Art. 6(1)(a)); elsewhere it is on by default under our legitimate interest in measuring advertising (Art. 6(1)(f) and local equivalents), with the right to opt out 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)); elsewhere the same regional default and the same right to switch it off apply. 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, in the EEA, the UK and Switzerland only after your consent. • 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. 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 short set of facts from your profile and the markers already saved in the app, so that the answer takes your data into account. The answer is generated by the GPT-5 nano model; it was developed by OpenAI, but 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 and in the same European zone, we keep a backup model, DeepSeek-V4-Flash: your question goes to it when the primary model is busy or does not answer. It was developed by DeepSeek, but it 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. This request stays in Europe: the deployment we use is created in the Sweden Central region on the “Data Zone Standard” tier. That means processing may take place in any European Union country, but never leaves the European data zone, and everything is stored inside it too. Reports are not sent to it. • Google (Gemini API) — 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 goes to Google instead. We use the paid tier: the provider does not train its models on your data. • Anthropic (Claude) — the last backup for chat answers, used when both providers above are unavailable; in that case your chat question is passed to it. It does not receive lab reports. • 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. • Cloudflare — servers and file storage: this is where the originals of your reports, the attachments and photos from your personal conversation, the messages themselves and Karina’s materials physically sit. A separate service, Cloudflare Stream, stores and delivers Karina’s videos — course lessons and clips in the club. When you play a video, the phone contacts Stream directly, and Stream sees the address of your connection. The videos themselves hold none of your personal data. • 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. • Stripe, PayPal and Paddle — 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. 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 keep it for 30 days to match a later payment and, only if that box is ticked, to write to you about the app; untick the box, use the unsubscribe link in any such email, or delete your account, and we stop. They receive no health data. For buyers in India the seller of record is Paddle. • Resend — delivery of the one-time sign-in code by email. It receives only your address and the code itself. It receives no health data. • Google (Firebase Analytics) and Meta (an SDK on your phone) — advertising, under the regional rules of section 4.1: in the EEA, the UK and Switzerland only after you agree on the consent screen, elsewhere on by default with an off switch in Settings. While advertising analytics is off these kits do not start at all. When it is on they report the app install and the purchase to their platforms and pass your device advertising identifier. 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. • 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. • 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 short notification phrase and the label of the screen to open. The content of your messages is not passed to Expo. Every phrase you see in such a notification is 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. What does not change is the promise that matters: neither your text, nor your markers, nor a report analysis, nor a file name, nor anyone’s name can be placed into a notification — not because we promise not to, but because the code physically cannot put variable text there. What exactly was written to you, you will read only by opening the app. 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 — payment is run entirely by the store. • 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. 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 in the European Union: our Azure resource is created in Sweden (Sweden Central) on the “Data Zone Standard” tier, and that is fixed in our own configuration — processing may take place in any European Union country, but while Microsoft is answering, your question does not leave the European data zone. 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 is set in our own configuration, and it is European. 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 health data, no markers, no reports and no message content — 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 and speech recognition, 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, under the regional rules set out there; for California residents that transfer counts as “sharing” under the CPRA, and you can opt out with the switch in Settings or 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. Whether these two purposes are on depends on your region. In the EEA, the UK and Switzerland they stay off until you tap “Accept all” — or turn on the purpose you want under “Choose what to allow” — on the consent screen. 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. Elsewhere it is on by default — the law there requires notice and the right to opt out; the notice is given by the link to this policy on the first screen of the app and by this section. You can switch it off at any time in Settings; once off or withdrawn, nothing is sent and the app keeps working in full. On iPhone, Apple's system tracking question applies on top: answer “Ask App Not to Track” and we tell the platforms so, and they will not tie the event to your advertising profile. There are two senders, and they differ. OUR SERVER reports the install, the registration, the subscription and its renewal: 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 and currency. 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. 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 bases — regional, as described above: in the EEA, the UK and Switzerland your consent (Art. 6(1)(a)); elsewhere our legitimate interest in measuring advertising (Art. 6(1)(f) and local equivalents) with the right to opt out. Recipients: Meta Platforms Ireland Limited (Ireland) and Google Ireland Limited (Ireland); both act as independent controllers of this data, so we answer for what we sent and they answer for what they do with it under their 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; 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). 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 dispose of their own copies as independent controllers. 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, 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 — for as long as the account exists. It goes when the account goes, and it is included in the data export you can download. • 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. • Recognized markers on the device (cache) — 30 days. • 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, the photos in them and the files attached to course assignments — for as long as the account exists. These messages are erased neither by the passage of time nor by the “delete health 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. • 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, and those erase themselves. 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 and activity totals. 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. The data returns only if 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, a copy of that answer (not your question) is kept for the team to review and is deleted 90 days after the review is closed. 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, markers, analyses, original reports, personal messages to Karina and their attachments, course files, the record of purchases and renewals, notification delivery addresses and all issued sign-in tokens. Three service records remain, and the law allows keeping them for the establishment of legal claims (Art. 17(3)(e)). 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, the versions of the documents you accepted, the language and a flag showing whether you gave separate consent to the processing of health data. What is not in it: your name, email, 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. Separately about advertising: if ad measurement was on (by your consent or by the regional default), 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. 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 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; • 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