Privacy Policy

01Who 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 either of their apps is open. Version 1.3 of this policy said, in section 05, that no position left the phone 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, nobody but those paired phones can read it, and closing the app stops the position being sent unless you have somebody you paired with opening their own app. A student's phone sends a position only while it is inside the school zone, described in section 05. It reaches them by passing through the relay we operate — sealed, so that the relay holds bytes it has no key to open — which makes us a carrier of it and not a reader of it. Section 05 sets out exactly what is sent and when; section 11 covers what the relay carrying it can see.

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.

02Sound 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 now covers both halves. It scans the shared detection library and the Android code that opens the microphone and hands audio to it, and it fails the build on any import or reference that could reach a file or a socket. This page said until August 2026 that the capture service was outside the check and that you had our word for it rather than a test; that exemption was real when it was written and has ended. The check runs every time the app is compiled.

03This 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.

04Why 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 three things are true at once: a guardian has armed the app, the current time falls inside one of the listening windows they set, and the phone is at the school. It is released at the end of a window, when the phone leaves the school, and when you disarm. This page said "two things" until August 2026; the third is new, and it only ever closes the microphone earlier.

The school test is not exact, and errs towards staying open. It works from the phone's own position, and it needs clear evidence that the phone has left before it closes the microphone — a phone indoors often cannot tell where it is, and inside a school building is where the app has to keep working. So the microphone can stay open for a while after the phone leaves. If the phone has no position at all the test is not applied, and the listening windows are then the only limit.

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.

A correction. This page said until August 2026 that the check closing the microphone at the end of a window ran in the app's own screen rather than inside the listening service, so that a phone left armed with the app swiped away could stay open past the end of a window. That was true when it was written and is not true now: the listening service re-reads the schedule as it runs and closes the microphone itself, and it applies the school test in the same loop. Disarming still closes it at once, whatever the hour.

The app remembers that you armed it, and that is all a reboot keeps: a phone that restarts does not start listening again on its own — Android refuses that — and has to be opened once, inside its listening hours, before it listens again. Turning protection off is remembered too, so a restart after that starts nothing. Section 07 has the detail, and until September 2026 this paragraph said the opposite of its first half.

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.

05The 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 two 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 two 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 by saying that no position left the phone 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 old sentence is recorded 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 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. 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.

• Who can read it: the pairing, and nobody outside it. A student's position goes to the guardians that student paired with. A guardian's position goes to the students they paired with, and to any co-guardian they paired with — two guardians of the same child may pair with each other, which shares position and online status between them and nothing else, and does not pass on the child's alerts. There is no roster, no directory, no search, no proximity list, and no path by which one family's phone learns another family's position. Pairing happens in person, by two phones showing each other a code, so nobody who was not in that room can ever be a recipient. The app lists everyone a phone is paired with, and a pairing can be removed from that list.
• It reaches them through a relay we operate, so we are a recipient too. Every position update and every alert passes through our server on its way. It is sealed on the sending phone before it leaves, so what we hold is bytes we have no key to open, addressed to a random token — but we are in the path, and saying "it goes to them and to nobody else" would not be true. What is exclusive is who can read it. Section 11 is the whole of what the relay sees.
• It goes both ways. Alerts travel in one direction, from a student's phone to a guardian's. Positions do not: a guardian who opens the app is showing their children where they are, at the same time and on the same terms.
• Several people on each side is normal, not an exception. A child paired with a mother, a father and a grandmother is seen by all three. A guardian paired with three children is seen by all three of them.
• Position sending stops when the app is closed, unless somebody is looking — and a student's phone sends nothing outside the school zone at all. By default, sending happens only while the app is in the foreground on the phone doing the sending — plus for the duration of an alert, when a parent needs to know where their child is without anyone having to open anything. On that default, a phone with the app closed and nothing happening sends no position at all. Since August 2026 that is not the same as sending nothing at all: see the next two items.
• A student's phone shares where it is only inside the school zone. Since 2026-08-30 this is a limit rather than a setting, and it is the reason the app is not a tracker: outside that boundary the phone sends no position at all, even with the app open. There is no switch for it and no way to widen it. A guardian's phone has no school zone — an adult's phone sends its position to the students they paired with, while their own app is open, as it always did, so a child can see a parent coming — and during an alert a phone sends its position wherever it is, because a limit on where the app shares a position must never become a limit on calling for help. No history is accumulated anywhere: the server holds the newest position and replaces it, and neither phone writes one to storage.
  
  What this replaced. Between 2026-08-29 and 2026-08-30 this item described a setting that let a phone share where it was all day, with nobody looking at either handset. It started off and it was granted one paired person at a time. It was withdrawn, and the switch went with it, because the school-zone limit refuses exactly what that switch existed to refuse. Anyone who read this page before that date read a wider product than the one described here now.
