Privacy Policy

DiMeals app · version 2.3 · updated 1 September 2026

Who is responsible for your data

The app is published by ARCTIC MAG S.R.L., VAT ID RO48130587, Trade Register J2023003030232, registered at Str. Popasului nr. 78, bloc A, sc. 1, et. 2, ap. 9, Voluntari, Ilfov County, Romania. You can write to us any time at contact@dimiol.com.

The account: when it appears, and what it is

You are not asked for an account to install or to use the app. The plan, the recipes, the list and the library all work without one. An account only appears for the features that need a server: reading a receipt, reading the nutrition table on a package, and importing a recipe, because the right to scan has to be held somewhere that does not reset when you change phones.

An account is made without a password: you type your email address, you get a 6 digit code, you enter it. That is all.

What we hold on the server:

• your email address, plus the date you made the account, the date you last signed in, and, to the nearest hour, when each signed-in phone was last used;
• how many scans you have made, by month and by kind. For each scan we keep the month, the kind (receipt, label or recipe), whether it succeeded, which model read it, what it cost in units of computation, and how many lines came out. The photo, the file or the text you sent is never kept on our side. The result of the reading is kept for a short while, and how long and why is written under What we keep for a short while so you do not lose a scan;
• the result of each reading, for a short while after it, together with the logical key of the attempt and a fingerprint of what was sent, only so that we can give you the answer if it was lost on the way. It is not just the latest one: every scan has its own window, so the results of several scans made on the same day can sit there at once. See What we keep for a short while so you do not lose a scan;
• the sign-in codes sent to your address, in encrypted form, together with the address and the time of the request, so that nobody can request endless codes for someone else's address;
• your subscription, if you have one: which store it was bought from (App Store or Google Play), the reference that store gives the purchase, the date the subscription runs to, and when we last asked the store about it. We never see your card, your name or anything else about the payment: those stay with the store.

What the phone holds: a sign-in token, kept in the system's key vault (Keychain on iPhone, Keystore on Android), so we do not ask you for a new code on every launch. We do not hold the token itself, only a fingerprint of it that cannot be reversed: we cannot read it either.

The account can be deleted at any time, and the deletion is real. See Deleting your account and the “Your rights” section below.

What the app keeps on the phone

Everything you enter is saved locally, on your phone:

• your meal plan and your recipes, including notes and the stars you give;
• the shopping list, the products in your library, and what you ticked as bought;
• the prices you write down, your receipts and their photos;
• the app settings;
• the last recipe catalogue fetched from our server, kept on the phone so the app works offline too, plus the list of catalogue recipes you deleted, so they do not come back;
• the sign-in token and the account's address, if you are signed in;
• a scan that was started and left without an answer: its key, the account that started it, and the source to be sent again, that is the photo, the file or the pasted text. See What we keep for a short while so you do not lose a scan;
• if you turn on Nutrition goal: the sex, age, height and weight you enter, plus the target calculated from them.

Your content from the list above, that is the plan, the recipes, the shopping list, the prices, the receipts, the settings and the Nutrition goal figures, is not sent to any server of ours. We cannot see it, store it or recover it. When you uninstall the app, the local copy is removed from the device; whether any copy remains in the device backup depends on your operating system and your backup settings. What sign-in needs, meaning the token and the account's address, is used as described in the section about the account.

What does leave your phone

Seven cases, each of them needed for that feature to work:

