Privacy Policy

Who we are

UrCartBuddy is operated by Binary Components Limited, a company registered in England and Wales (company number 05837146), registered office 79 Goldhawk Road, London, W12 8EG (privacy@urcartbuddy.com). Binary Components Limited is the data controller for personal data processed through this service.

What data we collect and why

Account data

When you sign in with Google or Facebook we receive your name, email address, and profile picture. If you register with an email address and password instead, we store your email address and a securely hashed password — your password is never stored in plain text. We store these to identify your account and personalise your experience. Your account creation date, current subscription tier, and interface preferences such as whether help tips are shown, which help tips you have dismissed, and whether you wish to receive Telegram notifications when collaborators check off items you added, are also stored. We also record the date and time you last used the app on the web or messaged our WhatsApp or Telegram bot, so we can maintain the service and understand overall usage.

Shopping lists and items

We store the lists, items, tags, and categories you create. Each item records who added it, who checked it off, and when — so collaborators can see activity on shared lists. Items may also store an optional description — free-text notes, substitution preferences, or sizes — that you enter manually. Items created from image imports may also store package weight and QR/barcode metadata when detected, so richer item viewing and editing can be supported later. Lists may also store an optional description you enter, including any web address you put in it; everyone with access to the shared list can read it. Lists may also store an optional source URL and title, such as the original recipe page used to create a recipe shopping list, and per-list field display preferences (which optional item fields such as Brand and Weight are visible on that list).

Item attachments

You can attach files (photos, PDFs, receipts, or any other format) to items from the web app, or by sending a document or photo to our WhatsApp or Telegram bot or to in-app Chat. A photo you send the assistant is kept as an attachment on the item it creates; if the turn creates no item, the photo is deleted. Attached files are stored on Cloudflare R2 object storage and are viewable by every member of the list the item belongs to. Files are subject to a per-user storage quota and a per-file size limit. When an item is archived, its attachments are scheduled for permanent deletion after a short grace period; deleting an attachment from an item removes it immediately.

When the "AI attachment titles" feature is enabled for a list (enabled by default), the contents of newly uploaded attachments up to 15 MB are sent to Google Vertex AI (Gemini) solely to generate a short descriptive title. File contents are not retained by us beyond the AI request. You can disable this at any time per list under List Settings → AI → AI attachment titles.

Collaboration data

When you share a list, we store the membership relationship (your user ID, the list, your role, and when you joined) so that collaborators can access the shared list.

First-party product analytics

To understand whether the service is useful, we record the UTC days on which an authenticated account meaningfully uses the web app, in-app Chat, or Telegram bot, and a small fixed set of home-screen install prompt outcomes. These records contain an internal user ID, date/time, channel, and fixed event name only. They do not contain shopping-list or item content, messages, contact details, IP addresses, location, referrers, or browser user-agent strings. We use no third-party analytics or advertising identifiers. Administrators see aggregate adoption and retention results, not individual behavioural timelines.

Diagnostic error and crash reports

Web app. When the web app runs into an unexpected error, it may send us a short diagnostic report so we can find and fix the fault. A report contains only a one-off event identifier, a fingerprint used to recognise repeats of the same fault, which general area of the app you were in, which part of the app noticed the error, the app build, whether the browser was online, whether you are using the installed home-screen app, when it happened, and a standard error type name such as "TypeError". It never contains error messages, web addresses, stack traces, or any of your shopping-list or item content. Reports are rate-limited, and repeats of a fault we have already seen are discarded.

Android app. If the Android app closes unexpectedly, it saves a technical report on your device. Nothing is sent until you choose to send it: the next time you open the app, a card asks, and you can see exactly what the report contains before deciding. You can send it, delete it, or tick a box to send future reports automatically without being asked — a choice you can withdraw, and which is cleared when you sign out. A report you do not answer is deleted after seven days, and a report is never sent from an account other than the one that was signed in when the fault happened.

