Privacy Policy

Effective 2026-08-20 · Version 1.5

Who we are

ShotDetect is made by Llyr Labs. You can reach us at contact@shotdetect.com.

ShotDetect is a research prototype. It listens for the sound of gunfire on the phone it is installed on, shows what that phone heard, and broadcasts that judgement to phones within Bluetooth range.

Since August 2026 it can also forward a corroborated alert to a guardian who is not nearby. This policy previously said there was no server and no path by which an alert could reach a parent who was not standing next to the school. That was true, and it meant the app did not work for a parent at work, on a night shift, or in another country — which is most parents, most of the time. There is now one server, described in section 11, and it is built so that operating it reveals as little as routing allows: it holds a sealed block of bytes addressed to a random token, and has no key to open it.

Also since August 2026: people who have paired with each other share their live position with each other while the app is open. Version 1.3 of this policy said, in section 05, that "Nobody can watch where you are between alerts". That was true when it was written and it is not true now. A student's position goes to the guardians that student paired with, a guardian's position goes to the students they paired with, it goes to nobody else, and it stops when the app is closed. Section 05 sets out exactly what is sent and when; section 11 covers what the relay carrying it can see, which is nothing but ciphertext.

This policy describes what the app does with sound, with your location, and with anything that could identify you — as the app behaves today, not as it is designed to behave.

Sound is never recorded

Sound is examined in memory and overwritten within seconds. It is not recorded, saved or uploaded. No one — including you, and including us — can play it back.

This is not a promise about how we behave. The shared detection code is built without access to storage or the network, and an automated test fails the build if anyone gives it either. That test covers the shared detection library. The Android service that captures the audio and hands it to that library is not covered by it — it writes no audio anywhere, but there you have our word rather than a test. That check runs every time the app is compiled.

This phone hears other people too

While the app is listening, the microphone captures whatever is around it, including other people and their children. That sound is handled in exactly the same way: examined in memory, overwritten within seconds, never stored and never sent anywhere.

Why the microphone runs while the app is armed

A gunshot cannot be detected after the fact. To notice one, the app has to be listening when it happens. The microphone is open when two things are true at once: a guardian has armed the app, and the current time falls inside one of the listening windows they set. It is released at the end of a window and when you disarm.

The schedule fails closed. A schedule that is empty, that has no enabled window, or that the app cannot read means the microphone stays shut — an app that listens because it could not read its own settings is the failure the rule exists to prevent.

One limit worth knowing. The check that closes the microphone at the end of a window runs in the app's own screen rather than inside the listening service. While the app is running it is re-evaluated every half minute. If you arm the app and then swipe it away, the listening service carries on, and it can stay open past the end of a window until the app is opened again. Disarming closes it at once, whatever the hour.

Two related consequences of the app remembering that you armed it: a phone that reboots starts listening again on its own, though only once a window is open; and turning protection off is remembered too, so a restart after that starts nothing. See section 07.

You do not have to take our word for which state you are in. When the app is dormant it releases the microphone at the operating-system level, so your phone's own microphone indicator goes out. That indicator is controlled by Android, not by us.

While the app is listening, Android requires a notification that cannot be dismissed. That is deliberate on Android's part, and we agree with it: an app using your microphone should not be able to hide.

The app reads the phone's location while it listens, and shares it with the people you paired with

This section previously said the opposite. Until August 2026 the app read no location at all and this policy said so. It now does, the change is described here rather than quietly made, and the in-app disclaimer version moved with it so that anyone who agreed to the earlier wording can tell that they agreed to a different app.

Why. An alarm is only raised when at least three phones heard the same sound at the same moment from points at least fifteen metres apart. That last condition is the whole defence against a single phone's mistake — one door slam heard by one phone is not an emergency — and it cannot be applied without knowing where each phone was. When the app broadcast the school's coordinates instead of each phone's own, every phone appeared to be in the same place, the fifteen-metre test could never pass, and no alarm could ever be raised however many phones agreed. There is no version of corroboration that works without per-phone positions.

What is done with it, first purpose: corroboration. The position, and how accurate the phone believes it to be, are two fields of the short Bluetooth message described in section 08. It is broadcast to phones within radio range. If the sound is corroborated by at least three phones and the detector is highly confident, it is also sealed and forwarded to a guardian you have paired with — see section 11 for exactly what that means and what the server can see, which is nothing but ciphertext. It is not written to storage and not attached to a name or an account. On the Bluetooth message it carries a label regenerated for every event, so two broadcasts cannot be tied together. The forwarded copy is addressed to the routing token described in section 06, which does persist — but the position is sealed inside the message and the relay has no key to read it.

