Privacy policy for Recipe Passport

Last updated: 8 November 2026 · See previous versions

Who we are

Recipe Passport is made by Bounceback Studios, the registered business name of a sole trader in Australia, ABN 24 362 033 828. Contact: support@bouncebackstudios.app. We are the party responsible for the data this policy describes.

The short version

Your recipes stay on your phone. We receive none of your recipes or other data, except a problem report or bug report you agree to send (see “Problem reports” and “Bug reports” below).
The app can send us a short problem report when an import fails or when you report a recipe. Setup shows a “Send error reports automatically” box: ticked, which you can untick, except where the country setup shows (the one detected, or one you pick) is in the European Economic Area, the United Kingdom or Switzerland: there it starts unticked and is on only if you tick it; those automatic reports hold only app, phone and error details, never the link you imported, a recipe or a note, which are sent only when you tap Send. If you never answered, you are not opted in. You can turn it on or off at any time in Settings > Privacy.
There is no account, no sign-in and no analytics of our own.
On Android the app can show one small banner ad, served by Google AdMob. It appears on the recipe screen, in cook mode, while a recipe is importing and at the top of the review screen of a recipe you have just imported, not on the Library. You can remove ads for good with a one-time purchase through Google Play. The app tells you, before any ad code contacts Google, what ads send, and asks whether you want personalised or non-personalised ads (as a step of the first-run setup; if you have not answered there, the first time the app is ready to show an ad); both are free, and you see the same number and size of banners in the same places either way; only how the ads are chosen differs. Where the law requires it, Google’s consent form follows.
On iPhone and iPad the app shows the same banner in the same places. Ads there are always non-personalised: the app never asks to track you and never receives your device’s advertising identifier. Before any ad code contacts Google, it tells you once what the ads code sends to Google, as a step of the first-run setup or, if you skipped it, the first time the app is ready to show an ad. Where the law requires it, Google’s consent form follows. You can remove ads for good with a one-time purchase through the App Store (see “iPhone and iPad”).
Nutrition estimates are worked out on your phone from a table bundled in the app.
“From photos” imports a recipe from photos of cookbook pages. The text is read on your phone, and the photos and the text never leave it. The app also looks for a QR code on each page: if it holds a web link, the app shows you the website’s name and offers to import from the link instead, and fetches that page only if you choose it. On Android the text reader and the QR-code reader are Google’s ML Kit, built into the app; when it reads a photo, ML Kit sends Google its own diagnostic information about your phone and the app, never the photo, the text or what the code says (see item 8 under “Network requests”). If you do not use “From photos”, nothing is sent. On iPhone and iPad the text and any QR code are read by Apple’s on-device Vision framework and nothing is sent.
The app makes internet requests only for the things listed below.

What stays on your device

Your recipes (title, description, ingredients, steps, notes, times, servings), tags, favourites, shopping list, and the link a recipe came from.
Cover photos: the ones fetched for an imported recipe and any you choose from your gallery. Gallery photos are copied into the app’s own storage and are not uploaded.
Your settings (such as your units choice, the mobile-data download switch, the clipboard check and the nutrition-estimates switch).
Whether you have bought “Remove ads” (a saved yes or no, checked again with Google Play or the App Store).
For a recipe imported from a page that states its own nutrition, the numbers the page stated.
The language model file you download or import.
Backup files you export: they are created on your phone and go only where you choose to send them with your phone’s share menu. A backup holds your recipes, cover photos, tags, shopping lists and pantry, not your settings, so treat it like any private file.
Your phone’s own backup. If you have Google backup (Android) or iCloud Backup (iPhone and iPad) turned on, or you move to a new phone with your phone’s transfer tool, your phone may copy this app’s recipes and their cover photos to your Google or Apple account or to the new phone; on iPhone and iPad it copies the app’s settings too. Your phone makes that copy, not this app. We never receive it and cannot read it. The downloaded reading model, any report waiting to be sent and, on Android, the app’s settings are left out of the backup.
Problem reports waiting to be sent (at most 5, for at most 7 days), and the bug-report file until the next report or app start.
Step timers. When you tap a timer on a recipe step in cook mode, the app hands the length and a label (the recipe title and the step number) to the clock app on your phone, the way sharing hands text to another app. If no clock app can take it, the timer counts down inside cook mode, which keeps the screen on. Nothing is stored or sent.
Your clipboard. When you open the add-recipe screen yourself, the app looks once at what you last copied, on the phone, to offer it for import, and to fill in the box, if it looks like a recipe link or recipe text. It never imports anything by itself, never reads the clipboard at launch, in the background or when something is shared to it, and skips anything another app marked sensitive (such as a password). Nothing is written to storage or sent: text that is not a recipe is discarded at once, and until you close the app it remembers, in memory only, the start of a clip you dismissed or imported, so it does not offer the same one twice. Your phone may show its own “pasted from your clipboard” notice. You can turn the check off in Settings > Importing.
Import notification. While a recipe is importing, the app shows an ongoing notification (“Importing recipe…”) so Android keeps the import running when the screen locks, and a “Recipe ready” notification if it finishes while you are in another app. The notifications are made on your phone, never contain your recipes, and nothing is sent anywhere.
Page photos. “From photos” reads a recipe from photos of cookbook pages, taken with the camera or chosen with the system photo picker. The photos are copied into the app’s private temporary storage only for that import and are deleted when the import is saved, cancelled or left; if the app closed mid-import, they are deleted the next time it starts. A photo you take in the app is not added to your gallery. If you choose “Use a page photo” for the recipe’s cover, that one photo is kept with the recipe, like any other cover photo. When it reads the photos, the app also looks for a QR code in each of them, using ML Kit barcode scanning built into the app on Android and Apple’s on-device Vision framework on iPhone and iPad. This works offline: the photo and what the code says stay on your phone. If a page’s QR code holds a web link, the app shows you the website’s name and offers to import from it (“Import from the link”), with “Read the page instead” as the other choice. It does this only if you choose it, and then it fetches that page the same way as a link you pasted (item 1 under “Network requests”), so that website can see the request; until you choose, nothing is fetched. The app never opens a link from a QR code in your browser. If the pages hold no QR code, several different links, or a code that is not a web link, the app simply reads the text. The photos, the text read from them and what a QR code says are never sent to us or anyone else and are never in a problem report or bug report.