• A phone also shares where it is while somebody it paired with has their app open — and this one has no switch. Since 2026-08-29, opening the app does not only show you other people; it asks the phones you paired with to show you where they are. Each of them then sends its position to you alone — not to the others it is paired with — for about fifteen minutes, renewed for as long as you keep looking, and ending by itself when you stop. It does not matter whether the app is open on the phone that is sharing. This is the one thing on this page that a different phone causes, so the two facts that matter most are stated plainly: there is no setting for it, and anybody you paired with can start it — unpairing is the whole of the control. In exchange, the phone that is sharing shows a notice saying so for as long as it lasts, and that notice cannot be swiped away — nothing in the app removes it without also ending the sharing. It changes nothing else: the same cadence, the same sealing, the same recipients-of-one, the same expiry at the relay, and no history anywhere. Nothing survives the phone restarting — a window is held in memory only, so a phone that reboots shares nothing again until somebody opens a map and asks.
• A phone also says when it reaches school, and when it leaves. While the detector is armed and inside the listening hours a guardian set, a student's phone tells the guardians it is paired with that it has arrived at school, or that it has left. That note is sent whether or not the app is open, which is what makes it useful and what makes it worth stating here. It carries a time and which side of the boundary the phone is on, and it carries no position of any kind — not the phone's and not the school's. Nothing new is said between crossings: the same note is repeated for an hour after each crossing, so that a guardian's phone that was off does not miss it. A phone that was not running to watch a crossing says the state it knows without claiming to have seen the crossing, rather than asserting an event nobody observed. There is no switch for it: it goes to every guardian the student paired with, and unpairing is the whole of the control. This page said until September 2026 that it could be switched off one paired person at a time; that switch was removed on 2026-08-30 and this sentence was not updated with it.
• A stale position is never drawn. If nothing has arrived from a paired phone for ninety seconds, its dot is removed from the map rather than faded or left in place. "Here an hour ago" and "here now" must not be able to look similar.
• It is sealed exactly as an alert is — AES-256-GCM under a key only your two paired phones can compute — and a position is the same length on the wire as an alert. Since August 2026 it is written to a different address on the relay, so the operator can see that a message is not a position, and when it arrived; it still cannot read any of it, and it still cannot tell an alert from a reply. Section 11 is the whole of what the relay can see.

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. A request from somebody you paired with adds a third occasion, but it adds no new reading: it publishes fixes the first two already produce, and it does not make the phone ask for one more often.

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, and neither the school-zone sharing nor a request from a paired phone changed that. Neither reads any new location: the app's own notice-bearing service is already allowed to read a position because you started it from the app, and both publish what that service already has. 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.

The camera. The app asks for the camera only to scan the other phone's pairing QR code, and only while that screen is open. Frames are read on the phone to find the code and are not stored, recorded or sent anywhere.

06No 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 ever asked for an email address, and it was outside the app. Before the app was on Google Play it ran a closed Android test, and joining it meant giving us — on the signup page, or by email — the Google account address you sign in with on your phone. Google Play matches testers by Google account, so it could not let anyone in without one. That test is closed, the page is gone, and no new address is being collected. An address given then was used to add that person to the tester list, to send the install link and the handful of messages the test ran on, and for nothing else. Anyone who joined had to 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 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 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.

07Almost 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:

• 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 — and, on a guardian's phone, the school chosen for each student they are paired with — whether this phone is a student's or a guardian's, and which version of the disclaimer was accepted or declined, with the date;
• the emergency number, where you set one by hand instead of taking the one your SIM card's country implies;
• whether the phone was last judged to be at the school, which is what the test in section 04 compares against;
• this phone's own pairing key pair and routing token — see section 06;
• for each person you have 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, and their public key and routing token, which are what let an alert be addressed and sealed for them;
• for each of those people, the country and time zone their phone reports, which is what shows the right emergency number and the right clock;
• the last place each paired phone reported, so that restarting does not blank the map. It is the newest report only, and it is ignored once it is more than ninety seconds old;
• the last note saying a paired phone reached school or left it, and what this phone last published about its own place. A place note is a time and which side of the school boundary a phone was on, and carries no coordinates; both rows exist so that a restart cannot tell you a second time that your child arrived;
• the name you asked to be called, if you gave one;
• a count of the times the detector was killed by the operating system without you stopping it;
• the reason the last capture attempt failed, if one did — for example that the microphone permission had been withdrawn;
• bookkeeping for the relay: whether this phone has registered with it, how far through the queue it has read, the difference between this phone's clock and the relay's, and whether it is waiting out an operating-system limit before asking again;
• on a workplace phone only, and new on 2026-09-13. 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. This row and the next are listed so that the disclosure is complete: the site — its name and address, the boundary somebody walked, its floors, its 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 only: which police agency the site offered its incidents to, when that began, when it expires, and whether it was stopped. That row holds no incident, no contact details for the agency, and no record of who read anything — the log of who looked is fetched from the server by the screen that shows it, and is never written to the phone.

The last two were held in memory only until 2026-09-13, deliberately, because writing them down is a disclosure and the disclosure had not been made. That was the right reason to wait and the wrong place to stop: a site that vanished whenever the operating system reclaimed the app meant somebody walked the perimeter again, and an enrolment that is defined as a ninety-day term restarted its ninety days at every reboot. Neither row exists on a family phone.

Two further things are written outside that file, by the map component rather than by us: the map squares already fetched from the OpenStreetMap Foundation's tile servers, kept so the same square is not downloaded twice, and the map library's own settings.

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 protection off. This paragraph said until August 2026 that an armed phone starts listening again by itself once a window is open, and that is not true. Android does not let a background component open a microphone, and names the microphone specifically among the things a boot handler may not start; the app attempts it and is refused. The phone has to be opened once, inside its listening hours, before it listens again — which is true every day and not only after a reboot. A day on which the student's phone is not opened during its listening hours is a day without protection. The app asks the student for that when the school day starts, and tells the guardian if it does not happen. No permission and no setting removes it. 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.

08What leaves the phone

The app makes network requests to one place: our own server. This section said two outside services until August 2026, then three places, and each was true when it was written. What changed is that the school search and the map moved behind our own origin — the phone asks us, and we ask OpenStreetMap. None of these requests carries audio. Two of them we can read; the third is sealed and we cannot. All three are set out here in full:

• School search — www.shotdetect.com/api/geo/search. When you type a school's name to set up a zone, that text is sent to our server, which asks OpenStreetMap's Nominatim service and passes the answer back. We receive the name you type and your phone's IP address; Nominatim receives the name and our server's address. The request carries a country filter and a user agent naming the app. It happens only while you are typing in the school search. It exists in this shape because Nominatim's usage policy requires that the app be able to switch to a different geocoder at the Foundation's request without a software update, which is impossible while the address is compiled into the app.
• Map tiles — www.shotdetect.com/tiles/. The maps you see are images fetched by our server from the OpenStreetMap Foundation, drawn from OpenStreetMap data. We receive which map squares are being asked for and your phone's IP address; the Foundation receives our server's. The request carries no detection data and never touches the part of the app that listens. It happens whenever a screen with a map is on show. Nothing is stored: the server passes on the tile you are looking at and never fetches an area in advance, which is what the Foundation's tile policy permits. The map data is still OpenStreetMap's, under the same licence, credited on the map itself and on our attribution page.
• The alert relay — our own server. A phone contacts it once when you pair, to bind its routing token to its public key so that messages can be addressed to it; whenever a corroborated, high-confidence detection has to be forwarded; and — since August 2026 — while the app is open, or while somebody you paired with has theirs open, to send your position to the people you paired with, at a pace that runs from about once a minute while the phone is still to about every two seconds during an alert. Both phones also hold a connection open to it while the app is watching for something addressed to them. What travels is a sealed block of bytes and a random token, never audio and never a name; the relay has no key for any of it, and an alert and a position are the same length. Since August 2026 a position is written to a different address there, so the operator can see that a message is not a position. Sections 05 and 11 set out what it can and cannot see. This bullet said "a phone contacts it twice" until August 2026, and that was true when it was written.

All three requests now carry your device's IP address to us, as any web request does, and an IP address can indicate roughly where you are. This paragraph said until August 2026 that two of them carried it to the OpenStreetMap Foundation. They no longer do; the Foundation sees our server. What becomes of what the Foundation does receive — the school name, the map square — is governed by the OpenStreetMap Foundation's privacy policy.

Two of the three we can read, and one we cannot, and the difference matters. The alert relay carries a sealed block of bytes we have no key for; that is set out in section 11 and it is unchanged. The school search and the map request are ordinary web requests to a server we operate, and nothing about them is sealed — moving them behind our own origin did not extend the relay's guarantee to them, and it must not be read as having done so. What it did was make the geocoder and the tile source changeable without shipping a new version of the app, which the Foundation's policies ask for.

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 short message, and this is the whole of what is in it:

• The moment of the sound.
• This phone's position, and how accurate that position is.
• How confident the detector was.
• Whether the microphone clipped.
• A random label regenerated for every event.
• A check value that lets a receiving phone reject a message somebody tampered with.

It contains no audio, no name, no account and no identifier that links two events to the same phone.

Be clear about the position in it. It is given to within a few centimetres, the broadcast is not encrypted, and anything in radio range that is listening for it can read it — which is precisely why the message carries nothing that identifies a person. A device in range learns that some phone running this app heard something, and where that phone was, and nothing about whose phone it is.

Since August 2026 a listening phone also broadcasts a presence beacon. It is a short Bluetooth signal sent about every twenty seconds, only while the detector is armed and listening, and it carries a rotating random label — redrawn every fifteen minutes — and a check that it came from this app, and nothing else. No position, no name, no account, and nothing derived from any sound. Nearby phones running the app use it to count how many armed phones are around, and that count is shown on the phone's own screen and goes nowhere else.

This page gave the message's size in bytes until August 2026. The number has now gone stale twice, and it was never something a reader could act on; what it stood in for is the list above, which does not age with the wire format.

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 two 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 once a minute at rest, more often while moving or during an alert — sealed in the same way and through the same relay. Only they can read it — it passes through our relay to reach them, so we carry it and cannot open it — and it goes both ways. Closing the app stops it, with one exception: a paired person opening their own app, which asks this phone for its position for about fifteen minutes at a time. A student's phone sends nothing at all outside the school zone. Section 05 is the whole of that one.

And one thing travels the other way, from a guardian's phone to a student's. A guardian sets the school, the listening hours and whether the phone is armed on their own handset, and those settings are sent to the student's phone over the same sealed channel and the same relay. The student's phone applies them and sends no setting back. This is new since August 2026, and it is the reason section 04's windows are described as ones "the guardian set" rather than ones fixed at installation. A settings message carries no incident and no position; it says only that a guardian changed a setting.

09No 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.

10Children

ShotDetect is intended for secondary-school students aged 13 and over, and for their parents and guardians. It is not offered to children under 13. That is an architectural conclusion rather than a preference: the app reads a precise position and puts it in an unencrypted Bluetooth broadcast, which is not something we are willing to do for a younger child's phone, and the policies that govern apps for under-13s rightly do not permit it. This page said until August 2026 that use by a child under 13 required verifiable parental consent; the honest position is that it is outside what this app supports at all.

The person who accepts must be 18 or over, and must be the student's parent or legal guardian. They are the account holder; the student carries a handset. A student's phone is not protected until a guardian has connected to it and accepted the terms, so a student never agrees to this alone.

Since wording 0.21.0 the person accepting has to say so, and acceptance is not recorded until they do. The screen carries the statement "I am 18 or over and this student's parent or guardian", and the Accept button does nothing until it is ticked. No birthdate is asked for and none is stored: this is an assertion rather than a check, which is the record the Data Privacy Act's treatment of minors turns on and the one thing the receipt did not previously hold.