Second purpose, and it is new: paired people see each other. This section used to end "Nobody can watch where you are between alerts", and until August 2026 that was true — a position crossed the relay only inside an alert, for the duration of one incident. It is no longer true, and the sentence is quoted here rather than deleted so that a reader who relied on it can see that it has gone.

What happens now: while the app is open on a phone, that phone sends where it is to the people it has paired with, about every five seconds. Each update carries the position, how accurate the fix is, the time it was taken, and whether the phone is moving — which is read from the fix's own speed, so a phone lying still is not drawn as though it were walking. On the receiving phone it is a dot on a map, and nothing else: no notification, no sound, and no record kept.

Location is read while the microphone is open — which is only inside the listening windows the guardian set — and also while the app itself is on the screen. The second of those is new with this feature; before it, closing the listening window ended the reading outright.

What we are not claiming. This is not a tracker and should not be relied on as one. A phone with no signal, no location permission, a poor fix or a flat battery shows nothing or shows something vague, and an empty map is not evidence about where anybody is.

If you refuse it. The app still listens and still detects. It broadcasts the school's coordinates instead, which is honest and useless for the fifteen-metre test, so the phone can hear a bang and never raise an alarm. The app says this on its home screen rather than leaving you to discover it. That substitution applies to the Bluetooth message only: with no position of its own, a phone sends nothing at all to the people it paired with, rather than drawing a confident dot on a school somebody may be nowhere near.

The permissions. The app requests ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION together, and needs the precise one: an approximate position is accurate to roughly a kilometre and cannot answer a fifteen-metre question. ACCESS_BACKGROUND_LOCATION is not requested. The Bluetooth scan permission is separately marked neverForLocation, which remains true — the app derives no location from scanning; it reads it from the location providers named here.

The app also reads two things that hint at where you are, neither of which identifies you or leaves the phone: your device's time zone, used to display your listening windows in local time, and your SIM card's country, used to show the right emergency number.

No account, and no identifiers

There is no sign-in. The app does not ask for a username, a password, an email address or a phone number, and there is nothing to create an account with.

There is one place we do ask for an email address, and it is outside the app. ShotDetect is in a 100-place Android early access test, and to join it you give us — on the early access page, or by email — the Google account address you sign in with on your phone. Google Play matches testers by Google account, so it cannot let you install the app without one. It is used to add you to the tester list, to send you the install link and the handful of messages the test runs on, and for nothing else. Testers must be 18 or over.

Where it is kept. That address is stored for us by Upstash, the same managed database the alert relay uses, reached through our host, Vercel. It goes nowhere else. Mail is sent through Titan, the provider behind our own contact@shotdetect.com mailbox, or through Resend; the address is given to whichever is sending, because that is what sending an email means.

How long. An address that confirmed is kept until the early access test ends or you ask us to delete it, whichever comes first. An address that never confirmed is deleted automatically after fourteen days, and its place released. Ask us and we delete any of it — Deleting your data, section 01a, says exactly what that removes and what it leaves. Deleting is not the same as unsubscribing: every message carries a link that stops the mail and keeps your place.

The app does not use an advertising identifier. This section previously said it generates no device identifier that persists between events. That was true until August 2026. Pairing with a guardian now mints two things that do persist: a key pair, and a random sixteen-character routing token which is the address the relay delivers to. Both are made on the phone, both are kept in the app's own storage, and neither is derived from anything about the phone or the person holding it. The token is what the relay knows you by; it knows nothing else. Uninstalling the app destroys both, and re-pairing afterwards mints a new pair — the old token is not reclaimed. See section 11 for what the relay does with it, and Deleting your data for how to remove it from the relay.

The Bluetooth message is a separate matter and is unchanged: the label it carries is regenerated for every event, so two broadcasts cannot be tied to the same phone. The routing token is never broadcast over Bluetooth.

One more thing the app stores about you, and it is the only one: the name you ask to be called. It is typed in during pairing, it is a first name or a nickname because that is all the other phone needs to display, and skipping the question is supported. It is shown on the phones you paired with. It is never sent to the relay, and it is never sent to us.

Almost nothing is kept between sessions

The timeline of what happened lives in the phone's memory while the app is running. It is not uploaded, and it does not survive the app being closed.

This section previously said the same of the people you have connected, and that the settings file held no personal data. Both were true until August 2026. A pairing that vanished when the app closed meant two families had to stand next to each other and pair again; and a guardian's phone cannot be sent an alert it has forgotten how to address. So pairings are now written to the phone.

What is written is a small settings file, named shotdetect.protection. It holds:

There is no sound in it, no account, no email address and no phone number. The private half of the pairing key is the most sensitive value the app stores, because whoever holds it can read that pairing's alerts. It sits in the app's own private storage rather than in the Android keystore, and that is a choice we should state rather than bury: the keystore cannot perform the key agreement this uses on Android versions before 12, and a safety feature that quietly works only on newer phones is worst for the families least able to buy one.