Reading a recipe with the language model happens on your phone. The text you paste, the text read from a page, or the text read from your photos, is not sent to us or to any remote model.

On an iPhone or iPad with Apple Intelligence turned on (iOS 26 or later), the app reads recipes with Apple’s built-in on-device model instead of a downloaded model file, so no download is needed; Settings shows “Recipe reader: built into this device” when it is in use. The app hands that model the same text (the text you pasted, read from a page or video captions, or read from your photos) with its reading instructions. Apple’s model runs on your device only: the app never asks for Apple’s cloud processing (Private Cloud Compute) and sends nothing to Apple or to us for this. If Apple Intelligence is off or your device does not have it, the app uses a downloaded model as described above.

On Android the app reads recipes with a downloaded model file today. A coming version will, on phones that have Google’s built-in model (Gemini Nano, run by Android’s AICore service), be able to read recipes with it instead, so no download is needed. The text stays on your phone; what Google’s code in that version sends Google is described in item 9 under “Network requests”. Until that version is released, Android always uses a downloaded model.

Network requests the app makes, and why

The app contacts the internet only in these cases.

A link you import (web page or YouTube). The app requests the address you gave it, from the site that address belongs to; a link read from a QR code on a page photo is requested in the same way, and only after you tap “Import from the link” (see “Page photos” under “What stays on your device”). That site receives the request and your phone’s IP address, as with any browser. For a web page, the app names itself in the request (a fixed string, “RecipePassport/1.2 (Android)” with a link to this page, on every version and platform), so the site can see which app is asking; for a YouTube video’s page, for YouTube’s caption requests (item 2) and for cover images (item 3), it sends a mobile-browser identification string, because YouTube does not serve its pages to an app that names itself. If a video’s description (or the channel owner’s comment) links to a recipe on another site, the app requests that address straight away, in the same way, and imports that page instead of the video; if that page gives no recipe, it reads the video. On the review screen, “Use the video instead” switches back to the video. The app does not send your name, an account, a device or advertising ID, or any recipe from your library. For an Instagram or Facebook link the app makes no request at all: those pages need a sign-in, so the app asks you to paste the caption and keeps the link with the recipe. A TikTok or Pinterest link is handled the same way. The app never uses an unencrypted connection: a link that starts with http (not https) is requested over https at the same address instead, and if the site does not answer that way the import fails rather than fetching anything without encryption.
YouTube captions. For a YouTube link the app also asks www.youtube.com (and m.youtube.com if the link uses it) for the video’s captions: the watch page, YouTube’s player and transcript endpoints, and the caption file. These requests carry the video’s identifier and a client name and version. No login and no key. These are YouTube’s own web endpoints, which are not an official programme for apps, and they may stop working.
Cover images. The app downloads a cover image from i.ytimg.com for a YouTube video, or from the address the page names for its image. It does this when you review an imported recipe (to show you the photo) and when you save it, when you open a recipe that has an image address but no stored photo (once per visit), when you open a recipe someone shared with you as a Recipe Passport link, and when you restore a backup (it fetches missing covers again). Image addresses that start with http are not loaded either. The server that hosts the image sees the request and your IP address.
The model download. When you tap Download, the app fetches the model file from Hugging Face (huggingface.co), which redirects to its content network. The file is about 1.1 GB or 2.5 GB. On Android the download is handled by Android’s own download manager, which keeps it going while the screen is locked or the app is in the background and shows its normal download notification; on iPhone and iPad the app downloads the file itself and resumes it if it is interrupted. It waits for Wi-Fi unless you turn on “Download models on mobile data”. The app checks the finished file’s exact size and file header on your phone before using it. The app sends no identifier of yours. Hugging Face and its network will see your IP address and the request.
Ads and purchases. See “Ads”, “Consent and privacy options” and “Purchases” below. Those requests go to Google (ads, and purchases on Android) or Apple (purchases on iPhone and iPad), not to us.
Problem reports. Only if automatic error reports are on (Settings > Privacy), or you tapped Send on a report: one encrypted (HTTPS) request to our report service, rp-reports.bouncebackstudios.workers.dev, carrying the report described in “Problem reports” below. A report that cannot be sent right away waits on your phone (at most 5, for at most 7 days) and is sent the next time the app is opened or brought back to the screen with a connection, or when the connection comes back.
A Recipe Passport recipe link. A recipe shared as a bouncebackstudios.app/r/#… or recipepassport:// link carries the recipe inside the link itself. If you open or paste one, the app reads it on your phone and opens the review screen; it makes no request to us for it, and the part of the link after # is never sent to any server. The only request is for the recipe’s cover image, from the source the link names, as an import does (item 3).
Text-recognition and QR-code diagnostics (Android only). On Android, “From photos” reads the text on your page photos with Google’s ML Kit text recognition, and looks for a QR code on them with ML Kit barcode scanning; both are built into the app and work offline: the photos, the text read from them and what a QR code says never leave your phone. When it reads a photo, ML Kit itself reports to Google. Google’s data disclosure for ML Kit (developers.google.com/ml-kit/android-data-disclosure) lists what it sends, the same for text recognition and for barcode scanning: information about your phone (manufacturer, model, operating system version and build, and its machine-learning hardware); the app’s package name and version; an identifier for this installation of the app, which Google says is not meant to identify you or your phone; performance figures such as how long a read took; settings such as the image format and size; the size of the input and output; the reader’s version; what happened, and any error codes. Google uses it for diagnostics and usage statistics, sends it encrypted (HTTPS) and says it does not pass it to third parties; it does not say how long it keeps it. It is sent only when a photo is read: if you do not use “From photos”, nothing is sent. We do not receive this data; Google handles it under its own privacy policy (policies.google.com/privacy). On iPhone and iPad the text and any QR code are read by Apple’s on-device Vision framework and nothing is sent.
The built-in reader (Android, a coming version). Today every Android version of the app reads recipes with a downloaded model file (item 4). A coming version will, on phones that have Google’s built-in model, Gemini Nano, offer to use it instead, through Android’s AICore system service and Google’s ML Kit GenAI code built into the app. Until that version is released, nothing in this item applies. When it does: the app hands the model the same text as any other reader (the text you pasted, read from a page or video captions, or read from your photos) with its reading instructions, and the model answers on your phone. Google says ML Kit processes that text on the device and does not send it, or the model’s answer, to Google’s servers, and that AICore keeps no record of either after a request. If the model is not yet on the phone, AICore downloads it from Google when you choose the built-in reader; that download is made by Android’s Private Compute Services, not by the app. As with the text reader (item 8), Google’s ML Kit code sends Google its own diagnostic and usage information when the built-in reader is used, never the recipe text or the answer, and may contact Google from time to time for updates to itself. For its GenAI features Google’s data disclosure (developers.google.com/ml-kit/android-data-disclosure) lists: information about your phone (manufacturer, model, operating system version and build, and its machine-learning hardware); the app’s package name and version; “user, device or other identifiers” and an identifier for this installation of the app, for diagnostics and usage statistics (Google does not say which identifiers); performance figures such as how long a read took; the size of the input and output; the configured languages; the feature’s version; what happened (such as a model download or a read), and any error codes. Google sends it encrypted (HTTPS), says it does not pass it to third parties, and does not say how long it keeps it. We do not receive it; Google handles it under its own privacy policy (policies.google.com/privacy). If you keep using a downloaded reader, nothing is sent. This item will be updated, and the change noted in the app’s “What’s new”, when that version is released.