An Android report contains the app version and build, your Android version and API level, your device manufacturer and model (for example "samsung SM-S938B"), the processor type, whether the app was a test build, the app's language setting, your system font size and screen orientation, which screen you were on and which operation was running (for example "reorder" and "reorder.move"), whether the device was online, when it happened and roughly how long the app had been open, the technical type of the fault (for example "InvalidOperationException"), and the names of methods in our own program code that were running at the time. It never contains error messages, web addresses, or anything from your lists, items, notes or attachments. Because it is sent over your signed-in connection, it is associated with your account.

So that we can tell which account hit the problem — and answer you if you contact us about it — an accepted report is written to our access-controlled server logs alongside your internal user ID, your account email address, and the same reference the app shows you. These entries are kept for up to 30 days (see "Data retention") and are used only to diagnose faults: never for analytics, profiling, advertising, or any automated decision about you.

When you invite someone, we store the invited email address or phone number, the inviting account and list, delivery method and status, attempt timestamps, expiry, and a masked form for display to the list owner. Invitation links are single-use and expire after seven days. We store a cryptographic hash for lookup and a protected copy solely so the background delivery service can include the link in the invitation message; raw invitation tokens are omitted from access logs. Restricted nginx error logs can contain request URLs, including private invitation or import links and referrers, when a request fails or exceeds a limit; these logs are kept for up to 30 days for security and fault diagnosis. Email invitations may be sent to people who do not yet have an account.

When you share a list to a phone number that doesn't yet belong to a UrCartBuddy account, we create a placeholder record for that number to reserve access until the person links it to an account. The person signs in and explicitly confirms the private handoff link sent to that number. The confirmation identifies the signed-in account and the masked phone number, then links the placeholder's current list memberships and history to that account and removes the placeholder. We record the date and time of phone verification. A number previously typed into Profile remains unverified and is not used to route shared-list invitations. If the handoff link is lost or expired, the list owner can send an email invitation instead.

If the access that placeholder record was created for is withdrawn instead — the owner removes it from the list, revokes the invitation, or the invitation expires unused — we remove the phone number and everything else in that record that identifies or can reach the person. A record that was never used for anything is deleted outright. If items or attachments it added are still on someone else's list (including items already archived into that list's purchase history), we cannot delete the record without deleting that person's list content along with it, so we reduce it to an unnamed marker instead: the phone number, the phone-derived name and any linked WhatsApp or Telegram identity are removed, those items show "Former member" as who added them, and the record can no longer be signed into, messaged, matched to a phone number, or reused if that number is invited again. Our records of what an AI request cost remain, with the phone number stripped out of them. The invitation's own audit record is retained with the list as described above and is unlinked from the anonymous marker. A daily background check applies the same treatment to any record the immediate cleanup did not reach. The separate WhatsApp send-suppression identifier described below is retained to prevent repeat sends.

Messaging and phone-sharing integrations (optional)

While processing a WhatsApp request, we may send Meta the incoming message identifier to mark it as read. When media input or tool activity requires a text reply, we may also show a typing indicator. Requests that remain eligible for a reaction confirmation do not send this typing signal. For Telegram requests, we send Telegram the existing chat identifier and a typing status. These status signals contain no message content and create no additional stored records.

To let you know when all items added by a WhatsApp message have been archived, we temporarily link the WhatsApp message identifier to the items it created, your account, a keyed identifier derived from your phone number, and the message time. These records contain no message text. They expire after 30 days and are removed by our regular cleanup job, or earlier on account deletion or anonymisation. We may also use a reaction to acknowledge an item add or your cancellation of a pending action. To send any reaction, we give Meta your WhatsApp number, the message identifier being reacted to and the reaction emoji. Archive reactions follow the archive-notification preference in your Profile. We also keep a monthly total of reaction attempts, without customer identifiers or message content, for the current month and twelve completed months to limit automated sends.

