What is collected, and by whom.

Short version: this website has no analytics code, cookies or forms, although its host still processes the technical details needed to serve a page. The app keeps your diary on your phone. The features that send anything elsewhere, and the services that receive it, are written out below.

Last updated 10 October 2026.

This website

There is no analytics script, no tag manager, no cookie banner, and no cookie to put behind one. There is no form either — no address to leave, no list to join, nothing that asks you for anything. The page sets nothing in your browser and does not attempt to identify you.

Every asset — the typefaces, the images, the stylesheet — is served from this domain. There is no font CDN and no embedded media, so loading a page makes no extra request to an analytics, advertising, font or media provider. That is a deliberate position rather than an accident of simplicity: a site whose argument is that figures should say where they came from should not be quietly reporting its readers to somebody else.

Cloudflare hosts and protects the site. Like any web request, loading a page exposes the IP address, requested URL, User-Agent and ordinary routing and security metadata to the host. Cloudflare may retain service logs under its privacy policy. Burnline does not use those logs for advertising or to build a reader profile.

The app

Where your data lives

On your phone, in the private App Group container shared only by Burnline and its widgets, as protected JSON files: your profile, your saved entries, and one file per day. There is no account to create, no Burnline server holding a copy of the diary, and no sync to anything by default. If your data is on a second device or in a backup, Apple’s backup services put it there under your Apple Account settings.

This is the reason there are no accounts, and it is a decision rather than a gap. An account’s real product would be a server holding other people’s food diaries — data adjacent to health, and a standing liability for an app whose entire argument is traceability.

Health data

If you connect Health, the app reads steps, active energy and workouts. It reads them and never writes: nothing Burnline calculates is put back into your Health record. Permission is asked for by iOS, is optional, and can be withdrawn in Settings at any time. The app works without it.

What leaves the device

AI Estimate and Lorie each ask for permission before their first request. Automatic About today notes are off by default and have a separate switch under Profile → Settings → AI & Privacy. You can turn either feature off there. Manual logging and Health import still work. Turning a feature off stops new requests and cancels pending work, but cannot recall information already sent.

Three content-bearing features send data after you use them or enable the relevant option, and they are nothing like the same size. The app also makes technical requests to Apple for App Attest, DeviceCheck and StoreKit when it prepares AI access or checks a purchase. Each path is set out separately rather than averaged into a sentence that would fit none of them.

An estimate. Photograph a plate, or type something the food list has never heard of, and the photograph or the line of text is sent to be estimated. What goes with it is the standing instruction that asks for a figure in a fixed shape, and nothing else: not your profile, not your weight, not the rest of the day, not anything else you have ever logged. The figure comes back, you see it and the assumption it rests on before it is saved, and the photograph is not kept — not in the app afterwards, and not by us.

A question for the companion — the sheet behind Ask Lorie, and the sentence that sometimes appears under About today, which is written the same way. This one is different in kind, and saying otherwise would be the dishonest thing on this page: it sends the day. Every entry in it, food and exercise, with the name, the time, the portion, the calories and macros, how confident the figure was and what it assumed, where the figure came from, and the words you typed when you logged it. With them go the day’s figures — burned so far, the burn expected by midnight, eaten, your step count, protein against its target, your goal and the target range it sets, the intake that plan allows and how much of it is left — and a short summary of the days behind it: your averages over the last seven and thirty days, and the foods that turn up most often. Then whatever you type into the conversation.

It is sent because there is no other way to answer the questions the thing exists for: is protein short today? cannot be answered without today, and one given the totals alone could only talk about your lunch in the abstract. What does not go with it: your name, your weight, your height, your date of birth, and the days themselves — history is sent as averages, and an individual past meal is looked up only if you ask about one. The note under About today is written only with automatic notes enabled, when the day has moved. Health-derived activity, steps and calorie figures are included when Health is connected; raw Health records are not uploaded.

A barcode. Scanning one sends the digits under it to Open Food Facts, a public database, and the manufacturer’s declared figures come back. The request carries the barcode and a User-Agent that identifies Burnline; because it is a direct internet request, Open Food Facts also receives the IP address and ordinary connection metadata. It does not receive your profile, diary, Health data or purchase identifier. There is no Open Food Facts account or API key. See its API documentation. This is the one free feature that needs a network. The built-in food list, by-hand form, repeats, saved entries, widgets, statistics and export do not.

Who handles it

An estimate and a companion turn take the same road. It has two stops, and only the first of them is ours.

That first stop is a small server we run: the proxy. It exists so that nobody has to go and find an API key of their own. It holds ours, checks that the request came from a genuine copy of this app on a real device, and checks whether it is inside the fifty free estimates or covered by a subscription — then applies our instructions and usage limits and hands back the answer. The proof of the device is a signature made by the phone’s own security hardware, and the proof of a subscription is a receipt from Apple. Neither is a name, an email address or an account.

From there the selected text, photograph or companion context goes to OpenRouter and then to Google, whose Gemini 2.5 Flash model answers it. OpenRouter selects an eligible Google endpoint for that model. Our server requests zero-data-retention routing and disallows provider data collection. If an eligible route is unavailable, the request fails rather than silently using a different privacy policy. Routing and billing metadata are distinct from diary content. See OpenRouter’s zero-data-retention documentation.