We do not control what those sites do with the requests they receive. See their own privacy policies.

The app does not request anything else. It reads your phone’s connection type (Wi-Fi or mobile data) locally to choose when to resume a download; that check sends nothing.

Opening a recipe’s source link hands the address to your browser or another app. What happens next is governed by that app.

Accounts and analytics

No accounts.
No analytics and no tracking tools of our own. Problem reports (below) are sent only with automatic error reports on, or when you tap Send. The app adds no name, email address, account, or device or advertising identifier to them; a note you type is sent as written, so leave personal details out. Google’s ads code and, on Android when you read a photo, its ML Kit text-recognition and barcode-scanning code send Google their own diagnostic information, described under “Ads” and in item 8 under “Network requests”.
Google Play and Apple may show us aggregated install, crash and performance statistics from users who have chosen to share them with Google or Apple. Those numbers are not linked to you by us.

On Android the app shows at most one small banner at a time, served by Google AdMob: at the bottom of a recipe, at the top of cook mode, at the top of the importing screens (one recipe, or a batch) while recipes are being read, and at the top of the review screen of a recipe you have just imported or opened from a Recipe Passport link, before you save it (it scrolls away with the recipe and is hidden while the keyboard is open). There are no ads on the Library, when you edit a saved recipe or type a new one, in the first-run setup, the model download or Settings, and no pop-up, video or app-open ads. If you buy “Remove ads”, the app stops loading the ads code on your phone.

