There is no account to delete
ShotDetect has no sign-in and no user account. There is no profile and no phone number held anywhere.
There is one email address, if you gave us one. This page previously said there was no email address held anywhere, and that has not been true since the app's closed test opened. That test is over and no address is being collected any more. If you asked for a place on it — on the signup page while it was up, or by writing to us — we still hold the Google account address you gave, because Google Play matches testers by account and cannot install the app without one. Nothing you do inside the app creates that record, and the app never sends it: it exists only if you typed it into the form. It is the one thing here we can look up, and therefore the one thing we can delete on request. Section 01a says how.
Since August 2026 there is one server, and this page previously said there was none. It forwards alerts to a guardian who is not at the school. It holds no account and nothing that names you: an alert sits on it as encrypted bytes, addressed to a random token, and is discarded after ninety minutes whether or not it was collected. It has no key to read any of it. See the privacy policy, section 11.
One thing on that server outlives the alert, and this page previously implied nothing did. When your phone pairs, it registers a random sixteen-character routing token and the public key allowed to collect from it. That record is kept for ninety days after the phone last used it — every time the phone checks for messages it proves it holds the matching private key, and the ninety days start again. A phone that stops asking, because it was uninstalled or simply never opened again, loses the record automatically at the end of those ninety days. It carries no name, no account and nothing derived from your phone or from you, and nothing on the server connects it to a person — but it is a record, it persists while the app is in use, and it can be deleted sooner. Section 04 says how.
What we cannot do is look you up from the app. There is no account to find and no way for us to tell which routing token is yours — so a deletion request by email cannot reach the record the app made, however much we would like it to. That deletion route is the app's own, and it is described in section 04. The test address above is the exception, and the one thing an email to us can act on.
Deleting the address you gave us
Email contact@shotdetect.com from the address you signed up with, or naming it, and say you want it deleted. We delete the record — the address, when you signed up, whether you confirmed, and the referral code attached to it — and reply to say it is done. There is no form to fill in and no account to close.
Two things worth knowing. Deleting is not the same as unsubscribing: every message we send carries a link that stops the mail while leaving your place on the test, which is usually what people want. And after a deletion, the confirmation link in any old message from us stops working — we keep a marker so that a link clicked, or fetched by a mail scanner, cannot quietly put you back. The marker holds a one-way hash of the address and the date, never the address, and it expires after about thirteen months. Signing up again clears it.
If you never confirm a signup, the place is released and the record deleted automatically after fourteen days. Nothing is kept about it.
What the app holds, and where
The timeline of what happened lives in your phone's memory while the app is running. It is not uploaded anywhere, and it does not survive the app being closed.
This page previously said the same of the people you have connected. That was true until August 2026. Pairings are now written to the phone, because a pairing that vanished when the app closed made two families pair again every time, and because a guardian's phone cannot be sent an alert it has forgotten how to address. Section 03 lists what a pairing record contains.
Sound is never part of this. It is examined in memory and overwritten within seconds, so there is no recording to delete at any point.
What is written to the phone
Three things. This page previously said none of them contains personal data, and that was true until August 2026 — the third now holds a name and a list of the people you paired with.
- Cached map tile images. The map squares already fetched from the OpenStreetMap Foundation's tile servers, kept so the same square is not downloaded twice.
- The map library's own settings. Written by the mapping component, not by us.
- A settings file named
shotdetect.protection. It holds whether you had armed the app; the listening hours you agreed to, as days and times; the coordinates and radius of the school you chose from the search; whether this phone is a student's or a guardian's; which version of the disclaimer was accepted; a count of the times the operating system killed the detector without you stopping it; and the reason the last capture attempt failed if one did. The hours and the school are stored because the listening service and the boot handler both have to honour them without the app being open; the armed flag is what lets a phone come back in the state you left it in after a restart. It carries no record of anything the phone heard.
Since August 2026 that settings file also holds what pairing needs:
- The name you asked to be called, if you gave one.
- This phone's own pairing key pair and its routing token.
- For each person you paired with: the name they gave, whether they are a student or a guardian, the date you paired, the confirmation code the two phones showed each other, their public key and routing token, and the country and time zone their phone reports.
This page listed two more per-pairing values until 2026-09-20, and they no longer exist. Release 7 stored a switch for whether this phone sent a paired person place notes and a switch for whether it shared where it was with them all day. Both were withdrawn: place notes are unconditional inside the school zone, the all-day trail was removed outright, and with nothing left to consent to the switches went too. No per-pairing sharing setting is stored on the phone, because there is none.
The private key is the most sensitive value in the file — whoever holds it can read that pairing's alerts.
Since 2026-09-20 the file may also hold a mesh enrolment code, and only if somebody typed one in. A school that runs ShotDetect can issue one code to every family, so that the phones at that school recognise one another's detections and a phone from outside cannot have its detections counted. It is the school's code rather than yours: every family at the school holds the same one, it is not a password for any account, and the phone keeps no record of who issued it. A phone with no code entered works exactly as before. The code is never sent anywhere — not to us, not to the school, not to a paired phone — and it is excluded from cloud backup and from phone-to-phone transfer, because a new handset should be given the code by the school rather than inherit it from an old one.
The workplace and agency roles are not available in the version on Google Play; they appear on the first screen as "Not available in this version" and cannot be selected. The next paragraph describes what a phone in those roles would hold, so that this list is complete.
Since 2026-09-13 a phone used at a workplace also holds its site in that file — the site's name and address, the boundary somebody walked, its floors and zone names, the hours agreed with the employer, the wording of its broadcasts, and the surveyed position of each fixed listening device. On a workplace manager's phone it additionally holds which police agency the site offered its incidents to, when that began, when it expires, and whether it was stopped. That last row holds no incident, no contact details for the agency, and no record of who read anything. Neither exists on a family phone, and both are erased with everything else by the steps below.
Four smaller things belong on the same list, and this page did not name them before. The emergency number, where you set one by hand instead of taking the one your SIM card's country implies. On a guardian's phone, the school chosen for each student they are paired with. Whether the phone was last judged to be at the school, which is what the listening rule compares against. And the app's bookkeeping for the relay: whether this phone has registered, how far through the queue it has read, the difference between its clock and the relay's, and whether it is waiting out an operating-system limit before asking again. None of them is audio, a position history, or anything typed by another person.
The phone's own position is never written to storage. The app reads its own position while it is listening and while the app is open, and puts it on the Bluetooth message described in the privacy policy. Since August 2026 it also sends it, sealed, to the people you paired with while the app is on screen — about once a minute while the phone is still, about every fifteen seconds while it is moving, and about every two seconds during an alert and for the ten minutes after. Since 2026-08-30 a student's phone does that only inside the school zone, and it sends its position for about fifteen minutes at a time to anyone paired who has opened their own app. Every one of those is held in memory for as long as it takes to send or to draw, and none is written to storage. The positions your paired people send you are drawn as a dot on a map and dropped after ninety seconds of silence. This page said those were never a file, which was true until August 2026: the settings file now also keeps the last place each paired phone reported, so a restart does not blank the map. It is the newest report only — overwritten by the next one, ignored once it is more than ninety seconds old, never used again once you disconnect that phone, and erased on uninstall. There is no location history to delete, on any phone or on our relay — and neither the school-zone sharing nor a paired person's request creates one: both replace the same single newest position rather than adding to a list. There is also nothing to delete for the request itself. A phone remembers which paired people have asked to see it only in memory, never in a file, so the list is gone the moment the phone restarts. The only other coordinates in the file are the school's, which you chose yourself — not where any phone has been.
Since August 2026 the file also keeps two rows about place notes, and this page did not name them before:
- The last note saying a paired phone reached school or left it, one row per phone.
- What this phone last told your paired people about its own place.
- A place note is a time and which side of the school boundary a phone was on. It carries no coordinates of any kind, and it is not a history: each row is replaced by the next.
Both rows exist to stop a repeat rather than to keep a record. Without them, a phone whose background service the operating system restarts would tell you a second time that your child had arrived — once per restart, with no way to notice it was repeating itself.
Nothing the app writes to storage contains audio. This page also said nothing it writes leaves the phone. That was true until August 2026. Two of the values above do: this phone's routing token and its public key are sent once to the relay when you pair, so that an alert can be addressed to you. The private key is not sent, and could not be.
How to remove everything
On a guardian's phone, do this first: stop the phone being a guardian. When it is no longer listening for messages from a paired student — because you removed the last student you had paired with, or changed the phone's role — the app stops the relay watch, and stopping it is what asks the server to delete the token-and-key record described in section 01. The request has to be signed by the private key on that phone, which is why nobody else can delete your record and why we cannot delete it for you. If the phone has no network at that moment the request fails and the record survives; doing it again later tries again.
On a student's phone there is still no button, and this version does not pretend otherwise. That phone registers a routing token too, so that a guardian's phone knows how to reach it, and nothing in the app asks the server to unregister it on purpose. What has changed is that it no longer has to: the record expires ninety days after that phone last checked the relay, so uninstalling starts a clock rather than leaving something behind for good. It is a slower answer than a button and we would still rather have the button, but the record does now go by itself.
Then uninstall the app. That removes the cached map tiles, the map
settings and the shotdetect.protection file — the key pair, the routing token,
the pairings and the names among them — from the phone.
Uninstalling on its own does not clear the server record at once, and this page previously said nothing was left behind at all. An app that has been removed cannot ask the server for anything, so the record stays until it expires — ninety days after that phone last checked the relay. In the meantime it is useless: a reinstall mints a new token rather than reclaiming the old one, and nothing can be delivered to a token no phone is holding the key for. Useless is not deleted, which is why the ninety days matter and why we would rather give you the number than let the word "uninstall" imply something faster. Turning the relay off before uninstalling is still the difference between ninety days and now.
To clear that storage without uninstalling, open Android Settings → Apps → ShotDetect → Storage → Clear storage. That also clears the armed flag and the listening hours, so the app will be off afterwards and a restart will not start it listening. It clears the pairing keys too, which means the phones you paired with must pair again — and, like uninstalling, it leaves the server record to expire on its own ninety days unless you turned the relay off first.
This paragraph said until August 2026 that two outside services see your device's IP address when the app asks for a school address or a map tile. They no longer do. Both requests go to our own server, which asks OpenStreetMap and passes the answer back, so we receive the address, the school name typed and the part of the map being looked at, and OpenStreetMap receives our server's address instead of your phone's. What OpenStreetMap keeps is still governed by their own policies, linked from section 08 of our Privacy Policy. These two requests are not sealed the way an alert is, and the guarantee that we cannot read a family's alerts does not reach them.
Making a request
If you believe we hold data about you, email contact@shotdetect.com and we will respond within 30 days.
We will tell you honestly what the answer is, and the honest answer has changed twice. We hold no name and no account. We hold your email address if — and only if — you asked for a place in the closed test with it; that one we can find, and we delete it on request, which is section 01a. Everything the app itself creates is different: the relay holds encrypted bytes under a random token for at most ninety minutes; a record that an alert was collected — a token and an opaque number, no content — for twenty-four hours; and the token-and-public-key record for ninety days after the phone that owns it last used it. None of that is linked to a person, which is why there is no lookup we could perform on it even in principle: we cannot find it, and that also means we cannot delete it for you. Section 04 is the route that works for it. The reply to an email is a real one, not a form letter.
Retention
This section previously read "We retain nothing, because we receive nothing." That was true until August 2026. The relay now receives things, and retains four of them for four different lengths of time:
- An undelivered alert — or a student's reply to one, or a guardian's settings message — is kept for ninety minutes, then discarded whether or not it was collected.
- A position, a note that a phone reached school or left it, and a request from one paired phone asking another where it is, are kept for fifteen minutes. Each is last-write-wins: a newer one replaces the one before it rather than being added to it. The fifteen-minute share that follows somebody opening their app, added on 2026-08-29, sends more of them and changes neither the rule nor the period — there is still only ever one position per pairing on the server.
- A record that an alert was collected — a token and an opaque number, with no content — is kept for twenty-four hours.
- The binding between a routing token and the public key allowed to collect from it is kept for ninety days after that phone last used it, or until the phone asks for it to go, whichever comes first.
We do not log request contents. We cannot read any of it.
The test address is a fourth, and it sits outside all of that because the app never touches it. An address that confirmed is kept until we have finished deleting the closed test's list, or until you ask us to delete it, whichever comes first. An address that never confirmed is deleted after fourteen days and its place released. An address that unsubscribed is kept and marked rather than deleted — deliberately, so that a later signup cannot quietly resume mail to somebody who asked us to stop — and is deleted on request like any other. The record holds the address, the dates, whether it confirmed, a referral code and where the signup came from. It holds no name, no phone number and nothing from the app.
Who physically holds those three things. The relay runs on Vercel, and the queue itself is a managed database operated by Upstash; both are outside the Philippines, and neither can read any of it, because what they hold is ciphertext addressed to a random token. This page described the retention without naming the holders until August 2026 — section 12.6 of our Privacy Policy is the complete sub-processor list, and the same two names are now in the app's own accepted disclaimer rather than only on the website.
On your own phone, the three items in section 03 are kept until you clear the app's storage or uninstall it.
If your workplace runs a site
The workplace and agency roles are not available in the version on Google Play; they appear on the first screen as "Not available in this version" and cannot be selected. What follows describes those roles so that this page is complete.
Everything above applies to a phone at a workplace unchanged: the same three things on the phone, the same four periods on the relay, the same absence of any account we could look you up by. There is nothing extra to delete, because a workplace deployment collects nothing extra — no position outside an open incident, no history of where a phone has been, and no arrival or departure notes. Section 11a of the privacy policy is the whole of that.
Uninstalling is the whole of the route, and it is yours rather than your employer's. Clearing the app's storage or uninstalling removes the site, its boundary, its hours, the devices this phone was paired with and this phone's own keys, exactly as section 04 describes. A manager cannot delete anything from your phone and cannot stop you doing it.
Two things live on the site's side rather than yours, and a manager holds the delete for both. The site record — its boundary, its hours, its roster of devices — goes when the site does. An enrolment with a police agency has an end date it cannot outlive, can be ended at once by a manager, and disappears from the server by itself when it expires.
An incident sent to a police agency is held for thirty days and then deleted. It carries no sound, no name, no account, and nothing saying which phone heard what, so there is nothing in it to delete on a person's behalf and nothing we could find if you asked. What an agency keeps of its own copy is theirs, under their own law, and a request about that goes to them. No incident has ever been sent to any agency.