If a list owner provides your phone number for a shared-list invitation, we store it to match and verify that invitation. When you use WhatsApp, Meta delivers your phone number, messages, photos, documents or voice notes to us so we can manage the lists you are authorised to use and send confirmations. Content needed for AI interpretation is processed by the AI providers described below, under the list owner's AI allowance. We store content-free WhatsApp reply reservations, send outcomes, monthly estimated costs and keyed identifiers derived from owner email, recipient phone and incoming message identifiers. These enforce the shared owner allowance, prevent duplicate processing and limit quota notices to one per recipient and owner per month. They contain no message or shopping content, survive account deletion to prevent allowance resets, and are retained for the current month plus twelve completed months. These keyed identifiers are pseudonymous, not anonymous. Optional connection requests store a token hash, encrypted phone proof, expected account and expiry. The setup challenge expires after ten minutes; its private confirmation link lasts thirty minutes after receipt. The challenge does not link an account by itself. You must receive a fresh private link on the matching WhatsApp number, sign in, and explicitly confirm the account. Monthly quota links for phone-only members expire after seven days. These new proof records are removed within a month after expiry, or earlier on account deletion or placeholder anonymisation. We do not store raw tokens or log private links. Older handoff proofs retain their existing account-scoped lifecycle; legacy LINK codes remain disabled. Separately, we store a keyed cryptographic identifier derived from the phone number and the time of the handoff attempt. This record contains no raw phone number, account reference, list details or message content. We retain it after account deletion or placeholder cleanup, for as long as the WhatsApp handoff service operates, solely to prevent repeated paid messages and abuse. It can recognise the same number if it contacts us again; it is not an anonymous record. We delete these suppression records when the handoff service is permanently retired. We also keep monthly totals of accepted WhatsApp sends and the first confirmation that a service message was billable, together with records preventing duplicate operational alerts, for the current month and twelve completed months. These records contain no customer identifiers or message content. Aggregate usage warnings are sent privately to the service operator through Telegram. If you connect Telegram, we store your Telegram user ID, chat ID, optional username, and display name so private bot messages can be routed to your account. List invite and Telegram connection QR links use short-lived tokens, and Telegram list invite links may create a minimal account for the invited Telegram user. Message content is processed to manage your lists and is not stored beyond what is needed to fulfil your request. For larger WhatsApp, Telegram or in-app Chat imports (a photo or recipe), we may temporarily store a draft import session containing the proposed item names, quantities, detected package weight or code metadata, target list, and tags so you can review them through a secure magic link before saving. Treat this review link as sensitive. While the draft is open, anyone with the link can see the draft and the names and tags of lists you can edit, change the draft, and save it into one of those lists or a new list in your account. Saving into an existing list requires your current owner or editor access. Reopening a saved, cancelled or expired link shows its status without the draft or your list details. Do not forward it. We also temporarily store the latest pending chat confirmation for your WhatsApp number, Telegram user ID or in-app Chat conversation so replies such as "yes", "no", or "tag with freezer" apply to the correct recent import or action. After a WhatsApp or Telegram item action or import is confirmed, we keep a short list of the item names just added so follow-up replies such as "tag with freezer" or "delete it" apply to the correct items. It can be used for up to 24 hours; a daily cleanup removes the record after it expires. If you have a Telegram account linked, you may also receive an automated Telegram message when a collaborator on a shared list checks off and archives items you originally added. This is controlled by a per-account preference in your Profile and is on by default.

Recipe import (optional)

If you ask UrCartBuddy to find a recipe and import its ingredients, your recipe request is used to search the web, fetch a recipe page, and extract ingredients. We store the resulting shopping items, any recipe tag applied to them, and the source recipe URL/title when attached to an import or list, but we do not store a separate copy of the full recipe page.

Voice commands and dictation (optional)

When you choose to record a voice command, UrCartBuddy temporarily holds the audio in the app's private storage and uploads it to our service so an AI provider can transcribe the words and carry out your list request. Dictation is different: the microphone in a Chat message box only transcribes what you said into the box for you to read, edit and send — it makes no change to any list by itself. Recording begins only after you tap the microphone action and grant microphone permission. The temporary on-device recording is deleted after it is sent, cancelled, or discarded. We do not retain a separate audio recording on our servers after the request. The transcript is used to process the command and may remain briefly in the in-memory conversation context used for follow-up requests; that context expires automatically. Transcripts are not normally written to server logs, but transcript logging can be enabled temporarily by an operator when diagnosing a voice incident.