Third-party services and protection

Cloudflare delivers the website and proxy traffic. Apple provides Health, App Attest, DeviceCheck and StoreKit. Open Food Facts answers barcode lookups. OpenRouter and Google process optional AI requests. Burnline does not authorise any of them to use diary or Health-derived content for advertising or tracking. Where a service processes data for Burnline, it is required to protect it at least as strongly as this policy and applicable Apple rules require.

For AI requests, that promise is also enforced in the request itself: zero-data-retention routing is required, provider data collection is denied, and fallbacks are disabled. A request fails if no route satisfies those conditions. Burnline contains no advertising SDK. Optional app analytics is described separately below.

Optional app analytics

Versions that offer the analytics choice use Google Analytics for Firebase only after you choose Allow analytics. Choosing Continue without analytics leaves every app feature available. The SDK is not initialized before you opt in. This does not add analytics to this website.

Analytics records app interactions such as onboarding steps, screen views, successful additions, AI request outcomes and response times, and purchase and restore outcomes. Addition events contain only a source category, such as manual, library, barcode or AI; they do not contain the entry itself. Google also processes an app-instance identifier and technical information such as device and operating-system information, app version, language, sessions, approximate region and supported in-app purchase metadata. These records are pseudonymous, not anonymous. Firebase also receives technical diagnostic information about its SDK, such as device platform and SDK versions, without linking that diagnostic information to a user or device identifier.

We do not send your name, diary contents, food names, body measurements, calorie or nutrient values, Apple Health data, barcodes, photographs, messages or AI responses to Analytics. Burnline does not set a User-ID or join analytics with its AI-service or purchase-verification identifiers. Advertising identifiers, advertising consent and ad personalization are disabled. Analytics is used to improve the app, not for advertising. See Firebase privacy information and Google’s Privacy Policy.

You can withdraw consent under Profile → Settings → Share app analytics. Turning it off stops collection and resets the local analytics data and app-instance identifier. Erase everything also turns analytics off. These actions do not retroactively delete events already processed by Google; those remain subject to the Analytics property’s retention settings. Contact us using the support link below for privacy requests.

What is kept, and what is not

The proxy keeps the attested public key and assertion counter with the lifetime free-request tally for as long as the free allowance and its anti-abuse protection operate. A one-time challenge expires after five minutes; an active-request lock after two minutes; an unfinished request reservation after one day. Rate-limit counters expire with their one-minute, one-day or thirty-day window, aggregate cost records after no more than seventy days, and a cached subscription check after no more than one minute. Subscription limits are associated with Apple’s original transaction identifier. These are pseudonymous identifiers, not anonymous data: they can link requests from the same installation or purchase, even though no account, name or email is stored with them.

Apple App Attest verifies the app. Apple DeviceCheck records whether this device has already received its lifetime free grant; its token is sent to Apple for that check and is not stored by our server. IP addresses are processed by Cloudflare for network delivery and abuse protection. Our short-lived rate-limit records use a hash rather than the raw address.

The Burnline proxy does not persist an AI request or response body. It exists in memory long enough to be checked, forwarded and returned, then is dropped. Application request-body logging is disabled. OpenRouter states that it does not retain prompts unless prompt logging is expressly enabled, and ZDR routes do not store or train on them. Its ZDR definition does permit transient in-memory prompt caching. What Burnline retains is counts — how many calls and how much they cost — plus the technical anti-abuse records above. Cloudflare and Apple also process technical metadata necessary to operate their services.

Getting your data out, and deleting it

Profile → Your data → Export as a spreadsheet writes every entry you have ever logged as a CSV and hands it to the share sheet. The origin of each figure is a column like any other, so the record of what was measured and what was guessed survives leaving the app.

Profile → Settings → Erase everything removes the profile, saved entries and every logged day and returns the app to setup. It also withdraws AI consent, clears cached companion notes, and removes temporary exports and diagnostic files. Copies you exported or that remain in device backups must be removed through the place where you saved them.

Erasing or uninstalling cannot reset the lifetime allowance. The local free-estimate count and App Attest key identifier are kept in the device Keychain, which may survive an uninstall, and the pseudonymous anti-abuse record remains on the proxy. Apple retains the DeviceCheck state. These records contain no diary, name or email. A valid subscription can still be restored through Apple after reinstalling.

Your choices and rights

Optional AI content and Health-derived context are processed only after purpose-specific consent. You can withdraw it under Profile → Settings → AI & Privacy; doing so stops future requests and cancels pending work without affecting manual logging. StoreKit data is processed to provide and restore Pro. Technical delivery, security and anti-abuse data are processed to operate and protect the service. None of these data is sold, used for advertising or used to make a decision with legal or similarly significant effects.

Where data-protection law applies, you may ask for access, correction, deletion, restriction or portability of personal data, or object to its processing, by emailing support@burnline.live. You may also complain to your local data-protection authority. Because Burnline has no account and does not attach a name or email to server records, an email address alone cannot identify a device or purchase record; a request may need a technical identifier from the app or Apple.

Children

Burnline’s calorie targets and AI guidance are intended for adults aged 18 and over, not children. It is not a medical service and does not diagnose or treat any condition.

Contact

For questions about this policy or to make a privacy request, email support@burnline.live. For a technical report, the support page explains which details can help us investigate.