• Signing in. Your email address goes to our server, which sends you a 6 digit code through our email provider, Brevo (Sendinblue SAS, France). The address is the only thing from the app that we send on; as with any internet request, the connection itself also carries technical data, including the IP address, which we handle as described under Server logs and IP addresses.
• Confirming a subscription. The purchase itself is made by the App Store or Google Play, not by us. What leaves the phone is the reference the store gives that purchase, which goes to our server so that it can ask that store, directly, whether the subscription is valid and until when. We keep the reference and that date on your account, so that scanning works on any phone you sign in on.
• What you send to be read. A photo of a receipt, a photo of the nutrition table on a package, or a recipe (as a photo or as pasted text) leaves the phone, passes through our server and reaches the artificial intelligence provider that reads it. This is the most substantial of these cases, so it has its own section below.
• Fetching new recipes. On launch, the app asks our server (dimiol.com, hosted with OVHcloud on a server located in Germany; the provider is Hebergement OVH Inc., Canada) for a file with the recipes we have published since your version, so you can get them without waiting for a new release. The catalogue request is a plain file download: it sends nothing from what is inside your app, not your plan, not your recipes, not even which recipes you already have or which ones you deleted. The connection does carry the usual technical data, including the IP address, described under Server logs and IP addresses. Recipe photos are downloaded from that same server when they appear on your screen. Those requests are a different matter from the catalogue: they go out when you look at a recipe, and the address requested says which recipe it is. See Server logs and IP addresses. If you have no internet, or the server does not answer, the app carries on with the recipes it already has.
• Checking for updates. On launch, the app asks the update server of our technical provider, Expo (Expo Technologies, Inc., United States), whether a newer version exists. That request carries technical information about the app: the runtime version, the operating system, the identifier of the project the update belongs to, the identifier of the update the app is running now, and a random identifier of this installation, which Expo uses to tell which installations have asked for an update. That identifier is made by the app the first time it runs and kept on the phone; it is not your device's identifier, and it holds no name, no email address and nothing else you have written in the app. As with any internet request, the connection also carries the IP address. It does not carry the content of your plan or your recipes; it carries the technical data listed above. Expo Technologies, Inc. is in the United States; Expo states that it complies with the EU-U.S. Data Privacy Framework and that it uses standard contractual clauses or other appropriate mechanisms for transfers, as described in its own privacy documentation.
• Importing a recipe from a link. If you paste a recipe address, the app requests that page directly from that website, with no intermediary of ours. That website sees your IP address, exactly as it would if you opened it in a browser. What happens next is governed by its privacy policy, not ours.
• The photo of an imported recipe is downloaded from that same website and then stays on your phone.

Photos and texts sent to be read

The rule, in short: from what is inside the app, we send on only what you choose to have read. The request also carries the technical data any internet connection carries, including the IP address, described under Server logs and IP addresses. Today there are three such paths (a shopping receipt, the nutrition table on a package, and a recipe, as a photo or as pasted text). If we add others, the rule stays the same, and this page will be updated first.

What happens to what you send:

• Your photo, your file and your text are never written to disk on our side. They pass through our server's memory and are gone once the reading is finished. There is no code in our server that would save them. The result of the reading, on the other hand, is kept for a short while in our database, so that we can give it to you if it was lost on the way and so that the same reading is not paid for twice. How long and why is written under What we keep for a short while so you do not lose a scan.
• Who reads it: OpenAI Ireland Limited (Dublin, Ireland), on their models. The processing happens on their servers, including outside the European Union; those transfers are covered by the standard contractual clauses in the data processing agreement between us and them.
• How long they keep it: we explicitly ask them not to retain the request in our account, so what you send is not collected anywhere on our side and does not appear in our dashboard. What remains are their abuse monitoring logs, which they keep for up to 30 days, unless the law requires them to keep them longer, and which we cannot access. What you send is not used to train models.

What a photo carries besides what you can see: a photo taken with a phone may carry things attached to it that are not in the picture, among them the place where it was taken, the exact time and the device model. What it actually carries depends on the phone and on your settings. The photos sent to be read do not carry those along: the app takes the picture apart and writes it again before it leaves, so what leaves is the dots of the image, not the file with everything that surrounded them. This holds for a photo taken on the spot, one chosen from the gallery, and one chosen from Files. If the rewriting does not succeed, the photo does not leave at all and we tell you so.

A PDF is the exception and leaves exactly as it is. We cannot rewrite a PDF without risking damage to the very document you want us to read, so what it carries inside leaves with it: that may be the author's name, the program that wrote it, or other notes that program adds. If you would rather it did not, photograph the document and send the photo instead.

One thing worth knowing before you photograph a receipt: receipts in Romania often carry the cashier's name printed on them. The photo that leaves is the whole receipt, as it is, not only the products and prices on it. If you would rather it did not, cover the line with the name when you take the photo, or type the prices by hand: the app works just the same, and what you type never leaves the phone.

What we keep for a short while so you do not lose a scan

A reading takes time. If your phone gives up, if your connection drops, or if the app closes right then, the scan has already been made and paid for, and the answer is lost on the way. So that this does not happen, a few things are kept for a short while. They are held only so that we can give you back a lost answer and so that the same reading is not made and paid for twice, not as a history and not as an archive: we do not read them, we do not gather them, and we do not use them for anything else.

On our server, tied to your account:

• the result of the reading, that is exactly what the model got out of your photo, your file or your text: for a receipt, the lines and prices read; for a label, the nutrition values; for a recipe, the ingredients and the steps;
• the logical key of the attempt and a fingerprint of what was sent. The key is made by the app for that one attempt: it holds the clock reading of when the attempt started and two random strings, so it tells when you tried, but nothing about you and nothing about what you sent. The fingerprint is a mathematical summary worked out from what you sent, from which the photo or the text cannot be rebuilt; it is there so that we recognise the same request even if the app restarted in between and forgot the key. For an app that does not send the key, such as an older version, only one thing is kept instead of two: there the key is the fingerprint.