Raising the floor to 13 does not put students outside the law on minors, and we are not going to imply that it does. The floor removes two things and no more: the United States' COPPA, which reaches only children under 13, and Google Play's Families policy, which attaches when an app declares an audience below 13. Under the Data Privacy Act it removes nothing at all. A person is a minor in the Philippines until 18, so for every student between 13 and 17 the consent for processing their personal information still has to come from a parent or legal guardian. The guardian's acceptance above is that consent. It is how we comply with the Act's treatment of minors, not a way around it, and it does not stop applying on a student's thirteenth birthday. Section 12.11 sets out what follows from that.

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 readable by those guardians and by nobody else — it reaches them through our relay, which holds it sealed and cannot open it; 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 closing the app stops the position being sent, except during an alert. It does not stop everything: section 05 describes a note saying the phone has reached school or has left it, which is sent with the app closed and carries no position of any kind. Since 2026-08-29 there is one further exception, and a parent should know it exists before installing rather than afterwards. Since 2026-08-30 there is also a limit that runs the other way: a student's phone sends no position at all outside the school zone, and there is no switch for that and no way to widen it. A setting that shared a position all day, with the app closed, existed between 2026-08-29 and 2026-08-30 and was withdrawn. The exception is not a setting and this is the one to read twice: when a guardian opens the app, the phones they paired with share where they are with that guardian — and with nobody else — for about fifteen minutes, whether or not the app is open at the other end. There is no switch for that one, any paired person can cause it, and unpairing is the whole of the control; the phone that is sharing shows a notice for as long as it lasts, and that notice cannot be swiped away and is not removed by anything in the app that leaves the sharing running. We think both are reasonable things for a family who paired with each other to choose, and we think a parent is entitled to be told them in plain words before installing rather than to discover them.

The one address we hold ourselves is a tester's, given to us by email to join the closed test, which is now over. Anyone who joined had to be 18 or over — we never put a child's email address on any list. Our child safety standards describe this in more detail.

11The 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 nine 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 while somebody has the app open, from about once a minute at rest to about every two seconds during an alert, between people who paired with each other. It carries a guardian's settings on their way to a student's phone, a note saying that a phone has reached school or has left it, and a student's one-touch answer to an alert — "I'm safe" or "I need help", and nothing a person typed. Since 2026-08-29 it carries a sixth: a request from one paired phone asking another to share where it is, which carries a time and nothing else. Three more have been added since, and each has a paragraph of its own below. All nine are sealed the same way. Everything below applies to all nine unless it says otherwise.

This page said until August 2026 that the operator could not tell an alert from a position. That is no longer true, and the change is worth stating rather than dropping. Positions, place notes and requests are now written to a different address on the relay from alerts, replies and settings, so the operator can see that a message is not one of those three, and when it arrived. Everything but a settings message is still one length, so the relay still cannot tell an alert from a reply, or any of those three from each other. A settings message is its own size, so the relay can tell that one apart as well — it learns that a guardian changed a setting, and nothing about what the setting is or whether anything happened at a school.

What is sent to it. When your child's phone corroborates gunfire with at least two 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 nothing here can be told apart by its size. What can be told apart is the address: a position and a place note are written to one place on the relay, and everything else is queued at another. 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.

A seventh kind of message, from 2026-09-12, and it is the only one a person sends rather than a phone. When two phones agree that they heard gunfire, each of them may ask whoever is holding it whether they heard it too. The question is asked only on a phone that reported hearing that sound, and one phone is asked no more than once in any seven days, so most events ask nobody anything. The answer is yes, no, or nothing at all; a yes or a no leaves the phone, and a silence does not. An answer that leaves carries the time it was given, and no position, no sound and no words. It is padded to the same length as everything else here, so it cannot be told from an alert by its size — which matters more for this one than for most, because an answer only exists when something was heard.

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 two kinds of message are described anyway, because the list of what this channel can carry has to be complete to be worth reading.

An eighth kind of message, from 2026-09-13, and no family phone sends or receives one. A fixed listening device at a workplace — one an installer mounted and surveyed, that nobody carries — can report how loud a sound was where it stands, so that an alarm can say which floor it came from. That message carries a loudness, a floor number and a time, and no position, no sound and no words. It is sent only while an alarm is open and only to the phones at that same workplace. It is padded to the same length as everything else above, so it did not change the size of any message this app sends, on any phone.

A ninth kind of message, from 2026-09-13, and neither a family phone nor a workplace sends or receives one. A police officer's own handset can tell that officer's own agency that it heard gunfire near where it is standing, and it reaches that agency and nobody else. That message carries a time, a position and how accurate that position is, what set it off, how confident the detector was, and whether the officer cancelled it. It carries no name, no badge number, no call sign, nothing anybody typed and no sound. It does not say that the officer fired, and nothing in it could. A phone's microphone overloads well below the sound of a gun at the holder's own head, so a shot fired here and one fired thirty metres away arrive at it the same way, and there is no field here that could tell them apart. It is shorter than an alert and padded to the same length as everything else above, so it changed the size of no message on any phone, including every family's.

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 makes false alarms substantially rarer on that path than on the one shown inside the building. 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. The measured figures are on how it performs rather than here, so that they can be kept current as the detector changes instead of going stale in a policy document.