Push notifications (optional)

If you enable browser push notifications, we store your browser's push subscription endpoint and associated encryption keys in order to send you real-time list updates.

If you use the Android app and turn notifications on, we store the notification token that Google's Firebase Cloud Messaging service issues for that installation of the app, along with the platform name and when it was last seen. That token is an address for the device rather than a name: it does not reveal who you are on its own, but we do link it to your account, and it is used only to deliver updates about lists you are a member of. A notification tells you who made the change and what changed — for example “Sam added: milk, bread” — so item names appear in it, and on your lock screen if your phone is set to show them there. Turning notifications on also lets Firebase create an identifier for that installation of the app; until you do, a new installation collects nothing through Firebase. An app installed before August 2026 may already have obtained that identifier under an earlier version. We remove the token when you sign out on that device, delete your account, or when Firebase reports the installation no longer exists; if we cannot reach the server at the moment you sign out, the app tells you so, and the device may keep receiving that account's notifications until it is next signed in and online. Switching notifications off in Android's own settings stops them being shown, but Android does not tell us, so it does not by itself remove the token — sign out on the device if you want it gone. Notification delivery is governed by Firebase's Privacy and Security information.

Archived items and service improvement

When items are archived, some may be flagged internally as candidates for improving our automatic item-sorting feature. No personal identifiers are used in this process — only the item name text.

AI usage metadata

When an AI feature is used, we store usage metadata linked to the acting account and separate allowance-allocation records linked to the list owners whose monthly limits pay for the request, so we can measure service cost, monitor reliability, and prevent abuse. This includes the source feature, AI provider and model, specific AI interaction type, token counts, timing, success or error status, and related channel or list IDs where relevant. We do not store the prompt text, AI response text, recipe page text, images, or shopping item content in these usage records.

We also store a per-account monthly AI spend cap (an optional override and timestamps for when 90% and 98% warnings were shown each month) so we can enforce monthly limits and pause AI features when exceeded. On a shared list, the owner covers the AI use, even when a member makes the request. Requests involving multiple owners divide their cost among those owners; a member is not shown another person's spending totals. See AI usage limits for details.

Subscription and billing

UrCartBuddy offers a free trial followed by a paid subscription. Current pricing is always shown before you subscribe. Which company processes your payment depends on where you subscribe: purchases made on the website are processed by Stripe, and purchases made inside the Android app are processed by Google Play, as Google requires for purchases made in apps distributed through the Play Store. Whichever you use, the subscription applies to your whole account on every device.

A valid trial or subscription on a list owner's account also covers the members' use of that list. Your own plan is needed to create and use a personal list; shared access remains tied to the owner's coverage and your membership role.

What we store depends on which processor took the payment. For a subscription bought on the website, we store Stripe's customer identifier and subscription identifier. For one bought in the Android app, we store Google's purchase token, the one-way hash of your internal account ID that we send to Google so the purchase can be matched to your account, and the product, offer and billing region Google reports back. For either, we store your subscription status and period dates so we can tell whether your subscription is active. We do not store your card number, bank details, or any other payment instrument — those are held exclusively by the payment processor, and neither processor sends them to us. If you were referred by a partner, we store the referral attribution so the partner can be credited appropriately. Subscription status and period dates are retained until you delete your account.

Contact form

If you use the contact form on our website or in the app, we store your name, email address, message, submission source and timestamps in our database. Authorised administrators use a restricted support inbox to handle your request and may record processing notes and status. Contact records are separate from app accounts, so deleting an account does not automatically delete a support request; you can ask us to erase it using the contact address below. Administrative email and Telegram reminders contain only inbox counts, the oldest received date and a link to the restricted inbox, not your name, email address, message or notes. If we reply by email, that correspondence is delivered through Google Workspace.

Transactional emails are delivered through Google Workspace. To protect email availability, we keep anonymous sending-attempt timestamps for a rolling 24 hours plus a short delivery buffer; they contain no email address, account identifier, subject or message content. Aggregate capacity alerts are sent to our administrator through Telegram, with no user identifiers or email content. We retain one alert state per threshold to prevent repeat alerts.

