VERSION 2026-09-12

Privacy Policy

This policy covers the seemykitchen.live website and the See My Kitchen Live mobile apps for Android and iOS. It is written to be checked against the product rather than to sound reassuring — where we say we do not collect something, it means the field does not exist.

1. The short version

• Video is never recorded. There is no archive, no replay, and no stored footage of any kitchen, at any point, ever.
• No audio is captured anywhere in the system. Not muted — never captured.
• Accounts are optional. The app works signed out. Signing in with Google or Apple keeps your saved kitchens across phones and holds nothing else; you can delete it in a tap.
• We do not track you across the internet. No advertising identifiers, no third-party analytics, no tracking cookies, no data sold or shared with data brokers.
• Your location reaches us rounded to about a kilometre, with nothing that identifies you, once per launch, and only if you use “near you”. Exact coordinates stay on your device.

2. If you are a diner

2.1 We do not know who you are, unless you sign in

Browsing kitchens requires no account, no email address and no phone number. We do not ask for your name, and signed out there is nowhere to give it.

If you choose to sign in — with Google, or with Apple on iPhone — we receive from that provider your email address, your name and, from Google, a profile picture, and we store them with a random account identifier. You can change the name in the app. Apple lets you hide your real email behind a relay address, and that works here.

What an account holds is the list of kitchens you saved, so it follows you to your next phone. That is the entire purpose and the entire contents. Your watch history stays on your device whether or not you sign in, and the event counts below are still recorded without any identifier — signing in does not connect them to you.

You can delete the account from the YOU screen in the app or at seemykitchen.live/account. Deletion is immediate and removes the account, its saved list and the sign-in record; there is no retention period and no copy kept.

2.2 What we count

So a restaurant can see whether its listing is worth paying for, we record counts of seven kinds of event: a listing being opened, a kitchen being watched in the feed, an arrival from a printed QR code, and taps on the Swiggy, Zomato, directions and phone buttons.

Each record contains only the kind of event, which restaurant it concerned, and the time. That is the whole row.

Deliberately absent from it: your IP address, your device or advertising identifier, your user agent, any session or visitor ID, the page you came from, and any cookie. Nothing in this data can be linked back to you, or used to recognise you on a second visit. This is the only form of analytics consistent with what we promise restaurants, and it is a constraint written into the database itself.

2.3 Location, for “kitchens near you”

If you use the “near you” feature, your device asks your permission for your approximate location. The sorting by distance happens on your device, against a list of kitchens we have already sent you. Exact coordinates are never sent to us.

What is sent, since version 0.5: once per launch, the app sends us your position rounded to two decimal places — about a kilometre — with no account, device or request identifier and without your IP address being kept. We store that rounded point and the time. It tells us which city you are in, so the app can show the right one, and where people who open the app are, which is how we decide where to bring the next kitchens on. It cannot tell us where in a neighbourhood you are, and it cannot be connected to you or to anything else you do.

An earlier version of this policy said your location never left your device. That was true of the app until version 0.5 and is not true now; we changed it for the reasons above, and this section is the record of the change. You can decline the permission and the rest of the product works normally.

2.4 Asking us to add a restaurant

If you ask us to approach a restaurant, we store which restaurant you asked for and a random identifier generated by the app on your device. That identifier exists for one reason — so that one phone counts as one request rather than forty — and it is used for nothing else. It is not an advertising identifier, it is not derived from anything about your device, it does not survive reinstalling the app, and it is never attached to what you watch, tap or search. The event records described above still contain no identifier at all, so the two cannot be connected, by us or by anyone who asks us to.

The name you pick comes from a list of businesses supplied by Google. What you type into that search box is passed to Google to find matches and is then discarded — we do not store it, and nobody at this company can read it.

If you have notifications switched on, we also keep the address of your device against that request, so we can tell you what the restaurant said. That is the only thing it is used for.

2.5 Asking Seemy

Seemy is the assistant in the app. It answers from what each restaurant has declared on its listing — hours, licence number, how to order — and from nothing else: it has no ratings, no reviews, no menus and cannot see the cameras.

When you send Seemy a message, the messages in that conversation and, if you opened it from a restaurant's page, which restaurant that was, are sent to our server and on to Google, whose Gemini model writes the reply. We do not store your messages — not in our database and not in our logs, which record only how long each reply was. The conversation lives on your device and is gone when the app closes. No identifier of yours travels with it: not the request identifier above, not your notification address.

So that Seemy can answer “what's near me” and know which kitchens you care about, the app also sends, for that one reply and nothing else: the neighbourhood name and the same kilometre-rounded position described in 2.3, if you allowed location; the kitchens you have saved; and your first name if you are signed in. None of it is stored by us, and none of it is sent if you have not given it — Seemy simply answers without it.

Google may keep and read what you write to Seemy.We use the Gemini API on its free tier, and Google's terms for that tier say the content you submit and the replies generated are used to provide, improve and develop Google's products, and that human reviewers may read them. Google states it disconnects this data from our account and key before reviewers see it. So: ask Seemy about kitchens, and do not type anything personalinto it — not your name, address, phone number or health details. The chat says the same thing before your first message. If we move to Google's paid tier, under which content is not used to improve products, this section will change and the version above will move.

2.6 Notifications