The hours are stored because the listening service and the boot handler both have to honour them and neither can see the screen you set them on. The armed flag is stored so a phone which restarts can come back in the state you left it in, and so the app can tell an unwanted shutdown apart from one you asked for. It also means that a reboot does not switch the microphone off: if the app was armed when the phone restarted, it starts listening again by itself once a window is open. Switching protection off clears the flag, and a reboot then starts nothing.

The app is designed to keep a list of alerts on the phone. That describes where the app is going, not where it is today: the timeline is held in memory only and is gone when the app closes. Practice alerts are written into it as well, labelled as drills. Either way, it holds no sound and never leaves your phone.

Section 03 of Deleting your data lists everything the app writes to storage, this file included.

What leaves the phone

The app makes network requests to three places. This section previously said two outside services, and that was true until August 2026. None of the three carries audio. Two are outside services and carry no detection either; the third is our own alert relay, and it carries a sealed alert. All three are set out here in full:

All three requests carry your device's IP address, as any web request does, and an IP address can indicate roughly where you are. For the two OpenStreetMap services, what becomes of it is governed by their own policies: OpenStreetMap Foundation and the OpenStreetMap Foundation. What our own relay sees is in section 11.

Detections are broadcast to nearby phones over Bluetooth. This is the other half of the August 2026 change described in section 05; this section previously said no detection was sent anywhere at all. When the app decides a sound was gunfire it broadcasts a 33-byte message: the moment of the sound, this phone's position and its accuracy, how confident the detector was, whether the microphone clipped, and a random label regenerated for every event. It contains no audio, no name, no account and no identifier that links two events to the same phone. It is a broadcast, so anything in radio range that is listening for it can receive it — which is precisely why it carries nothing that identifies a person.

To be exact about what is proven: a message has been shown to cross between two real handsets, in both directions, in 0.22 seconds, and the receiving phone decoded it intact. How reliably it crosses a real building has never been measured — that test was two phones on a desk, which answers whether delivery can happen at all and not how often it does through a wall, down a corridor, or with a dozen phones advertising at once.

This section used to end: "Nothing goes to a guardian who is out of range and nothing goes to us; neither path exists." That was true until August 2026. Both paths now exist. A detection that at least three phones corroborate, and that the detector is much more confident about than it needs to be to warn the school, is sealed on your child's phone and sent through our relay to the guardian you paired with, wherever they are. We cannot read it; we can see that a block of bytes arrived. Section 11 is the whole of it.

And one thing leaves the phone that is not a detection at all. While the app is open, it sends this phone's position to the people it has paired with, about every five seconds, sealed in the same way and through the same relay. It goes to them and to nobody else, it goes both ways, and closing the app stops it. Section 05 is the whole of that one.

No analytics, no advertising, no sale of data

The app contains no analytics package, no crash reporter, no advertising network and no third-party tracker.

No data from any user is sold, shared with advertisers, or used commercially. That is a constraint on our business model, stated here so it can be held against us.

Children

ShotDetect is intended for students of school age and their guardians. Use by a child under 13 requires verifiable parental consent, and a student's phone is not protected until a guardian has connected to it and accepted the terms — so a child never agrees to this alone.

That gate is enforced: a phone will not arm unless a guardian has accepted on it, so a student tapping through the disclaimer alone cannot open the microphone. This page said the opposite until 2026-08-18, describing a gap that had already been closed. What the app cannot do is check who is tapping, which is a different limitation and is stated on the screen that asks.

This paragraph used to begin "The app collects no personal data from any user, of any age." That was true until August 2026. Two things changed. On the phone, the app now keeps the name you asked to be called and the people you have paired with, in its own private storage — sections 06 and 07 list every field. And our relay now receives a random routing token, a public key, a sealed block of bytes and the IP address of whichever phone connected — section 11. It receives no name, no account, no email address and no phone number, and it cannot tell whose alert it is carrying. Nothing from any of it is sold or shared with anyone.

A parent deciding about a child's phone should read section 05 before this one. Since August 2026 a student's live position is shared with the guardians that student paired with, continuously, for as long as the app is open on the student's phone — not only during an alert, which is what earlier versions of this policy described. It is shared with those guardians and with nobody else; there is no directory and no way for a stranger to be added. It goes the other way too: the guardians' positions are shared with the student. And it stops the moment the app is closed. We think that is a reasonable thing for a family who paired in person to choose, and we think a parent is entitled to be told it in plain words before installing rather than to discover it.