To show an ad, the Google Mobile Ads SDK in the app contacts Google. According to Google’s page for the Google Mobile Ads SDK (https://developers.google.com/admob/android/privacy/play-data-disclosure, read on 17 October 2026, describing SDK version 25.5.0; this app ships version 25.4.0), the SDK collects and shares, for advertising, analytics and fraud prevention:

your IP address (which may be used to estimate your general location);
how you interact with the ad and the app’s ad requests (such as app launches and taps);
diagnostic information (such as app launch time, hang rate and energy use);
device and account identifiers: your Android advertising ID and an app set ID.

Data is encrypted in transit. On Android, if you chose “Personalised ads”, Google may use this data to show ads that suit you, within what you agreed to in Google’s consent form where one applies. If you chose “Non-personalised ads”, the app asks Google for non-personalised ads only: they are chosen from what kind of app this is and your approximate area (from your IP address), not your interests, and Google still receives the data above to count views, limit repeats and prevent fraud. The app does not tag ad requests as child-directed. We do not receive this data and cannot see which ads you were shown. Google handles it under its own policies (https://policies.google.com/technologies/partner-sites). No recipe, ingredient, import link or text, or bug report is ever given to the ads code.

Your advertising ID. It is an Android setting, not ours. You can reset it or delete it in Android Settings (Settings > Privacy > Ads, wording varies by phone and Android version) and you can opt out of ad personalisation there. If you delete it, the ads code can no longer use it.

On iPhone and iPad the banners are in the same places and the ads code is the Google Mobile Ads SDK for iOS. The app asks Google for non-personalised ads only, and it never shows Apple’s “Allow to track” prompt, so the ads code cannot read your device’s advertising identifier (IDFA). According to Google’s App Store data disclosure for the SDK (https://developers.google.com/admob/ios/privacy/data-disclosure, read on 5 November 2026, describing SDK version 13.12.0; this app ships version 13.6.0), the SDK may collect: crash logs (not tied to you) and performance data such as app launch time, hang rate and energy use, used to diagnose problems, for analytics and for advertising; a device identifier, meaning an identifier Apple gives our apps on your device (the same in all Bounceback Studios apps; other companies’ apps get a different one); which ads you were shown; your approximate location worked out from your IP address; and how you interact with ads and the app’s ad requests. Google uses this to show, count and measure ads and to prevent fraud. Ads are chosen from what kind of app this is and your approximate area, not your interests. We do not receive this data and cannot see which ads you were shown.

The ads notice. It tells you once what ads send to Google and, on Android, offers two free choices: “Personalised ads” or “Non-personalised ads”. It is a step of the first-run setup, after Region; if you have not answered there (you tapped Skip), it appears the first time the app is ready to show an ad. Skipping is not a choice: until you answer, no ad loads. Until you choose, the ads code does not contact Google at all (it does not start by itself when the app opens). You can change your choice at any time in Settings > About and support > Ads and your data. Separately, the notice shown at an ad (not the setup step) offers “Remove ads”, the one-time purchase, when the store (Google Play, or the App Store on iPhone and iPad) can sell it; if you tap it and do not buy, no ad loads then and the app asks again next time. If you bought “Remove ads”, no ad loads and the notice at an ad never appears.

After either answer in the ads notice, where the law requires it (the EEA, the UK and Switzerland, and US states where Google shows a privacy choices form), Google’s User Messaging Platform shows its consent form the first time the app is ready to show an ad, after the first-run setup. If you chose “Non-personalised ads”, ads stay non-personalised whatever you answer on Google’s form. Ads load only if consent allows. Where a privacy choices form is required, Settings > About and support shows an “Ad privacy choices” row that reopens it, so you can change your answer at any time. The form and your answer are handled by Google’s consent SDK on your phone.

On iPhone and iPad the ads notice (in the first-run setup, or at the first ad if you skipped it) has a single “OK”, because ads there are always non-personalised; until you tap it, the ads code does not contact Google. Google’s consent form and the “Ad privacy choices” row work as described above.

Purchases

“Remove ads” is a one-time purchase handled entirely by Google Play. We never see your card or payment details, name or Google account. The app asks Google Play whether this Google account owns the purchase, saves the yes or no on your phone, and checks again from time to time. “Restore purchases”, on the Remove ads screen in Settings, asks Google Play again. There is no subscription.

On iPhone and iPad, “Remove ads” is a one-time in-app purchase handled entirely by Apple’s App Store. We never see your card or payment details, name or Apple Account. The app asks the App Store whether your Apple Account owns the purchase, saves the yes or no on your device, and checks again from time to time. “Restore purchases” asks the App Store again and may ask you to sign in to your Apple Account.

Nutrition estimates

The estimates are calculated on your phone from an ingredient table bundled in the app, built from the United States Department of Agriculture’s FoodData Central (public domain). Nothing is looked up online and your recipes are not sent anywhere for this. The estimates are not medical advice (see the About nutrition estimates screen in the app). You can turn them off in Settings.

Permissions

On Android the app asks for these permissions:

Internet, to make the requests listed above.
Network state and Wi-Fi state, to see whether you are on Wi-Fi or mobile data so a model download can wait for Wi-Fi. Nothing is sent.
Vibrate, for small touch feedback.
Set alarm (com.android.alarm.permission.SET_ALARM), so a timer you start on a recipe step can be handed to your clock app. Android grants it at install without asking; the app uses it only when you tap a timer.
Billing (com.android.vending.BILLING), so Google Play can complete the “Remove ads” purchase.
Advertising ID (com.google.android.gms.permission.AD_ID), which the ads code reads to request ads; see “Ads” above.
Ad services (android.permission.ACCESS_ADSERVICES_AD_ID, ACCESS_ADSERVICES_ATTRIBUTION, ACCESS_ADSERVICES_TOPICS), added by Google’s ads code so it can use Android’s advertising services where the phone has them.
Notifications (POST_NOTIFICATIONS), asked the first time you import; you can say no and imports still work, without the notifications.
Camera (CAMERA), asked the first time you tap “Take a photo” in “From photos” and used only to photograph recipe pages. You can say no and choose photos instead. The camera is optional, so phones without one can still install the app.
Run in the foreground while importing and keep the phone awake (FOREGROUND_SERVICE, FOREGROUND_SERVICE_DATA_SYNC, WAKE_LOCK), used only while an import you started is running, so it carries on if the screen locks or you switch apps. The ads and billing libraries also declare wake lock and foreground service for their own background work.

It has no microphone, location, contacts, storage or biometric permission. The app picks cover photos and page photos with the system photo picker, which gives it only the photos you choose.

iPhone and iPad

The iPhone and iPad version is the same app with these differences. It shows ads and offers “Remove ads” as described under “Ads”, “Consent and privacy options” and “Purchases”: ads are always non-personalised and the app never asks to track you. The Android permissions list does not apply. The model download is made by the app itself, as described above. Sharing a link or text to the app from another app goes through an iOS share extension that passes it to the app on your device and sends nothing anywhere. Backups and shared recipes go through the iOS share sheet. Choosing a cover photo, or page photos for “From photos”, uses the system photo picker, which gives the app only the photos you choose. In “From photos” the text is read, and any QR code on a page found, by Apple’s on-device Vision framework, and nothing is sent anywhere; a link from a QR code is fetched only if you choose “Import from the link”, as described under “Page photos”; the camera is used only when you tap “Take a photo”, and iOS asks for permission then. A photo you take is not added to your photo library. With Apple Intelligence turned on, recipes are read by Apple’s built-in on-device model and no model download is needed (see “What stays on your device”). Bug reports go by your own mail app, as below; in a build without the report service address, the automatic reports, the setup box and Settings > Privacy do not exist.

What iOS may keep after you delete the app. On iPhone and iPad the app stores its small settings in the iOS Keychain, and iOS can keep Keychain items after an app is deleted. What may remain is: your settings (region, units, the mobile-data download switch, the clipboard check, the nutrition, appearance and library-sort choices, the name of your model file, and which version’s “What’s new” you have seen); whether setup and the tour were finished; your answers to the ads notice and to the “Send error reports automatically” box; the saved yes or no for “Remove ads”; and the figures Settings > Diagnostics shows: the last five reads (time, model file name, whether it worked, how long each step took and token speeds), the kind of the last import and share (type and size, never the text) and frame timings. It can also hold the link or text of one import that was waiting for the reader download, or was running when the app closed, until that import runs. Your recipes, photos and the model file are deleted with the app. These items stay on your device and we never receive them, except that the Diagnostics figures go into a bug report or problem report when one is sent (see “Bug reports” and “Problem reports”); the only copy outside your device is in your phone’s own backup, if you have one. Version 1.5.0 left these items in place; later versions delete them the first time it starts after being deleted and installed again. There is no reset button for them in the app: to clear them, delete the app and install it again.

Problem reports

The app can send us a short report when something goes wrong, so we can fix imports.

When. In a build without the report service address, none of this exists. The last step of setup has a “Send error reports automatically” box, ticked unless you untick it (it starts unticked if the country setup shows is in the European Economic Area, the United Kingdom or Switzerland; you can change the country) and saved when you leave setup or change it, with a “What’s sent” link to Settings > Privacy. With it on, an automatic report is sent when an import fails. With it off, the app offers “Send a problem report” each time instead and sends only if you tap it. If you never answered, you are not opted in: the app asks each time. You can also tap “Report a problem with this recipe” at the bottom of any recipe. You can change this any time in Settings > Privacy > Send error reports automatically; turning it off also deletes, unsent, any automatic report still waiting on your phone.
Automatic reports are smaller. A report sent automatically contains everything listed below except the link you imported, a recipe and a note; links in the error message are removed too. After an automatic report the app offers “Send the link too”, which sends the full report only if you tap it.
What a report contains. A random report id (new for every report); the time the report was made; the app version; your phone’s operating system and version, model, and how much RAM (working memory) it has, rounded to a whole gigabyte (for example 8 GB; no files or photos on your phone are read); which reader is installed (Fast or Best, or “custom” and its size for a model file you imported; never its file name); how fast the reader ran (the size of the text it was given, in tokens, and tokens per second); how long each step of the import took and where it stopped; the error code and message, shortened; the kind of source (for example YouTube, a web page, Instagram or pasted text); and the link you imported, cleaned so only the site and page path remain (for a YouTube video, only the video id; other parts of the address such as share or tracking codes are removed first). A report you send about a recipe also contains that recipe as saved (title, servings, ingredients, method and nutrition) and the note you typed, if any. It never contains the page or transcript the app read, the text read from your photos, your other recipes, your photos or your location. The app adds no name, email address, account, or device or advertising identifier; a note you type is sent as written, so leave personal details out of it. You can see exactly what will be sent with “See what’s sent” before sending.
Where it goes. To a small service we run on Cloudflare (Cloudflare processes it on our behalf), which stores it and emails it to us. The service does not store your IP address; it uses it only, in a one-way hashed form, keyed with a secret only the service holds, that changes daily, to limit how many reports one phone can send.
What we do with it. We use it only to find and fix problems with imports and recipes. We do not share or sell it, and do not use it for advertising.
How long we keep it. Reports are deleted automatically after 90 days. The emailed copy is kept with our support emails (see “How long we keep things”).
Deleting a report. After sending, the app shows the report id. Email support@bouncebackstudios.app with that id and we will delete the report.

Bug reports

The app has a “Report a bug” screen (Settings > About and support > Report a bug). The same screen is offered from a recipe you have just imported (“Something wrong? Send this recipe to the developer”) and when an import fails (“Send this to the developer”, or “Email the developer instead” next to a problem report). This screen is separate from problem reports: it builds a fuller report that you send yourself, from your own mail app.

This screen sends nothing automatically. The app builds a small file, bug-report.json, on your phone and shows you its exact contents before anything happens. You then tap one button: “Email the report” opens your own mail app with the file attached, “Share the file” uses your phone’s share menu, and “Copy report” copies the text. The app itself makes no network request for this; your mail app sends the message, and only if you press send there.
The link and the source text are part of your report. If you leave “The link” ticked, or turn “The source text” on, they go in the file like the message you typed, and we treat them the same way: as content you chose to send us about one import. You see them in the preview first. Nothing is sent until you tap a button on that screen and then send the message in your mail app; the app never sends a report by itself.
Corrections. After you correct a recipe you imported, the app may offer to send us your correction so the reader can improve. The report contains the lines you changed (before and after, up to 30 lines, each cut to 160 characters), the kind of source and, if you leave them ticked, the link and the device and model info; it does not contain the whole recipe or the source text. You see it before you send it from your own mail app; nothing is sent automatically. “Don’t ask again” stops the offer.
What the file can contain. Always: what you typed in the “What went wrong?” box, a short report code, the date and time, and the app’s version; for a report about an import, also the kind of source (web page, video, pasted text or caption), whether the import finished, and the error message the app showed if it failed. If you leave them ticked: “The link” you imported; “The recipe as imported” (title, description, ingredients, steps, servings, times, units); “Device and model info” (operating system version, phone model and maker, total memory, the model file’s name, and how long each part of the import took). Only if you turn it on: “The source text”, meaning the text the app read (the page text, video transcript or caption, up to 100,000 characters); the text read from your photos is never included, and the option is not offered for a photo import. It never contains your other recipes, your photos, a device identifier or an advertising id.
What we receive. The email goes to bugs@bouncebackstudios.app. We therefore receive your email address, anything your mail app adds to a message (such as your name), and the file. The app itself never reads or sends your email address: your mail app adds it when you press send. Problem reports carry no email address at all.
What we do with it. We use it only to find and fix the problem, and we may reply to you about it. We do not share or sell it, and we do not use it for advertising. We keep the message and the file as our record of the bugs reported and the support given, for as long as the app is available (see “How long we keep things”); ask us and we will delete them, unless we need them for a legal claim or the law requires us to keep them.
Copies outside our control. A copy stays in your mail app’s sent folder, or with whichever app you shared the file to. The file also sits in the app’s temporary storage on your phone until you start another report or next open the app, when it is removed.

To have a bug report deleted, write to support@bouncebackstudios.app from the address you sent it from.

Children

The app is meant for people aged 18 and over. It is not directed at children, and we do not knowingly collect personal information from anyone under 18. It does not collect personal information on its own; the only personal information we can receive is in a bug report someone chooses to send. The app adds no name, email address, account, or device or advertising identifier to a problem report; a note you type is sent as written, so leave personal details out. Ad requests are not tagged as child-directed. On Android they may be personalised if you chose “Personalised ads”, as described under “Ads”; on iPhone and iPad they are always non-personalised. If you think a child has sent us personal information, email us and we will delete it.

How long we keep things

Your recipes, their cover photos (including a page photo you chose as a cover), the app’s settings and the model file: on your phone, until you delete them or uninstall (on iPhone and iPad, iOS may keep the settings after the app is deleted; see “iPhone and iPad”). Page photos for an import in progress: in the app’s temporary storage until the import is saved, cancelled or left, or the next app start. Your phone’s own backup, if you have one, may hold copies of the recipes and their cover photos (and, on iPhone and iPad, the app’s settings).
Problem reports: 90 days on our report service, then deleted automatically; the emailed copy with our support emails, below.
We keep bug reports, problem-report emails and other emails you send us as our record of the bugs reported and the support given, so we can see what we told you if the problem comes back, for as long as the app is available. If you ask us to delete yours sooner, we will, unless we need it for a legal claim or the law requires us to keep it.
Ad, purchase and (on Android) text-recognition and barcode-scanning diagnostic data held by Google: under Google’s own policies; we hold none of it.

Your rights, and the laws that apply

We are based in Australia. We follow the Australian Privacy Principles in the Privacy Act 1988 for the personal information we handle. If you are unhappy with how we have handled your information, email us first; you can also complain to the Office of the Australian Information Commissioner (oaic.gov.au).

Overseas recipients. Some of the data described in this policy goes to companies based in the United States: Google (the data the ads code sends, described under “Ads”, and, on Android when you use “From photos”, the text-recognition and QR-code diagnostics in item 8 under “Network requests”); Cloudflare (problem reports, which it processes for us, as described under “Problem reports”); and Hugging Face (your IP address and the request when you download a model, item 4 under “Network requests”). A “Remove ads” purchase is handled by Google Play or Apple’s App Store, both based in the United States, as described under “Purchases”. The sites you import from, wherever they are, see the request and your IP address, as with any browser. We send none of this ourselves: each of these goes straight from your phone, and the ways to limit or avoid each are described in those sections.

If you are in the European Economic Area, the United Kingdom or Switzerland: automatic problem reports are sent only while the “Send error reports automatically” box is on. It starts unticked for you and is on only if you tick it, which is your consent; you can withdraw it at any time by turning it off in Settings > Privacy, as easily as you gave it. Withdrawing does not undo a report already sent; to have one deleted, see “How to delete your data”. A problem report you choose to send and a bug report are handled on the basis of our legitimate interest, which you can object to by not sending one; a report never identifies you unless you put personal details in a note or send it by email. Ads load only after you choose in the ads notice and with the consent you give through Google’s form, which you can withdraw at any time through “Ad privacy choices” in Settings > About and support; you can also switch to non-personalised ads in Settings > About and support > Ads and your data. On iPhone and iPad ads are always non-personalised; the ads code still stores and reads information on your device and sends it to Google only with the consent you give through Google’s form, which you can withdraw the same way. On Android, when you use “From photos”, Google’s ML Kit text-recognition and barcode-scanning code sends Google the diagnostic information listed in item 8 under “Network requests”; Google receives it directly, as the provider of that code, and the only way not to send it is not to use that feature. You have the right to ask what personal data we hold about you, to have it corrected or deleted, to object to or restrict how we use it, and to complain to your data protection authority. Email us to use these rights. We will answer within a month; if a request is complex we may need up to two months more, and we will tell you within the first month if so. If we decide not to act on a request, we will tell you why within the month. Google (ads, consent, Google Play and, on Android, text-recognition and QR-code diagnostics), Cloudflare (our report service and website) and Hugging Face (the model download) are based in the United States and publish their own safeguards for data sent to them.

If you live in a US state with a privacy law such as California’s, you can use the same rights by email. We do not sell your personal information ourselves. If you chose “Personalised ads”, the ads library may send your device’s advertising ID to Google for personalised ads, which some US state laws call “sharing” or “selling”; you can opt out for free by choosing “Non-personalised ads” in Settings > About and support > Ads and your data, through “Ad privacy choices” where the app shows that row, or by turning off ad personalisation or deleting the advertising ID in Android settings. On iPhone and iPad ads are never personalised and the app never sends an advertising identifier, so nothing is “shared” for cross-context behavioural advertising; Google still receives your IP address and an app-level device identifier to serve, count and measure ads; Google shows the ads and pays us a share of the ad income. Where your state’s law treats that as a “sale”, the “Ad privacy choices” row in Settings > About and support lets you opt out for free. We do not use your information to profile you.

How to delete your data

Apart from a bug report or problem report you chose to send (see “Bug reports” and “Problem reports”), all of your data is on your phone, and in your phone’s own Google or Apple backup if you have one, which you manage in your phone’s settings. To delete a problem report, email support@bouncebackstudios.app with the report id the app showed; reports are also deleted automatically after 90 days. To delete a bug report or other email, write from the address you sent it from. You can delete a recipe in the app, remove the language model in Settings (Remove model), or uninstall the app to remove everything (on iPhone and iPad, iOS may keep the app’s small settings after that; see “iPhone and iPad” for what they are and how to clear them). We never receive or hold the data the ads library collects, or the diagnostic data Google’s text-recognition and barcode-scanning code sends on Android, so we cannot delete either ourselves. Google collects it directly from your phone and decides how it is used; Google shows the ads and pays us a share of the ad income. To have it deleted, use Google’s controls at myadcenter.google.com and policies.google.com/privacy, and reset or delete your advertising ID in Android settings, which breaks the link to past ad data. On iPhone and iPad the ads code never has your advertising identifier; the identifier it uses is reset once you have deleted all Bounceback Studios apps from the device. If you are in the EEA or UK and want help with a request to Google, email us. A backup file you exported is a normal file outside the app: delete it yourself, and delete copies you sent elsewhere.

We hold no copy of the data in the app, apart from reports and emails you sent us, and cannot delete it for you. Sites you imported from keep whatever logs they keep.

Changes to this policy

This policy describes the current version of the app. If it changes, the new policy will be published at the same address with a new date at the top, and the change will be listed, with the date, the app version it applies from and the full text of the earlier version, at https://bouncebackstudios.app/recipe-passport/privacy/changes/. A change that affects what data leaves your phone will also be mentioned in the app’s “What’s new” text before that version is released.

Contact

Bounceback Studios (ABN 24 362 033 828), support@bouncebackstudios.app

This policy is published at https://bouncebackstudios.app/recipe-passport/privacy.