What the operator can see. A block of ciphertext, a random token, the size of the message, which of two addresses it went to, and the time it arrived. Everything but a settings message is one size, so it cannot read the position, the time of the event, the number of phones, or whether it was a drill. Since August 2026 it can see that a message is not a position, because positions and place notes are written to an address of their own; it still cannot tell an alert from a reply by length, or a position from a note that a child reached school. Length is the property that is guaranteed here, and it is the only one: the paragraph below sets out what the rate of a phone's messages still gives away. A guardian's settings message is a different size and is distinguishable as such — the operator learns that a setting changed, and nothing about what it is. 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 steady stream of messages is a phone with its app open, and the operator can see that much from the timing alone even though it can read nothing. Because the pace quickens when a phone moves and quickens again during an alert, the timing also says that much — the rate of unreadable messages is itself information. That is the price of the equal-length envelopes: they hide what is being sent, not that something is, or how often. Since August 2026 the pattern says more than it did: a position is written to its own address, so a request to the other one is known not to be a position, and can be timed. Positions, place notes and the requests described above share that address and are the same length, and the operator can tell them apart by how often each changes: a position every minute or two, a place note twice a day, and a request about every five minutes and only while somebody has a map open. That last rate is a disclosure the other two do not make — it says roughly when a family looks at each other, which is a fact about behaviour rather than about where anyone is, and we state it rather than leave it to be found. While the app is open the notes are lost among the positions, which are far more frequent. With the app closed and nothing happening they are not lost among anything, because then there are no positions at all — unless somebody paired has opened their map in the last fifteen minutes, in which case there are, and the notes are lost among them again. The rest of this paragraph describes the quietest case: nobody looking. A phone in a school bag writes nothing until it crosses the school boundary; it then writes the same note about seven times over the next hour, so that a guardian's phone that was switched off does not miss it. So the operator learns more than that a child is at school on a school day. From the timing of those bursts alone it can read the times a phone arrives and leaves, on the same weekday pattern, without decrypting anything. Set beside the IP address that any connection carries, that is a daily schedule attached to a rough location. We state it rather than let the encryption claim imply more than it delivers, and switching the note off for a paired person is what removes it.

There is one identifier, and it outlasts a session. 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 is kept for ninety days after the phone last used it, and every time the phone checks for messages the ninety days start again — so a phone in daily use keeps its token for as long as the app is on it, and a phone that stops asking loses it. While it is there, 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 across sessions, and calling it anything else would be dishonest. Deleting your data explains how to remove it sooner.

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. An undelivered message is held for ninety 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 for ninety days after the phone last used it. Every time the app checks the relay for messages it proves it still holds the private key that token is bound to, and the ninety days start again. A phone that has been uninstalled, wiped, or simply never opened again stops proving it, and the record is deleted with nobody having to ask — which is what finally makes uninstalling enough. An uninstalled app cannot ask us to delete anything, and it no longer has to. A guardian's phone still asks outright when it stops being a guardian — when the last paired student is removed, or the phone's role changes — and the record goes then rather than in ninety days. A student's phone has no equivalent button in this version; the expiry is what covers it. Asking outright has to be signed by the key the token is bound to, which means only that phone can delete it early, 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. That is no longer the whole answer, because there are three exceptions and closing the app stops none of them. The first 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. The second is the note saying the phone has reached school or has left it: it carries no position of any kind, and it is sent whether the app is open or not. That second one had a switch of its own until 2026-08-30 and now has none, because inside the school zone an arrival or a departure is the thing the app is for. The third is a paired person opening their own app, which shares this phone's position with that person for about fifteen minutes. The third has no switch either, so unpairing is the only way to stop it — and it is the one this paragraph exists to be honest about, because it is the only exception that somebody else can start.

11aIf 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 the disclosure is complete.

A workplace can run the same app over an office or a floor instead of a school. The people covered are adults in an employment relationship rather than children, so the consent is a different act: it is individual, informed, and given under section 12 of the Data Privacy Act rather than by a parent on someone's behalf. It is a separate in-app document with a version number of its own, and changing it does not disturb a family's.

A manager sees that you are covered. A manager never sees where you are. That is not a setting and there is no tier of the product that changes it. A member's phone does not send its position because it is inside the site, or because the hours are running, or because a manager opened an app. It sends a position only while a corroborated incident is open, and only because it heard something. No history of where a phone has been is kept anywhere, there are no arrival or departure notes, and there is no screen that shows where a member is. A manager's roster shows whether each phone is listening and whether its microphone is alive.

Everything in sections 01 to 07 above is the same on a workplace phone: sound is examined in memory, nothing is recorded, and the build check in section 02 is what makes that auditable rather than promised. Two limits of that check are worth stating where an employer's data-protection officer will read them — it covers the shared listening library and the parts of the app that handle sound, not every part of the app, and it reads Kotlin source only.

A site can offer its incidents to one named police agency, and nothing has ever been sent to one. A manager enrols the site; the enrolment always has an end date, cannot be written for longer than a year, and can be ended at once. Enrolling with a station does not enrol with a region or a national command. An incident reaches that agency only if all five of these hold:

• The site is enrolled with that agency at that moment.
• Two or more phones standing far enough apart heard the same sound.
• Two people who heard it answered yes.
• A manager released it, or the site set releases to go by themselves and no manager acknowledged in time.
• It is not a drill, unless that agency agreed to receive drills for an exercise.

When one of the five refuses an incident, the manager is told which one.

What is sent is the time, the shape of where the sound came from, the floor and area the site named, how many phones heard it, how many people said yes, and the manager's number. No sound, no name, no account, and nothing saying which phone heard what. It is held for thirty days and then deleted; what the agency keeps of its own copy is theirs, under their own law. Nothing records which person at an agency opened an incident, so a site cannot be shown that and we do not pretend otherwise.

This section said until 2026-09-13 that nothing could reach an agency because the question that asks a person whether they heard gunfire was not built. It was built on 2026-09-12, and a manager can enrol a site from the app itself as of 2026-09-13. What has not changed is the sentence that matters: no incident has ever been sent to any police agency, and no alert of any kind has ever come from a real gunshot. A manager's screen shows who at which agency has opened an incident from this site, because a site that consented to a feed is entitled to see what its consent was used for — and it shows a credential rather than a person, for the reason in the paragraph above.