The one address we hold ourselves is a tester's, given to us by email to join the closed test, and testers must be 18 or over — we do not put a child's email address on a tester list. Our child safety standards describe this in more detail.

The alert relay, and what its operator can see

Until August 2026 this app had no server. It now has exactly one, and it exists for a single reason: an alert that cannot travel further than Bluetooth never reaches a parent at work, on a night shift, or in another country. The relay is designed on the assumption that you should not have to trust whoever runs it — including us.

It carries two kinds of message, not one. This section described only alerts until August 2026, and that was true then. The relay now also carries the position updates described in section 05 — sent about every five seconds while the app is open, between people who paired with each other. Everything below applies to both unless it says otherwise, and the operator cannot tell which kind it is holding.

What is sent to it. When your child's phone corroborates gunfire with at least three phones, and the detector is highly confident, it builds a short message: the moment of the event, a position, a radius, how many phones agreed, and how precise the system is willing to claim the location is. A position update is a different short message — a time, a position, its accuracy, and whether the phone is moving — and it is padded to exactly the same length, so the two are indistinguishable from outside. Either way it is encrypted before it leaves the phone, with a key that only your two paired phones can compute, and it is addressed to a random sixteen-character token that was exchanged when you scanned each other's codes.

The bar for sending is deliberately higher than the bar for showing. A detection has to clear it by a wide margin before it is forwarded to someone who is not at the school, which cuts false alarms to roughly one per school per year. It is paid for in real events: a substantial share of the gunshots the app would flag at the school are never forwarded at all. Silence from this app is not evidence that nothing happened.

What the operator can see. A block of ciphertext, a random token, the size of the message — which is always the same — and the time it arrived. It cannot read the position, the time of the event, the number of phones, whether it was a drill, or whether the block is an alert at all. It cannot tell which student is paired with which guardian, which school anyone attends, or who anyone is. There is no account, no email address and no phone number anywhere in this system.

What the traffic pattern does say, and we would rather it did not. A phone posting a message every five seconds is a phone with its app open, and the operator can see that much from the timing alone even though it can read nothing. That is the price of the equal-length envelopes: it hides what is being sent, not that something is. We state it rather than let the encryption claim imply more than it delivers.

There is one identifier, and it lasts. The routing token is generated on the phone when you pair, and the relay stores it alongside the public key allowed to collect from it. That record has no expiry — it is the only thing on the relay that does not age out — so the operator can see that the same token has been active over time, and how often. It is not derived from your phone or from you, it carries no name, and nothing on the relay connects it to a person. It is still an identifier that persists, and calling it anything else would be dishonest. Deleting your data explains how to remove it.

What it can see that we would rather it could not. Your device's IP address, as any network connection carries — which can indicate roughly where you are. Guardians' phones hold a connection open while they are waiting to be reachable, so that address is visible for as long as the app is watching. We do not log request contents.

What it can do that encryption cannot prevent. Refuse to deliver, or delay. No cryptography fixes that, so the app measures delivery instead of assuming it: the guardian's home screen shows when the connection was last confirmed, and the "send me a test alert" button sends a real one through the real relay so a family can check the path works on a quiet afternoon rather than discovering it on the day.

How long anything is kept. This is unchanged by the August 2026 position sharing. An undelivered message is held for twenty minutes and then discarded, whether or not it was collected. A delivered one is removed as soon as the receiving phone confirms it. A record that a message was collected — a token and an opaque number, no content — is kept for twenty-four hours so the sending phone can answer "did it arrive". A position is not stored any longer than an alert is, and neither is written to a history of any kind: there is no trail on the relay to look back at.

The one exception is the token-and-public-key record described above, which is kept indefinitely. It is not deleted when you uninstall the app, because an uninstalled app cannot ask us to. A guardian's phone asks when it stops being a guardian — when the last paired student is removed, or the phone's role changes — and the record goes then. A student's phone has no equivalent in this version, so its own record stays until we build one. Either way the request has to be signed by the key the token is bound to, which means only that phone can delete it, and we cannot do it for you on request — we have no way to tell which token is yours. That is the same property that stops us knowing anything about anybody, and it cuts both ways. Deleting your data, section 04, is the step-by-step.

If you would rather not use it. Pairings made before this feature existed keep working over Bluetooth alone, and the guardian's screen says "nearby only" rather than pretending otherwise. To stop sharing a position without unpairing, close the app: nothing is published while it is not on screen. The one thing that overrides that is an alert, which sends a position either way — that is the case the app was built for, and we are not going to pretend otherwise.

Changes to this policy

If this policy changes materially, we publish the new version here with a new version number and effective date. The version in force is the one shown at the top of this page.

Contact

Llyr Labs — contact@shotdetect.com. To remove data, see Deleting your data.