How long: the day of waiting is a FLOOR, not a ceiling: they are not deleted sooner than 24 hours after the scan ended, and the clean-up passes only once a day, at a fixed hour. So the deletion falls somewhere between 24 and about 48 hours, depending on how close to that pass the scan ended. They go together, the result and both keys. When you delete your account they go with the rest of your data, without waiting for this window; what “go with” means when the database refuses at that very moment is written under Deleting your account.

One case where that window starts later, so that you know the weak part too: if a scan is left without an outcome, meaning something failed on our side during the reading itself, its row never gets an ending moment, and without one the clock does not even start. The result of the reading is not at stake, because such a row has none written into it; the two keys are. The clock starts only when you come back: at your next scan, or merely by opening the scanning screen, the server closes the row left that way and only then gives it an ending moment. Your return starts the 24 to about 48 hour window, it does not end it: the keys go with the clean-up after that. If you never come back at all, they stay until the details of the scan are deleted, at twelve months.

On your phone, for as long as a scan has started and has not yet had an answer, we keep the key of that attempt, the account that started it, and the source to be sent again: the photo, the file (a PDF included) or the pasted text. Without them, an app closed during the reading would have nothing left to send again, and the paid scan would be lost. The registry row, that is the key, the account and the pointer to the source, lasts 24 hours, and usually far less: it goes at the first of these moments, when the answer arrives, when the scan is refused for good, when you give it up from the error card, when you leave the scanning screen, when you sign out, when your session expires, and when you delete your account. At each of them the working copy of the photo or the file goes as well.

The button that sends your choice again does NOT delete it, and that is worth knowing, because it is the whole point of it: sending again needs the source. It rewrites the attempt, so the 24 hours start over from your last send, not from the first. For as long as you keep trying, the source stays on your phone; the limit is counted from your latest attempt. The button next to it, the one that takes you back to choose something else, is the one that gives up and deletes.

And if none of those moments ever gets to happen, because the app closed during the reading and you never come back to the scanning screen, the attempt expires anyway after 24 hours. The app clears its own expired attempts, together with their working copies: once at every start, whichever screen you land on, then on its own at the hour of expiry if it stays open, and once more every time you bring it back to the front. You do not have to open the scanning screen and you do not have to do anything.

What we cannot promise, so that you know the weak part too: while the app is closed or put to sleep by the phone, no code of ours runs, for anybody. So the deletion does not happen at the exact minute the 24 hours are up, but at the first start or return after that. This is not a choice of ours: a phone gives no app a background window that a to-the-minute promise could rest on. Until then the file sits in the app's temporary space, on your phone: it goes nowhere and it never reaches us.

When you send someone a recipe

The “Send the recipe” button makes a link to dimiol.com, and the recipe travels inside the link, after the # character. What follows the hash never reaches the server: that is how the internet is built, it is not a promise of ours. The fragment after the hash is not part of the HTTP request the browser makes, so it never reaches our server. We checked it live in the server's log: when such a link is opened, the address our server is asked for is /r/, without the recipe. So it is not that we do not keep your recipe: we never receive it.

The page that opens asks nothing of anybody else: no fonts, no measurement, no images from other servers. Neither you nor the person you send it to needs an account for this.

Camera and photo library

The app asks for camera and photo library access only when you choose to attach a photo to a receipt or a product, or to scan something. Photos you attach to a receipt or a product are copied into the app's folder on your phone and stay there; they are not uploaded anywhere. A photo you send to be read does leave, as described above, and only after you confirm on a screen that tells you what is about to happen.

Photos taken for scanning are first put through a conversion on the phone, which shrinks them. We have checked that the resulting photo does not carry the place where it was taken, the phone's make, or the date.

Server logs and IP addresses

As with any internet request, our server sees the IP address of your connection, because otherwise it would have nowhere to reply. What we do with it:

• it never reaches our database. There is nowhere for it to go: no table, no column;
• it does not reach our application's log either. For each request we write four things: what kind of request it was, which address on the server it asked for, what answer we gave, and how long it took. No IP addresses, no email addresses, nothing of what you sent;
• it is held only in the server's memory, for at most one hour, so that we can stop anyone requesting thousands of codes at once, and it is gone at the first restart.
• the same goes for recipe requests. When the app fetches the recipe catalogue or a recipe photo, the server that serves those files sees the IP address and the path requested, and the path of a photo says which recipe it is, that is, what you are looking at on screen. Neither the address nor the path is written down anywhere: there is no access log on that side, and the configuration that ensures this is kept next to the app's code, with a tool that compares it against the one running on the server. The comparison is run by hand, when we ask for it, not on every request; its purpose is that a change on the server can be found, not that it is prevented.