12Philippines: the law this notice is written under, and what it entitles you to

ShotDetect's pilot is in the Philippines, and phones running it are in the Philippines, so the Data Privacy Act of 2012 (Republic Act No. 10173) applies to us — including section 4, which extends the Act to a controller who "use[s] equipment located in the Philippines" even when not established here. Sections 01 to 11 above describe what the app does. This section is the disclosure the Act itself requires, in the order it requires it.

Two sections of the Act do most of the work here, and both are worth naming so you can look them up: section 16, which sets out your rights and the list of things a controller must tell you before it processes your data, and section 12, which sets out the grounds on which processing is lawful at all. Section 34 of the Act's Implementing Rules and Regulations expands section 16 and adds the two items most notices omit — the lawful basis, and the right to object.

12.1  Who the controller is

The personal information controller is Llyr Labs, Philippines, contact@shotdetect.com. The Data Protection Officer's contact details are in 12.7. There is no other controller of what the app collects: it has no advertising network, no analytics vendor and no data broker in it. The workplace role is not available in the version on Google Play, and section 11a says so. An employer that runs a workplace site under section 11a is a controller of its own decision to run one, and of the site record it keeps — the boundary, the hours, the roster of devices. It is not given a location by us, because there is none to give.

12.2  What is processed, and how

Rather than repeat it here in different words — which is how two descriptions of the same thing come to disagree — the description required by section 16(b)(1) and (3) is sections 02 to 08 above, and section 03 of Deleting your data lists everything written to the phone. In summary: sound, examined in memory and never kept; this phone's position; a display name you choose; the people you paired with, their public keys and their routing tokens; and the settings a guardian sets.

Precise location is personal information under the Act, and it is not "sensitive personal information". Section 3(l) defines that term as a closed list — race, ethnic origin, marital status, age, colour, religious, philosophical or political affiliation; health, education, genetic or sexual life, offences and proceedings; identifiers issued by government agencies; and anything classified by law. Location is not in it. We say so plainly rather than describing location as "sensitive" for emphasis, because the classification decides which lawful basis is available and what has to be registered, and getting it wrong in the flattering direction is still getting it wrong.

12.3  The lawful basis for each thing we process

Section 34(a)(2)(c) of the IRR requires the basis to be stated wherever processing is not based on consent. Ours:

• Consent — section 12(a). Reading the microphone and reading this phone's position. A guardian accepts the in-app terms on the device before the phone will listen, the accepted wording carries a version number so you can establish what you agreed to, and the permissions are granted separately by Android. Consent can be withdrawn: turn protection off, remove a pairing, revoke the permission in Android's settings, or uninstall. Sharing a position because a paired person opened their app has no consent of its own, and we say so rather than imply one: it rests on the consent above and on the pairing itself, it has no switch, and it is withdrawn only by removing the pairing.
• Contract — section 12(b). Carrying an alert or a position between two phones that paired with each other. That is the service you asked for, and it cannot be performed without doing it.
• Legitimate interests — section 12(f), for the small amount of relay bookkeeping that is nobody's idea of a feature: a routing token bound to a public key so that a message can be addressed at all, a delivery receipt so a sending phone can answer "did it arrive", and rate limiting so that one phone cannot deny the relay to every other family. The specific interest, which the Act requires us to name rather than gesture at (NPC Circular 2023-07, section 5(C)): operating a reliable and abuse-resistant delivery path for life-safety messages. We assessed it as required — purpose, necessity, and a balance against your rights — and the balance is helped by the fact that none of that bookkeeping can be tied to a person: it is an opaque token, and the relay cannot read what it carries.
• Protection of vitally important interests, including life and health — section 12(d), for the delivery of a corroborated alert itself. We state it as an additional basis rather than the primary one, because consent and contract already cover the ordinary case; it is here for the case where an alert is in flight and a question is later asked about whether it should have been.

We do not rely on section 13 (sensitive personal information), because we do not process any. We do not rely on section 12(e) (national emergency, public order, public authority): ShotDetect tells no school and no emergency service, and it acts for no public authority.

12.4  Recipients

Section 16(b)(4) requires the recipients or classes of recipient to be named. They are:

• The people you paired with — by scanning each other's QR code, or by an invite code sent to them and pasted within five minutes, and either way only once both phones showed the same confirmation code. They receive alerts and positions, and only they can read them. There is no directory, no search and no way for anyone else to be added.
• Us, as the operator of the relay — which carries every alert, every position, every settings message, every note that a phone reached school and every request from one paired phone asking another where it is, all of them sealed. We hold ciphertext under an opaque token and have no key. We are a recipient in the sense the Act means, and section 11 is the whole of what we can see.
• Anything in Bluetooth range, for the detection broadcast. It is unencrypted by design (section 08), carries a position and nothing that identifies a person.
• Our processors, listed in 12.6.
• Nobody else. Your information is not sold, not shared for advertising, and not disclosed to any authority except where a law compels it — in which case we would tell you unless the law forbade us.

12.5  How long things are kept

Required by section 16(b)(7). On the phone: until you delete it or uninstall. On the relay: an undelivered alert for ninety minutes; a position, a note that a phone reached school, or a request from a paired phone asking where this one is, held for fifteen minutes; a delivery receipt for twenty-four hours; the token-and-public-key record for ninety days after the phone last used it, restarting each time it does. Deleting your data is the detail.

12.5a  How it is protected

