No audio is ever recorded or stored, anywhere in the stack. There is no server-side buffer, archive or transcript, and no code path that writes an audio payload to storage. Your email address is the only personal information we collect, and we collect it only to log you into your account.
This page describes what the OpenPOC service actually does with data, as read out of the code that runs it. It describes measured behaviour, not intentions.
Your account: an account number, your email address, your account status, your quota and push-to-talk settings, and the times your account was created and last signed in.
Your channels and radios: for a channel, its name and its audio and push-to-talk settings. For a radio: its radio code, its public key, any name and note you give it, its own settings, hashed hardware identifiers, the model number, manufacturer, hardware name and build fingerprint the device reports about itself, and the times it was created and last seen online. Which radio belongs to which channel is held as numbers only.
Usage and balance: per radio, per day, how many bytes it carried and how they were charged, and any prepaid balance credited to your account. Counts and amounts only -- no content of any kind. We do not run a payment processor and we hold no card or bank details.
If you set a picture for a radio, that one image is stored. Images are the only media we store.
When a radio first registers it sends its own generated public key, its app version, a signature, hashed hardware identifiers, and plain details of the device it is running on: its model number, manufacturer, hardware name and build fingerprint. The hashed identifiers are used only to block abuse of the service. The device details are stored with the radio, and the model number is shown back to you in your own radio list, so you can tell your radios apart.
When it connects it sends its radio code, a nonce, its app version, and a signature. Once connected it sends channel traffic: floor requests, the repeated refresh that keeps the floor while it is transmitting, floor releases, a repeated note that it is waiting to talk while another radio is transmitting and a matching note when it stops waiting, roster and configuration requests, a liveness ping, and the WebRTC session descriptions that set up audio. Those session descriptions are produced by the device's own media stack and carry the network addresses of the device's local interfaces, which is how audio gets routed to it. The client asks for one sensitive Android permission, RECORD_AUDIO, and that audio is transmitted live to the people on your channel -- never to us, and never to storage.
Signing in uses Google, and we request only the openid email scope. The only field we read back is your email address, and we require Google to have marked it verified. Your session is a cookie holding a timestamp, your account number, and a signature. The signature covers a fixed label for this cookie format, that timestamp, your account number, and the time your account last signed in -- and that last value is never itself put in the cookie. The cookie is marked HttpOnly, Secure and SameSite=Lax, and it lasts up to 30 days of inactivity, refreshed as you use the site.
Audio is not end-to-end encrypted, and we will not imply that it is. Each leg of the audio path is encrypted in transit with DTLS-SRTP, so no on-path observer can listen in. But the audio is relayed through a media relay run by our hosting provider -- the same company that runs the servers, the database and the object storage, not a separate third party -- and a relay of that kind necessarily decrypts and re-encrypts each leg it forwards, so that provider is technically able to access audio in transit. Our own servers never carry audio at all -- they carry sign-in, provisioning, signalling and floor control only.
The Ed25519 keys in the system are used to sign messages, so that a radio and the server can each tell that a message is genuine and has not been replayed. They are not used to encrypt anything, and they do not make voice private from the relay.
The service writes operational logs. A log line can record a radio code, channel activity, and the connecting IP address. No email address is written to a log, and no audio is ever logged. These logs are held by our hosting platform under its own retention settings rather than by anything in our code.
You delete your own account from your admin page: open the settings gear in the top right corner and choose to delete your account. You are asked to confirm before anything is removed.
Every radio and every channel you own is deleted, and the hardware identifiers held against those radios go with them. Your account row itself stays: your email address is overwritten with a one-way hash of itself, which we keep so that the same address cannot be used to open another account. Your usage counts and any prepaid balance records stay too, linked to that account row. Stored pictures are deleted for radios that were assigned to a channel; a picture for a radio you never assigned to one can remain in storage. If a device of yours has been blocked for abusing the service, we keep that block, together with the account and radio code it was recorded against, the date and a note. Operational logs already written are not edited afterwards, and expire on the platform's own schedule.
Each radio's private key is generated on the device and never leaves it. Control messages are signed rather than password-authenticated, so there is no account password stored on the server to be stolen. Traffic to the site and to the servers is over HTTPS, and audio legs are encrypted in transit as described above.
If what the software does with data changes, this page changes with it. Material changes will be reflected here rather than announced separately.
We do not publish a contact address for this free service. Deleting your account and its data is self-service, from the settings gear on your admin page, and that is the only channel for it.
For how the system works technically, see /about.