Server logs

Public website visits and app sign-ups are reported in aggregate. Sign-up counters hold only a date, an allowlisted landing-source label and a count, with no link to an account. These counters are retained for up to 13 months and are not removed on account deletion (see what is kept). Small counts can still permit an inference about a visit; reports are restricted to administrators.

Our servers produce standard application logs (errors, warnings, key events such as sign-ins and account deletions). They are used to operate the service, diagnose technical problems, keep an audit trail of significant account actions, and monitor for security issues, and for producing aggregate visit statistics for our public website. Logs are retained for up to 30 days. Because deleting an account is itself one of those logged events, a log entry naming the deleted account can remain for up to 30 days after the deletion before it expires.

Legal basis for processing (UK GDPR)

• Contract performance — processing your account data, lists, items, and integrations is necessary to provide the service you signed up for.
• Consent — optional features such as WhatsApp, Telegram and push notifications (in the browser and in the Android app) are only activated when you explicitly choose to enable them. Phone-sharing handoffs require a message from the invited number and explicit confirmation in the signed-in account.
• Legitimate interests — server logging, administrator access auditing and security monitoring are necessary to maintain a safe and reliable service, as is keeping refund and chargeback records after account deletion so a referral partner is not credited for money that went back.

Who we share data with

We do not sell your data or share it for advertising purposes. Data is shared only with:

• Stripe — for payment processing when you subscribe on the website. We share your name, email address, and a unique customer identifier. Governed by Stripe's Privacy Policy.
• Google Play — for payment processing when you subscribe inside the Android app, where Google is the seller of record. We send a one-way hash of your internal account ID so the purchase can be matched to your account; we do not send your name or email address. We receive back the subscription's status, expiry date, order identifier, and the billing region Google reports for the purchase (which is not a record of where you were). We receive no card or other payment details. Governed by Google's Privacy Policy.
• Google — for sign-in authentication only. Governed by Google's Privacy Policy.
• Meta (Facebook) — for sign-in authentication and WhatsApp messages, media and secure connection replies (if used). Governed by Meta's Privacy Policy.
• Telegram — for Telegram bot messaging and Telegram list invite links (if enabled). Governed by Telegram's Privacy Policy.
• Google Firebase Cloud Messaging — delivers push notifications to the Android app, if you allow them. Once you turn notifications on, Firebase also creates and maintains an identifier for that installation of the app. What we send it is the device's notification token and the notification's title, message (which names the items that changed) and target list address. Governed by Firebase's Privacy and Security information.
• Oracle Cloud Infrastructure — our hosting provider, where your data is stored on servers located in the United Kingdom or European Economic Area.
• Cloudflare R2 — object storage for any files you attach to items. Cloudflare processes them as our storage provider, storing and serving the file itself, your user ID (in the storage key), and metadata such as filename, size, and content type; we do not use R2 to analyse their contents. Separately, if attachment titling is switched on for a list, the file's contents are sent to Google Gemini to generate a title — see the Google Gemini entry below. Governed by Cloudflare's Privacy Policy.
• Groq — for AI-assisted parsing of shopping items, recipe ingredient extraction, item sorting helpers, and voice transcription when configured. Only the text, image, or audio content needed to fulfil the request is sent; no account identifiers are intentionally included. Governed by Groq's Privacy Policy.
• Google Gemini (via Vertex AI or Google AI Studio) — used for the chat agent loop, AI-assisted item parsing, attachment title generation (when enabled per list), and voice transcription when configured. Only the text, image, file, or audio content needed to fulfil the request is sent; no account identifiers are intentionally included. Governed by Google's Privacy Policy.
• Open Food Facts — used for two things. When a product barcode is detected in an AI, Chat, or Telegram image import, the barcode may be sent to Open Food Facts to look up a product name and package quantity. Separately, to show a product photo beside an item on your list, the item's name may be sent to Open Food Facts to search for a matching product. Only names specific enough to identify a product are sent: single everyday words such as “milk” or “eggs” are answered with a built-in icon and are never sent, and long free-text notes are never sent. The search is made by our server, so your device and IP address are not exposed to Open Food Facts, and the result is stored once and shared by all users rather than being linked to you, your account, or your list. Governed by Open Food Facts' Privacy Policy.
• SearXNG and third-party recipe websites — if you use recipe import, your recipe query is sent through our self-hosted SearXNG instance and the selected recipe page is fetched from the relevant website so ingredients can be extracted.
• Collaborators you invite — users you share a list with can see the list contents and the names of other members.