If you choose to turn on notifications, we store the address your device's push service gives us, along with the keys needed to encrypt a message to it. For diners this record has no user account attached to it — it is a device we can reach, and nothing else about you. Turning notifications off in your device settings ends it; we also delete these records automatically once the push service reports the device is no longer reachable.

2.7 Watching a stream

Video reaches you from our streaming server, which necessarily sees your IP address in order to send you the video at all — as any website does. It is used to deliver the stream and is not combined with anything else, not used to build a profile, and not retained as a record of what you watched.

3. If you appear in a kitchen stream

If you work in a kitchen that streams here, this section is about you, and it is the part of this policy we take most seriously.

Nothing you do is recorded. Video passes through memory on our server and is overwritten within seconds. There is no archive, no replay and no export. We cannot produce footage of you to your employer, to a customer, to an insurer, or to any authority, because it does not exist anywhere.

No audio is captured. Conversations in the kitchen are not transmitted and cannot be listened to.

Cameras must be positioned so faces are not readily identifiable — over a tandoor, tawa, handi or pass, rather than at head height across a room. The deliberately low picture quality supports this: at the resolution these cameras produce, faces, screens and documents are not reliably legible. We do not sharpen, upscale or enhance the picture, and we do not operate any face recognition, identification or tracking of any kind. We will not build one.

Under the Digital Personal Data Protection Act 2023, the restaurant that operates the camera is the Data Fiduciary for anything its camera shows; we transmit its stream on its instructions. Your employer is required by our terms to obtain your written consent before streaming and to display signage in the kitchen.

If you have not consented, or you withdraw consent, write to seemykitchenlive@gmail.com. You do not need to go through your employer, and you do not need to explain why. We will take the feed offline while it is investigated.

4. If you run a restaurant

To operate your listing we hold the email address you sign in with, your business name, address, area and contact details, your FSSAI licence number and expiry, the opening hours and listing content you enter, your camera configuration, and a billing record of what you have been invoiced.

We also hold operational technical data from the kitchen agent software — which version it is running, the machine name it reports, and when it was last heard from — so that a stream that stops can be diagnosed without anyone visiting your premises. Your recorder password is stored on your own machine and is not transmitted to us.

Much of your listing is public by design: that is what you are paying for. Your email address, billing records and diagnostic data are not.

5. Who else processes this data

We use a small number of infrastructure providers, each doing one job:

• Supabase — the database holding listings, accounts and the event counts described above.
• Vercel— serves the website and the apps' API.
• Hetzner — the streaming server. Video passes through its memory and is never written to its disks.
• Google and Apple push services — deliver notifications to devices that asked for them.
• Google Sign-In and Sign in with Apple — if you choose to sign in. The provider confirms who you are and gives us your email and name; we tell it nothing about what you do here.
• Google Gemini API— generates Seemy's replies. Receives the messages in your conversation and the restaurant you were looking at, and nothing that identifies you. On the free tier we use, Google may use those messages to improve its products and human reviewers may read them — see §2.5.
• Google Places — matches what you type when you ask us to approach a restaurant against a list of real businesses, so that everyone asking for the same place is counted together. Your search text reaches Google for that purpose only. We send no identifier of yours with it.

We do not sell personal data, do not share it with advertisers or data brokers, and run no advertising network code in the website or the apps.

6. How long we keep things

• Video — seconds. It is never written to storage.
• Event counts — retained as aggregate history for the owner dashboard. They contain nothing that identifies a person.
• Notification records — until you turn notifications off or the device stops being reachable.
• Restaurant requests — kept while we are still trying to bring that kitchen here, so we can tell you what they say. Reinstalling the app ends your side of it: the identifier is gone and the request can no longer be traced to your device.
• Diner accounts — until you delete them, which you can do at any time from the app or this site. Deletion is immediate.
• Rounded location points — kept, as they identify no one and are the record of where demand was.
• Restaurant accounts — for as long as the listing exists, and afterwards only as required for tax and accounting.

7. Your rights

Under the Digital Personal Data Protection Act 2023 you may ask what personal data of yours we hold, ask for it to be corrected, ask for it to be erased, and complain about how it has been handled. Write to seemykitchenlive@gmail.com.

For diners this will usually be a short answer, because there is normally nothing held that is linked to you.

8. Children

This service is not directed at children, has no social features, no messaging, no comments, no user profiles and no way for anyone to upload content or contact another user. We do not knowingly collect personal data from children. Our standards on child safety are set out at /child-safety.

9. Security

Stream playback is authorised by short-lived signed tokens, so stream addresses are neither public nor permanent. Publishing to a kitchen feed requires a per-camera key. Database access is restricted so that the public can read only published listings. The single most effective security measure in this product, though, is that the sensitive material is never stored in the first place.

10. Grievance Officer

As required by the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules 2021 and the Digital Personal Data Protection Act 2023, complaints may be addressed to our Grievance Officer at seemykitchenlive@gmail.com. We acknowledge within 24 hours and aim to resolve within 15 days.

11. Changes

If this policy changes materially we will update the version at the top of this page. Continued use after that date is acceptance of the revised policy.

Restaurant operator? The Restaurant Publisher Terms set out your obligations. Using the site or apps as a diner is covered by the Terms of Use.