What we do not do

• We do not ask for an account in order to install or to use the app.
• We show no ads, and we do not sell or rent your data. We pass it on only to the providers named on this page, only what the feature you asked for needs.
• We use no behaviour analytics, no cross-app tracking and no profiling.
• We do not keep the photo, the file or the text you send to be read, and we do not look at what you scanned. The result of the reading we keep for a short while, only so that we can deliver it to you: see What we keep for a short while so you do not lose a scan.

If you write to us

When you use “Write to us” or “Report a problem” in the app, your own email app opens with the message prepared. For a problem report we automatically add, at the end of the message, the app version, the operating system and the language, so we can fix it. Nothing from your plan or recipes is attached. The message is sent when you send it, and it arrives in contact@dimiol.com, hosted by Zoho Corporation in its European Union data centre. We keep the correspondence for as long as we need it to answer you and to track reported problems, then we delete it.

Deleting your account

You can delete your account from inside the app, at any time: “•••” → About the app → Delete my account. If you have already uninstalled the app, write to us from the account's own address at contact@dimiol.com and we will delete it, within 30 days at most.

The deletion is real, not a flag. What disappears from our database is your email address, the history of your scans with every technical detail attached to them, including the briefly kept result and the request keys, if any were still there, the details of your subscription including the store’s purchase reference, any sign-in codes still stored at that time, and every token, meaning every phone you were signed in on. No “deleted” row with your address in it is left behind.

Three things survive deletion, and they deserve to be named.

• The database backups. We make a daily copy of the database so that we can repair damage. Your account disappears at once from the working database, but it remains in the copies made before the deletion: for at most 14 days in the ones on the server, which delete themselves every night, and for about one year in the copy we keep on a computer of ours, which is pruned at the next fetch of new copies, not by the clock. The copies are not used in the ordinary running of the service; they are checked automatically when made, so that we know they are not corrupt, and otherwise we would open them only to rebuild the database after damage.
• A mark that you deleted your account. So that a restore from a backup cannot bring you back against your will, we keep separately, outside the database, the account's internal number and the date of deletion. That is all. Not your address, nothing you wrote: that number is a random string of letters and digits that says nothing outside the database we have just emptied. After any restore, this list is applied again, before the service starts, and the accounts in it are deleted a second time. The mark itself goes once the last backup copy that could have brought you back has expired, which in practice means about one year. We do not delete it by the clock, but when we look at which copies still exist, and that happens when we fetch new copies; until then the mark may stay somewhat longer.
• The reference of a replaced purchase. When you change your subscription, from monthly to yearly for example, the store issues a new reference and leaves the old one behind. We keep the old one permanently, in a separate list, so that nobody can use it again to obtain a subscription without paying. That list is not tied to your account in our database and is not deleted along with it. It holds no name, no email address, nothing you wrote: it is the number the store gave the purchase. But the store can link it back to you, so it remains personal data, and we keep it on the ground of our legitimate interest in preventing a purchase from being reused. The reference of your current purchase does not go into that list.

What we cannot promise, so that you know the weak part too. The mark sits on the server and reaches our own computer only when we fetch the copies, which we do from time to time, by hand. If we lost the server entirely just between your deletion and the next fetch, that mark would not reach anywhere, and a rebuild from the older copies could bring you back. It is the only situation in which your deletion would not defend itself, and if it happened, you can ask us to delete again.

What stays: everything on your phone, that is, your recipes, plan, list, product library and receipts. We do not hold them, so we cannot delete them; the local copy is removed when you uninstall the app, and whether any copy remains in the device backup depends on your operating system and your backup settings. If you asked for deletion by email, we keep your message for as long as we need it to show that we acted on it. The steps, in full, are at Deleting your account.

Your rights

The General Data Protection Regulation (GDPR) gives you the right of access, rectification, erasure, restriction, portability and objection. Here is what each one means here, concretely:

• Access. You can find out what we hold about you. Part of it you already see in the app: your address is in “About the app”, your remaining scans are on the scanning screen, and your subscription is on the subscription screen. The rest, meaning the dates, the technical details kept for each scan and the store’s purchase reference, we send you in writing on request, at contact@dimiol.com.
• Rectification. If anything we hold about you is wrong, you can ask us to correct it, at contact@dimiol.com. In practice the one you are most likely to want changed is the email address: you change that by deleting the account and making a new one on the right address, and you lose nothing from your phone by doing so.
• Erasure. From inside the app, right away, or by an email to us. See the section above.
• Portability. On request we send you, in a file made to be read by a machine, everything we hold on your account: your address, the dates, the history of your scans and the details of your subscription. What actually matters, your recipes and your plan, is already with you on the phone, and may be included in the device backup, depending on your operating system and your backup settings.
• Objection and restriction. You can stop the processing tied to your account at any time without losing the app: sign out, or delete your account, and the plan, recipes, list and nutrition carry on working on the phone, as before. That stops the account and the scanning features. It does not stop the two requests the app makes on launch even without an account, for the recipe catalogue and for the update check; those are described above. They do not carry the content of your plan or your recipes; they carry the technical data described there.

On what basis we process: we hold your email address, the history of your scans and the details of your subscription in order to perform the contract between you and us, that is, to give you the features you asked for: without an account we cannot tell that a subscription is yours, and scanning cannot work. Sending a photo to the provider that reads it is on the same basis, at your explicit request, tapped by you on a confirmation screen. On the basis of the contract as well, we keep for a short while the result of the reading and the request keys, described under What we keep for a short while so you do not lose a scan: without them we could not give you the scan you asked for, if the answer was lost on the way.

The technical processing, on which basis: three things happen that you did not ask for one by one, and all three rest on our legitimate interest (Article 6(1)(f) GDPR) rather than on the contract:

• the IP address of your connection, for preventing abuse. Our interest is that nobody can request thousands of sign-in codes for other people's addresses. It is held only in the server's memory, for at most one hour, and never reaches our database or our log;
• the IP address and the path requested, when the app fetches the recipe catalogue or the recipe photos. Our interest is that the recipes you have stay up to date without waiting for a new release. The request sends nothing from what is inside your app, but the path of a photo says which recipe it is. Neither the address nor the path is written down: they reach neither a log nor a database;
• the technical data that goes with the update check (the runtime version, the operating system, the project and update identifiers, the random identifier of this installation, and the IP address of the connection), which reaches Expo. Our interest is that the app you have keeps working and can be fixed. They do not carry the content of your plan or your recipes; they carry the technical data listed above.

You can object to any of these, at contact@dimiol.com, and we will tell you what stays possible without them.

The deletion mark, on what ground: we keep the account's internal number and the date of deletion so that we can meet our legal obligation to erase your data for real, including after a backup is restored (the right to erasure, Article 17 GDPR). We cannot let you object to this one: without that mark, a restore would bring your account back. How long we keep it is written below, under “How long we keep things”.

Support correspondence, on which basis: we process what you write to us in order to answer you and to follow up the problems you report. For answering about the service we rely on performing the contract; for keeping a record of reported problems and looking into them we rely on our legitimate interest in keeping the app working and safe.

How long we keep it:

• your email address, your subscription and your sign-in tokens: for as long as the account exists. They disappear when you delete it;
• the sign-in codes: a day. A code is only good for ten minutes, and after that the row is read by nothing, so a daily clean-up deletes it;
• the details of each scan: twelve months, then they are deleted by that same clean-up. Your monthly quota only ever looks at the current month; the twelve are so that we can still answer a question about what a past month cost;
• the result of the reading and the two request keys: between 24 and about 48 hours after the scan ended. The day is the floor, and the clean-up passes once a day. See What we keep for a short while so you do not lose a scan, including the case where the window starts later;
• a scan started and left without a verdict, on your phone: 24 hours from your last send, together with the working copy of the file, and usually far less, because it goes at the first of the moments listed in that section. A passing failure keeps it on purpose, so that the resend button has something to send, and every resend starts the limit over. The deletion happens at the first start or return after those 24 hours, because nothing of ours runs while the app is closed;
• the IP address: at most one hour, in the server's memory alone;
• the database backups: 14 days on the server, which delete themselves every night, and about one year in the local copy, pruned at the next fetch. See “Deleting your account” for what this means when you delete yours;
• the mark that an account was deleted (the account's internal number and the date): until the last backup copy older than it expires, that is, about one year;
• the reference of a replaced purchase: permanently, so that it cannot be reused;
• correspondence you send us: for as long as we need it to answer you and to track reported problems, then we delete it.

If you are not satisfied with our answer, you may contact the Romanian Data Protection Authority (dataprotection.ro) or the supervisory authority of the country where you live, where you work, or where the alleged breach took place.

Children

The app is not aimed at children and collects no data about them. The baby marks on recipes are cooking notes written for parents, not information about any particular child.

Changes

If the app ever starts sending new data off your phone, we will update this page before that feature reaches you, and say clearly in the app what changes. The date at the top shows the last change.