Section 20 of the Act requires reasonable and appropriate organisational, physical and technical measures, and NPC Circular No. 2023-06 sets out what the Commission expects those to look like. This section is that statement. It was added on 2026-09-20; the measures themselves are older than the section, which is the honest way round to say it.

Technical.

• Sound never leaves the phone at all. This is the first measure rather than the last, because the most sensitive thing this app touches is the one thing it never transmits. It is enforced in the build: source guards fail the build if anything in the audio path so much as imports a file or network class, and a separate audit fails it if one file holds both a capture marker and a way to send. Those are guards on our source code. They are not a proof about the compiled app, and we will not describe them as one.
• Everything the relay carries is sealed before it leaves the phone — AES-256 in GCM mode, under a key the two paired phones agree between themselves by P-256 ECDH when you pair, put through SHA-256 with a label naming the protocol and its purpose. We hold ciphertext under an opaque routing token and no key, so the measure that protects an alert from us is the same one that protects it from anyone else.
• The Bluetooth detection broadcast is authenticated with a truncated HMAC-SHA256 tag, and the older unauthenticated format is refused outright rather than accepted for compatibility. It is still unencrypted by design — section 08 says why, and that is a deliberate trade, not an oversight.
• There is no account to breach. No email address, no phone number, no password, no persistent device identifier. A relay record is a random token, a public key and sealed bytes.
• Every connection to the relay and to this site is over TLS, and the app pins its own expectations of what it is talking to.

Organisational. A Data Protection Officer is named in 12.7 and is a real person you can write to. Breaches are handled as 12.10 describes, including the Commission within 72 hours and — where a child's information is involved — the child and their parent or guardian both. What we keep and for how long is 12.5, and nothing is kept indefinitely: every item on the relay has a stated life and is deleted at the end of it whether or not anyone asks. Our processors are named in 12.6 and are engaged on terms requiring protection comparable to what the Act requires of us.

What we have not done, said here rather than left for you to find. No independent security audit and no penetration test has been carried out against the relay or the app. The measures above are ours, described by the people who built them, and 12.12 applies to this section as much as to the rest. A school or employer weighing this app should read that sentence as it is written.

12.6  Data processed outside the Philippines

Section 21 of the Act makes us accountable for personal data we transfer, "whether domestically or internationally", and requires us to use "contractual or other reasonable means to provide a comparable level of protection". The Act does not restrict the transfer; it makes us answerable for it, and it requires us to tell you it happens. It happens:

• Vercel — hosts this website, the relay's serverless functions and the school-search and map proxies. Receives the IP address of a connecting phone, an opaque routing token and ciphertext, and — since August 2026 — the school name typed into the search box and the map squares being viewed.
• Upstash — the managed database the relay stores queued messages in, where the school-search cache is held, and where a closed-test email address is held. Receives the same ciphertext and tokens; the email address is the one item of ordinary personal information here.
• OpenStreetMap Foundation — map tiles, and the Nominatim school search. Receives the map squares being viewed and the school name typed into the search box. This entry said until August 2026 that it also receives the phone's IP address. It no longer does — those requests go through our own server, so the Foundation sees that server's address. Governed by their privacy policy.
• Titan and Resend — email delivery for the closed test only. Receive an email address in order to send to it.

Servers for the first two are outside the Philippines. We remain accountable for your data in their hands, and each is engaged on terms requiring protection comparable to what the Act requires of us.

12.7  Our Data Protection Officer

Section 21(b) of the Act requires us to designate someone accountable for compliance, and NPC Advisory No. 2017-01 requires their contact details to be published — in the privacy notice specifically, with a postal address, a telephone number and an email address.

12.8  Your rights, and how to use them

Section 16 of the Act, as expanded by section 34 of its IRR. All of these are free to exercise, and we will not treat a request as a reason to stop serving you.

• To be informed — whether we are processing your data, and, before we start, everything in 12.1 to 12.6. This section is that disclosure.
• To object — to processing, including to automated processing and profiling, and to be asked again if this notice changes materially.
• To access — a copy of what we hold, its sources, who it has been disclosed to, how it was processed, and when it was last accessed or changed.
• To correct — to dispute anything inaccurate and have it corrected.
• To erasure or blocking — to have data suspended, withdrawn, blocked, removed or destroyed where it is incomplete, outdated, false, unlawfully obtained, used beyond the purpose you were told, or simply no longer necessary; and where you withdraw consent and no other ground applies.
• To damages — to be indemnified for damage suffered through inaccurate, incomplete, outdated, false or unlawfully obtained data.
• To data portability — section 18: a copy of data we process electronically, in a structured, commonly used format you can take elsewhere.
• Transmissibility — section 17: your lawful heirs and assigns may exercise these rights after your death, or while you are incapacitated.

How to ask. Write to the Data Protection Officer at the email address in 12.7. There is no form to use. Tell us what you want and enough for us to identify the data — we will ask you to verify who you are before we act, because acting on an unverified request about somebody else's child would be the worse failure. A parent or guardian may exercise a minor's rights, with proof of that relationship.

What we can and cannot do, stated honestly rather than optimistically. Most of what this app holds is on your own phone, where you can read, change and delete it directly and we cannot reach it at all. On the relay, the only thing we hold about anybody is an opaque token, a public key and sealed bytes — we cannot tell which token is yours, which is the same property that stops us knowing anything about anyone, and it cuts both ways. A request to delete a relay record has to be signed by the phone that owns it, which is what the in-app control does. Deleting your data is the step-by-step, including what uninstalling reaches and what it does not.

12.9  If we get it wrong: complaining to us, and to the National Privacy Commission