Data retention

• Your account and the data you create are retained until you delete your account, except where a shorter or longer period is stated below. Deleting your account is immediate and bypasses every grace period described here.
• Items on shared lists are retained until the list owner deletes them.
• Contact messages and processing notes are kept while a request is active, then erased automatically 12 months after it is marked processed, including archived messages. Administrators can erase an archived message sooner. Reopening a request makes it active again. Contact reminder delivery state is kept for 90 days and contains no sender identity or message content.
• A deleted list is kept for 30 days and can be restored by its owner during that time, after which it and everything on it — its items, their attachments and its sharing — are permanently deleted. Other members see the list disappear immediately and cannot restore it; if the owner restores it within the 30 days, their access comes back with it and they are told. The owner can also delete a list permanently straight away instead of waiting. A deleted list’s attachments still count towards your storage until it is permanently deleted. Deleting your account does not wait: lists you had already deleted are destroyed with the rest of your data.
• Leaving a list somebody else shared with you removes your access at once and cannot be undone from your side — only the owner can invite you back. Items you added stay on the list, because they belong to the list rather than to you.
• Attachments are retained for the lifetime of the item they belong to. When an item is archived, its attachments are scheduled for permanent deletion after a short grace period. Deleting an attachment from an item removes it immediately.
• Draft import review sessions expire automatically and are no longer usable after they are saved, cancelled, or expired.
• Pending WhatsApp, Telegram and in-app Chat confirmations are short-lived and are completed, cancelled, superseded, or expired automatically.
• Recent WhatsApp and Telegram item context used for follow-up tagging or removal expires after 24 hours and is removed by daily cleanup.
• WhatsApp message-to-item links for reactions expire after 30 days and are removed by regular cleanup, or earlier when the account is deleted or anonymised.
• Voice recordings are processed for the requested command and are not retained as separate server files after that request. Temporary recordings in the app's private storage are deleted after sending, cancelling, or discarding.
• Photos you send to the assistant from the Android app are copied into the app's private storage only for the length of that request and deleted afterwards. If the app is interrupted mid-capture, the copy is deleted the next time the app starts.
• The Android app's on-device copies — the offline cache of your lists, any data export you have generated but not yet shared, an invitation or phone-handoff link waiting to be opened, and a note of which list you last had open so the app can reopen it — are removed when you sign out on that device or delete your account. A pending phone-handoff link is kept in Android secure storage or the current browser tab's session storage for up to 30 minutes while you sign in, and is cleared on sign-out.
• Android notification tokens are retained until you turn notifications off, sign out on that device, delete your account, or Firebase reports the installation is gone.
• AI usage metadata and allowance-allocation records are retained with the relevant account until deletion unless we introduce a shorter operational retention period. Deleting an actor or owner clears their account link from retained cost records.
• A WhatsApp handoff record is retained with the linked account until account deletion; its raw token expires after seven days and is not stored by our server. The separate keyed send-suppression identifier and attempt time remain while the WhatsApp handoff service operates, including after account deletion.
• Fixed-name product events are retained for no more than 13 months and daily meaningful-activity records for no more than 25 months. Both are removed on account deletion.
• Telegram connection tokens expire after a short time; Telegram list invite tokens expire automatically and are single-use.
• Email and phone list-invitation links expire after seven days and are single-use. Invitation audit/status records remain with the list until it or the inviting account is deleted.
• A placeholder record created by sharing a list to a phone number loses its phone number when that access is withdrawn — removed from the list, revoked, or expired unused. The record is deleted outright unless items or attachments it added are still on someone else's list, in which case it is reduced to an unnamed "Former member" marker that keeps the attribution on those items without naming or identifying anyone. A daily check covers any the immediate cleanup did not reach.
• If a subscription payment is refunded or charged back, we keep a record of that transaction — the payment processor's own transaction identifier, its event identifier, the reason, and when it was recorded — after your account is deleted. That record cannot be deleted without losing the protection it exists for: stopping a referral partner being credited for money that went back. The link to your account is removed when the account is deleted, though in rare cases a refund processed at the same moment as the deletion can leave that link behind.
• Browser push notification subscriptions are removed when you disable notifications in the browser or delete your account.
• Server logs are retained for up to 30 days.
• Administrator access and action audit records are retained for 90 days, including after a target account is deleted. They contain the administrator's verified Google email and identity reference, action, time, outcome, and an internal account, contact message or job reference. They exclude customer contact details, shopping content, search terms and credentials. These records support access control, security and investigation.

