Khel Vision
Privacy policy
What Khel Vision collects, what happens to a match you give it, what stays on your phone, and how to have any of it deleted.
The short version: we receive the match so we can find the rallies in it, and that is all we use it for. Every reel you make is built on your phone and is never sent to us.
1What this policy covers
This policy covers the Khel Vision Android app (com.khelvision.app) and this website.
It is written to be read, not to be survived. Section 4 is the part most people are actually asking about.
2What we collect
| What | Why |
|---|---|
| Your email address | To sign you in, to send the one-time code, and to reach you about your access to the alpha. |
| The match recording you give us | To analyse it and return the rallies in it. |
| Technical details of a match and its analysis | File name, size, duration and format; the identifiers of the upload and the analysis; timestamps; and whether it succeeded. Needed to resume an interrupted upload and to tell you what went wrong when something does. |
| Server logs | Ordinary request records, including an IP address, kept for security and for diagnosing faults. |
Diagnostics
The app reports how it is being used and how failures end, so faults can be found without asking you to reproduce them. This is on by default, and you can turn it off at any time in Settings → Diagnostics → Share diagnostics. Turning it on takes effect the next time you open the app.
| What | Why |
|---|---|
| Which steps you reach, and how each one ends | Steps such as signing in, switching accounts, preparing a file, uploading, analysis, browsing the rallies, editing and export each report that they started and how they finished — completed, cancelled, or failed with a category of failure. This is how we find out that, say, uploads on a particular network are failing at the same point. Recording a match live reports the same way, and in more steps than any other part of the app: opening the session, waiting for it to be ready, each piece of the recording as it is sent and acknowledged, keeping the session alive while you record, the rally updates that come back, and how the match ended — finished, cancelled, or added to your library. What those reports add are counts and the sport you picked: how many pieces the recording was sent in, which piece a report is about, and how many rally updates arrived. What is in the recording is never among them. |
| Technical detail about a failure | The stage it happened at, a category for the cause, the HTTP status where a request was involved, and how many attempts were made. |
| Requests the app makes to us | Which endpoint was called — as a route, never the populated address — the response status, and which attempt it was. Most are recorded for only a sample of requests; a request that fails, and any request belonging to signing in or to a live recording session, is always recorded. When the app starts it also reports which version of our service and of our analysis engine answered it. |
| Technical detail about a file or a reel, never either | Its duration, its resolution and a size band — not the file, not the file name, and not a thumbnail. A reel you are assembling reports its length in the same way, before there is any file to measure. The same kinds of detail describe a match you record live, measured on their own subjects: its resolution and frame rate come from the finished recording, which is the only place either can be read; the duration is how long the session ran rather than how long the finished file is; and the size band is one per piece sent, not one for the whole recording. |
| How long a step took | Steps report their own elapsed time: starting the app, preparing a file, transcoding, uploading, analysis, a search, opening your moments, showing the first frame of one, and an export. A live recording adds how long it waited to become ready, how long it took to open, how long each piece took to send, how far behind the rally updates were, and how much of its recording permit remained when it was renewed. Where our server asks the app to wait before trying again, that interval is reported too. For transcoding and export we also report how that time compared with the length of the video itself, which is what tells a fast phone from a slow one. These are how long something took; what Google’s own services record about your sessions is separate, and described below. |
| How many of something there were | How many pieces an upload or a live recording was sent in and which piece a report is about, how far a cancelled upload had got, where a resumed one restarted, how many rallies came back and how many a filter left, how many you picked for a reel and how many were exported, and how many rally updates a live recording received. Also how much of what a screen needed was already on your phone. Counts, never what was counted. |
| Choices you made, and what was already in progress | How you sorted your moments and how you reordered a reel; which sign-in method you chose and which sport; whether your video needed converting and whether a reel was built from the converted copy; whether you were signed in when the app started, whether the app was in the foreground when it checked on a job, and whether an upload or an analysis was running when you switched accounts. |
| What the app did about a problem | When an upload is interrupted the app has several ways to pick it back up, and it reports which one it chose — waiting and retrying, asking you, signing you in again, or stopping. When you submit a match it reports whether we analysed it fresh, served a result we already had, or recognised it as one already done. |
| How our server said it received each piece of a live recording | For each piece of a match recorded live, the server’s own word for what it did with it, passed on unchanged rather than interpreted. |
| Whether a finished live match reached your library | Added, still to be retried, or no longer possible — usually because the recording your phone kept has since been reclaimed. This one is our app’s own verdict on your device, not anything our server said. |
| How far your phone’s clock is from ours | Measured once each time a live recording asks permission to send a piece. A phone running a second ahead of our server is enough to have that permission refused, and that shows up in no error count — only in this number. |
| Identifiers that let one action’s events be read together | The upload, analysis and session identifiers our own service issued, plus an identifier generated for each thing you do in the app. |
| Which app you send a reel to | If you share a finished reel, the name of the app package you picked from the share sheet — never the reel, and never anything in it. |
| A pseudonymous identifier for your install | Created by Google Analytics for Firebase. It is not your email address, and it is not derived from your account. |
| Crash reports | If the app crashes or stops responding, the error and the stack trace are reported. |
What diagnostics never include. Your videos or any frame of them; your email address; file names; sign-in codes, passwords or access tokens; or anything you type as a player label. No diagnostic event carries an account identifier, and where one refers to a recording it carries a reference derived on your own phone that we cannot turn back into the recording. This paragraph is about diagnostics alone — what the app sends us in order to analyse a match is the table above and section 3.
Diagnostics are processed on our behalf by Google Analytics for Firebase and Firebase Crashlytics. Those services collect a surface of their own that the app does not choose and cannot filter: your device model, operating system version, app version and language, an approximate location derived from your IP address, and a set of automatic events that Google defines and adds to — among them the app being opened for the first time, a session starting, time spent in the app, and the app being updated, cleared or removed. Crashlytics also captures uncaught errors and app-not-responding events by itself. None of that can be switched off while diagnostics are on; turning diagnostics off stops it.
The list of what diagnostics never include is a rule the app applies to everything it sends itself. A crash captured by Crashlytics is the exception: its message is whatever the code that failed put there, and the app never sees it before it is sent. We write that code to keep such values out of error messages, but we cannot promise it there the way we can for the rest.
If you turn it off. Nothing further is sent, and the automatic surface above stops with it. Crash reporting stops when you next open the app — it cannot be stopped in the middle of a running session — and any crash reports still held on the device are deleted rather than sent.
We do not ask for, and have no use for, your date of birth, your contacts or your device’s advertising identifier — the app requests no advertising permission and the analytics SDK is configured not to read one. It asks for no location permission and never reads your device’s location. The only location involved is the approximate one Firebase derives from your IP address while diagnostics are on, described above.
3What happens to a recording you give us
Whether you record the match live in the app or pick an existing file, the app converts the recording into a format that can be uploaded and sends it to us.
On our side it is stored and analysed to find the rallies in it. Doing that produces further copies and processed versions, and those are covered by this policy in the same way as the recording itself. The analysis returns a list of rallies, which comes back to your phone and is stored there.
Your recordings are not used to train models, and they are not sold, rented or shared for advertising. We share them with no one except the infrastructure providers that host the service on our behalf, who may only process them to provide it to us.
4What stays on your phone
Two things, and they are the most important part of this page:
- The reel you make. Reels are cut and exported on the device. No reel is ever uploaded to us, and we never see one.
- Everything you do after the rallies arrive. Watching, picking, trimming, reordering and exporting all happen locally, with no further request to us.
A reel leaves your phone only when you send it somewhere — a share sheet, your gallery, a message, a social platform. That is your act, and what follows from it is covered by section 7.
5This website
This site sets no cookies, runs no analytics, embeds no third-party scripts, and loads its fonts from its own domain. There is nothing here to opt out of.
It is hosted on Vercel, which keeps ordinary server logs of requests — including IP addresses — for security and operations.
6How long we keep things, and how to have them deleted
We keep a match and its analysis for as long as your account has it, and we delete them when you delete the match or when we delete your account. Deleting a match in the app removes it from the device and asks us to remove our copy.
Server logs are kept for a short operational period and then rotated out. Account records — your email address and the fact that you have access — are kept while your access lasts.
Diagnostics events and crash reports are held by Google Analytics for Firebase and Firebase Crashlytics under those services’ own retention, and they carry no account identifier.
Where a diagnostic event refers to one of your recordings, it carries a reference derived on your phone from a key that never leaves it and that belongs to the signed-in account alone — not the recording, and not a value we can turn back into one. Removing your account data destroys that key, so references produced before and after a removal cannot be connected, and the same recording under a different account on the same phone produces a different reference. The pseudonymous install identifier Google Analytics for Firebase creates is separate, and removing your account data does not remove it — to clear that, turn diagnostics off or uninstall the app.
You can ask us for a copy of what we hold about you, ask us to correct it, or ask us to delete it, by writing to privacy@khelvision.in. We will answer within 30 days. Deleting your account deletes your matches, their analyses, and the record of the confirmations you gave under section 7.
7Your responsibilities for the footage you provide
The same two conditions as Terms section 6, stated here because they are as much a privacy matter as a contractual one: they are about other people’s faces.
- A source you give Khel Vision must be a recording you personally own or are authorised to provide.
- Every identifiable person in it must be an adult who agreed to being recorded.
Footage involving minors must never be submitted, on any plan, for any purpose.
The app asks you to affirm both conditions for every recording, and asks you again before a reel leaves it. It records what you affirmed — the sentences as they were shown to you, and when — in a record on your device. That record is not sent to us. It is kept so that a later rewording of this page cannot change what an older confirmation appears to have claimed.
We cannot inspect footage to check who owns it or how old the people in it are. We ask, we state the rule, and we record the answer. That is the whole of what we can honestly do.
8Changes, and how to reach us
When this policy changes, the date at the top of the page changes with it. A change that affects what we collect or what we do with a recording will be described here before it takes effect, not after.
Privacy questions and requests: privacy@khelvision.in.