Write to us first, and this is not us protecting ourselves. The Commission will not take a complaint unless you have told the respondent in writing and either got no response within fifteen calendar days or got one that did not fix it — and you have to attach proof of that to your complaint. So a first letter to the DPO in 12.7 is the step that makes an NPC complaint possible, not the step that delays it. We will answer.

If we do not, or if our answer is wrong, you may complain to:

The Commission moved offices in 2026. If you find an older address for it on any page of ours, the one above is the current one and the older one is a mistake we have not yet caught.

12.10  If there is a data breach

Governed by NPC Circular 16-03. Our commitment, which is what that circular requires of us and not more than we can do:

• Where a breach involves data that could enable identity fraud, we have reason to believe it was acquired by someone unauthorised, and there is a real risk of serious harm, we will notify both the National Privacy Commission and you within seventy-two hours of knowing or reasonably believing it has happened.
• Where the breach affects at least a hundred people, or the disclosure would harm someone, we will not delay that notification at all, and a full report follows within five days.
• The notice to you will say what happened, what data was involved, what we have done about it, what we are doing to reduce the harm, who at Llyr Labs you can ask for more, and what help we can give. It will come to you individually, by a secure route.
• Where the person affected is a minor, we will notify both the student and their guardian, in language the student can read. That is NPC Advisory 2024-03, and it is the right rule.
• We will document every security incident whether or not it is notifiable, and file the annual summary the rules require.
• Because relay payloads are sealed on the sending phone with a key we never hold, a breach of the relay exposes ciphertext, tokens and IP addresses — not positions, not alerts, not names. That is the point of the design, and it is not a reason we would decline to tell you.

12.11  Students under 18

Philippine law sets no age of digital consent — the Commission has said that establishing one would take an Act of Congress — so there is no bright line to point at here. What applies instead is NPC Advisory No. 2024-03 on child-oriented transparency, which covers any product "likely to be accessed by children", and this one plainly is.

What does have a bright line is minority itself. Article 234 of the Family Code, as amended by Republic Act No. 6809, sets the age of majority at 18. A student of 13 to 17 is therefore a minor who cannot give a valid consent of their own, and the consent relied on for their personal information is their parent's or legal guardian's. That is the position whatever minimum age we set, and it is why the terms require the acceptor to be 18 or over — and, since wording 0.21.0, why the acceptance screen asks them to say so — rather than treating a 13-year-old as able to agree for themselves.

What we do:

• A guardian must accept on the device before a student's phone will listen, and that gate is enforced in the app rather than merely asked for.
• The acceptor must state, on the screen where they accept, that they are 18 or over and the student's parent or guardian. Acceptance is not recorded without it. That part is an assertion rather than a check: the app asks for no birthdate and cannot see who is holding the phone, and this list said until 2026-09-11 that the age itself was enforced, which it never was.
• The app is not offered to children under 13 (section 10).
• No setting on a student's phone shares anything with anyone the student did not pair with.

Outside the Philippines. If this app is ever distributed in the European Economic Area, Article 8 of the GDPR sets the age at which a child can consent to an information society service at 16, and member states may lower it to as far as 13. The age is therefore 16 in Ireland, Germany and the Netherlands, and 13 in Denmark, Sweden and Finland, among others. Raising our floor to 13 does not clear Article 8 in the states that chose 16. What answers it is the same fact as above: the consent we rely on is given by the holder of parental responsibility, which is what Article 8(1) requires where a child is below the applicable age. We have not completed an EEA distribution assessment, and this paragraph is a statement of the architecture rather than a claim that the assessment is done.

Two things the Advisory asks for were outstanding until 2026-09-20, and both are now done. It requires a separate child-friendly version of this notice alongside the standard one — that is Your privacy, in plain words, written for the students who use the app. And it requires a documented Child Privacy Impact Assessment before launch; one now exists. It is a first-party assessment that has not been reviewed by counsel, and section 12.12 applies to it as much as to this notice. The Advisory also expects geolocation to be off by default on a child's account unless it is necessary for the specific purpose — for this app it is the purpose, the app cannot corroborate a gunshot without it, and a guardian arms it deliberately rather than finding it already on. That argument is about corroboration, and between 2026-08-29 and 2026-08-30 it did not stretch to an all-day sharing setting that was a convenience rather than the purpose. That setting was withdrawn on 2026-08-30 and the question goes with it: a student's phone now sends a position only inside the school zone, which is the narrowest reading of the Advisory's rule rather than an argument against it.

The other thing added on 2026-08-29 cannot be held to that rule, and we would rather say so than let the paragraph above cover it. A phone shares where it is while a paired person has their app open, and that is not off by default — there is no default to set, because there is no switch. It is bounded instead: about fifteen minutes at a time, to the one person who is looking and nobody else, ending by itself when they stop, gone entirely when the phone restarts, and never to anyone the student did not pair with. And the child's phone shows a notice for as long as it runs, which is the one thing a switch would not have given them — a child can see it happening rather than having to remember a setting. That notice cannot be swiped away, and nothing in the app removes it without also ending the sharing. We stop the claim there, because that is where our own testing stopped: it is an ordinary app notification, and a phone's own notification settings are outside any app's control. What we can say about those settings is that they are the ones every alert arrives through, so switching this app's notifications off is not a way to hide this notice and keep the app doing its job. We think that is the right trade for a family who paired with each other, and it is a trade, not a compliance with the Advisory's expectation.

12.12  What this section is not

It is a privacy notice written against the Act and the Commission's circulars, by the people who built the app, and it is pending review by counsel. Everything in it about what the app does is checkable against the app. Nothing in it is legal advice, to you or about us, and where it and the Act disagree, the Act wins.

13Changes 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.

14Contact

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