Your rights

Under UK GDPR you have the right to:

• Access — request a copy of the data we hold about you.
• Portability — download a machine-readable account export from your profile page. It includes your handoff status and timestamps, AI requests you made, and allowance allocations billed to your account. It excludes private proof tokens, encrypted phone proof, and other members' identities from allocation records.
• Rectification — ask us to correct inaccurate data.
• Erasure — delete your account and the data associated with it at any time from your profile page, or by emailing us, subject to the limited exceptions in Data retention below. How to delete your account sets out the steps, what is deleted, and what is kept.
• Restriction — ask us to restrict processing of your data in certain circumstances.
• Object — object to processing based on legitimate interests.

To exercise any of these rights, email privacy@urcartbuddy.com. We will respond within 30 days.

Complaints

If you are unhappy with how we handle your data, you have the right to lodge a complaint with the UK Information Commissioner's Office (ICO) at ico.org.uk. We would appreciate the chance to address your concern first — please contact us at privacy@urcartbuddy.com.

Cookies

Our public website at urcartbuddy.com is a static information site. It does not install the web app or store your lists in your browser. Demonstration videos are hosted by us, without third-party video embeds or tracking. The web app runs separately at web.urcartbuddy.com. The browser storage described below belongs to that app's address.

If you previously used the web app at urcartbuddy.com, your browser may still hold data for that old address. When your browser updates the old offline worker, our cleanup removes that worker and the cached pages and thumbnails it holds at that time so future visits open the public website. Other saved browser data, including offline changes and sign-in storage, may remain until you clear that site's data or your browser removes it. It is not automatically transferred to the new app address, and the new app does not send those old offline changes.

UrCartBuddy does not use tracking or advertising cookies. We use browser localStorage only to make the app work on your own device: to keep you signed in between sessions, to hold a copy of your lists so they still open when you are offline, to queue changes you make offline until they can be sent, and to remember display preferences such as text size and which list you last had open. All of it stays in your browser, is never sent anywhere as tracking data, and is cleared when you clear the site's data. The restricted administrator area at admin.urcartbuddy.com uses essential, secure session and anti-forgery cookies. Its one-hour sessions use Google sign-in, which receives the sign-in request and provides the administrator's verified email and identity reference. Only configured administrators can access account and service information for support and operations. These admin cookies are scoped to that address.

The Android app also remembers interface preferences on your device, including whether you have hidden the reorder help. This setting is not sent to our servers and is removed when you clear the app's data.

Children's privacy

UrCartBuddy is not intended for use by children under the age of 13. We do not knowingly collect personal data from children. If you believe we have inadvertently collected such data, please contact us at privacy@urcartbuddy.com and we will delete it promptly.

Changes to this policy

We may update this policy from time to time. Material changes will be notified via the app or by email. The date at the top of this page shows when it was last revised.

Contact

Data controller: Binary Components Limited (company number 05837146), 79 Goldhawk Road, London, W12 8EG, United Kingdom.
Email: privacy@urcartbuddy.com