Privacy Policy

EarHorn Privacy Policy. Learn how EarHorn handles your information.

Effective date: October 4, 2026

Braeside Dev LLC ("Braeside Dev") built EarHorn as a baby monitor app. This policy describes how the EarHorn iOS app handles your information. This Privacy Policy is governed by and subject to the Terms of Service, including the governing law and dispute resolution provisions therein.

The Short Version

Braeside Dev receives nothing from the app directly. Apple sends us standard counts of purchases and installs of each build. On the App Store those say nothing about who you are; on a TestFlight beta they can, and there is a section about that below. Apple may receive some individual information through CloudKit, but it is limited to encrypted blobs and metadata, and Apple presumably also knows that you bought the app at all. The app is a baby monitor and works like one: it shares audio, and information about that audio, with the devices you have paired. It is built to limit what a third party on your local network can learn, balanced against what that costs in battery, processor and bandwidth on every device involved. If you do not trust your network, use a tailnet; and if you do not trust that, we cannot make any promises.

Data Collection

Braeside Dev does not collect, receive, or have access to any personal information through EarHorn. The app does not require an account and does not ask for personal details such as your name or email address. The app stores limited data locally on your devices and in your own iCloud account, as described below.

Device Identifiers

EarHorn generates a random device identifier (UUID) on first launch so that paired devices can recognize each other. It is stored in the iOS Keychain on your device and is not transmitted to Braeside Dev. It is shared with devices you pair with. Reconnecting to a device you have already paired with does not put it on your network, and neither does pairing, by QR code or with the 8-character code, where it travels encrypted. Pairing with the 8-character code does put something else there, and only on the baby device: for the few seconds that pairing takes, one of the baby device's public keys is readable by anything else watching your local network. A parent device never puts its own on the network this way, whichever of the three you use. Nothing can be read from the key, but it would let a watcher recognise that baby device later. The baby device answers that by trying to replace the key as soon as the pairing finishes, usually within seconds, so the key a watcher saw stops being the one it signs with. If one of your paired devices is switched off or away, that replacement waits for it.

Under some settings, and in some situations, a baby device does announce its presence on your local network, so that a parent device can find it. Out of the box the app decides for itself: the baby device stays silent while iCloud can carry its connection details to every parent you have paired, and announces itself whenever one of them could not be reached that way. In the app's settings you can tell it to announce whenever the app is running instead, or to stay quiet.

It also depends on what you are doing at the time. Even on the quietest setting, showing the 8-character pairing code puts the baby device on the air for as long as that code is up, because announcing itself is how the parent device finds it. Showing a QR code does not: the QR already carries the address and the port the parent device needs, so there is nothing to announce. When the baby device does announce, what goes on the air is a rotating tag that changes roughly every hour and means nothing to anyone without the matching key. Your device identifier is not in it.

The identifier is cleared by the factory reset in the app's settings. Unpairing does not clear it, and the app cannot make promises about what happens as it is deleted.

Cryptographic Keys

EarHorn generates P-256 cryptographic keys for device authentication. These keys are stored in the iOS Keychain with protections that prevent them from being synced to iCloud or backed up. The factory reset in the app's settings deletes them, along with everything else EarHorn has put in the Keychain on that device. The app cannot make promises about what happens as it is deleted, so the reset is the one to rely on.

The Name You Give a Device

You can name each device, which is how you tell one room from another. The name is stored in the Keychain on that device. It is only ever communicated between your own devices, encrypted end to end, and it is not sent to Braeside Dev.

Pairing

Pairing two devices uses either an 8-character code the baby device shows, or a QR code you scan with the parent device. The QR code is the quieter of the two: the baby device does not announce itself on the network while showing it, does not turn on the peer-to-peer radio for it, and tells the parent device who it is only in encrypted form. All three of those are true because the code itself carries what the parent device needs. Typing the 8-character code instead sends the baby device’s public key across the network readable, with a one-time stand-in in place of its identifier; who it is travels only once the connection is encrypted. The QR code can also be shared as a link, by AirDrop, message, or any other app you choose. That link contains a one-time secret, a key, and the baby device's network addresses so the parent device can find it, and it expires after fifteen minutes. If you send the link through another app, that app handles it like any other message you send, so send it the way you would send anything else you would rather keep to yourself.

Audio and Device Communication

EarHorn streams audio directly between your paired devices using Apple's Network framework, over your local Wi-Fi network. If you have set up a VPN or overlay network such as Tailscale, the app may also try to reach a baby device over that. Audio is encrypted end to end between your two devices with a key that is unique to each connection. EarHorn does not write audio to disk. It is held in memory, sent, played, and dropped, and none of the app's audio code touches a file at all. What we cannot promise is what iOS itself does with audio we hand to it, or that it hands to us: the operating system's own audio stack, and any Bluetooth device you have connected, are not ours to see into. EarHorn does not transmit audio to Braeside Dev, to Apple, or anywhere else other than the devices you have connected. If the audio travels over an overlay network, that network's own relays may carry the packets; they stay encrypted the whole way.

When in baby mode, the app accesses the device microphone continuously to detect sound above your configured threshold. Audio is only streamed to paired parent devices when the threshold is exceeded. Because the app only sends audio when the room is noisy, someone watching traffic on your network could tell when sound was detected, though not what it was.

If a Bluetooth headset or speaker is connected, iOS may route capture or playback through it, the same as any other audio app.

Finding Each Other Without a Network

There is a third way your devices can reach each other: Apple's peer-to-peer radio, which uses Bluetooth and a direct Wi-Fi link rather than the network you are on. It is used in two situations. The first is while you are pairing with an 8-character code, when the app turns it on whatever your settings say, because two phones being set up side by side may have no working network between them yet. Pairing with a QR code does not turn it on, since the code already carries an address. The second is if you ask for it: in the app's connection settings you can let the phones keep searching for each other directly, which is for two phones that cannot share a network or for reconnecting when the Wi-Fi drops. That part is off unless you turn it on, and it costs battery on both phones. Audio over this path is encrypted exactly as it is over your network.

iCloud and CloudKit

EarHorn uses Apple's CloudKit service for two things: to deliver alerts when the parent app is in the background, and to pass connection details between your paired devices over a secure channel, so a parent device can find a baby device without the baby device announcing itself on a network, or when the two are not on the same network at all. Each device keeps its own records in its own owner's iCloud account, in a private area shared with the devices it is paired to, so a pairing has an area on each side. Noise alerts are the exception: those are written only by the baby device, into its own area. Braeside Dev does not have access to your CloudKit data.

You can turn iCloud off entirely in the app's settings. It is not a free privacy win. You lose alerts while the parent app is not connected, and the baby device falls back on announcing itself on the local network, because that becomes the only way a parent device can find it.

Noise alerts carry nothing but metadata. When sound is detected, the app writes a record with no content of ours in it at all. That the record appeared, which accounts it is shared with, and the time iCloud stamped on it are the whole message. That is metadata, and it is still information. The room name you see on the lock screen is filled in by your own phone, from its own stored list of paired devices; the room name never travels through Apple's push system.

The device record is encrypted. Each of your devices publishes one record per pairing describing itself, so there are two records per pairing, one per device in the pair. Each holds information like its identifier, the app version it is running, the oldest app version it can still work with, its battery level, the alert interval you chose, and similar settings. That is an illustration, not a closed list; what it holds follows what the app needs to tell your other devices. All of it is encrypted into a single sealed blob that only your paired devices can open. Apple cannot read it and neither can we.

Network addresses, two ways. Whenever two of your devices are connected to each other, the baby device tells the parent where else it can be reached, over the encrypted connection, whatever your settings say. That is how a parent device finds it again later, and no setting turns it off.

Separately, those addresses can be kept in iCloud, so a parent device can look them up while the two are apart. That is so a parent can find the baby device without the baby device having to announce itself on a network, and so it can find it when the two are not on the same network at all. A fresh install has this on, publishing both kinds of address: the ones that only mean anything on the Wi-Fi network the device is on, and any VPN or overlay addresses. In the app's settings you can narrow it to one kind or the other, or keep nothing in iCloud at all. The record is sealed the same way as the device record. What the local addresses reveal, to the people you have shared with, is the shape of your home network.

The unpair notice. When you unpair a device, this phone writes one last record into the area it shared with that device, to tell it the pairing is over. The record is empty. That it turned up, and which area it turned up in, is the whole message: the other phone stops expecting this one and says so on screen. It does not change what either phone trusts, which is a decision each one makes for itself.

What Apple can still see. Sealing hides what is inside a record, not that it exists. Apple can see that your iCloud account holds EarHorn records, which accounts you have shared them with, and when records are written, which is a rough record of when alerts happened and when the app was in use. Apple presumably also knows that you bought EarHorn at all, since you bought it from Apple.

The app attempts to delete old noise records as it writes new ones. That happens per paired device, so assume several of the most recent records still exist at any time. The app also attempts to delete its CloudKit data when you unpair devices. None of that is a guarantee: assume records may persist in your iCloud account until you unpair devices or remove the app's data from iCloud yourself.

The Build Check

On launch, EarHorn reads a single public record from Apple's CloudKit that says which app version is the oldest one still supported, so the app can tell you when it is too old to work properly with your other devices. It carries nothing about you, and works whether or not you are signed in to iCloud. It does say which release channel this copy came from, because a beta and an App Store build read a different record. It is still a request to Apple, so Apple sees that a device somewhere is making it. You can turn it off in the app's settings.

If You Are Testing a Beta

Beta builds are distributed through Apple's TestFlight. To install one you give Apple an email address, and Apple tells us which testers installed which build and shows us the crash reports and any feedback you send through TestFlight. That is Apple identifying you to us by name and email, which is the one place this app has anything user-specific about you at all. It comes from TestFlight, not from EarHorn, and the App Store version works differently: there we see counts and nothing else.

The Connection Log

EarHorn keeps a diagnostic log on your device to help work out why a connection failed. It is stored privately in the app, is excluded from device backups, and is capped at about a night's worth before the oldest entries are dropped. It contains no audio, no device names and no keys: connection events, error codes, and per-minute counts including sound levels in decibels. Devices are written as a four-character label derived from the device identifier, not the identifier itself. It cannot be turned back into one, but it is the same label for the same device every time, so a reader with two of your logs can tell that the same device appears in both. Read together over a night, those levels are a rough record of when a room was noisy.

The log stays on your phone unless you choose to export it from Settings and send it somewhere. Sharing it is always your action, and where it goes is your choice. It exports as a plain text file, so you can read every line of it before you send it, and edit out anything you would rather not send.

Data Retention

Analytics and Tracking

EarHorn does not include analytics, advertising, or third-party tracking. There is no code in the app that reports anything to us. Apple gives us the sales and install counts it gives every developer, which say how many people downloaded which build. On the App Store that is all it says. Beta testing through TestFlight is different, and has its own section above.

Children's Privacy

EarHorn is designed for use by adult caregivers aged 18 and older, not by children directly. While the app captures audio that may include children's voices, this audio streams exclusively between the user's own paired devices. Braeside Dev does not collect, receive, store, or have access to any audio data, including children's voices, and does not knowingly collect personal information from children under 13.

California and State Privacy Rights

EarHorn does not sell or share personal information as defined under the California Consumer Privacy Act. Because EarHorn does not collect personal information beyond locally-stored device identifiers, the rights to know, delete, and opt out under state privacy laws are addressed by the app's design: there is no personal data held by Braeside Dev to disclose, delete, or stop selling.

Changes to This Policy

If this policy is updated, the revised version is published at https://earhorn.app/privacy/ with a new effective date, and the next update of the app carries it. When an update carries changes to this policy that Braeside Dev considers substantial, the app asks you to accept it before you can continue, which is how Braeside Dev gives notice of substantial changes to how the app handles your information, consistent with the Terms of Service.

Contact

If you have questions about this policy, or wish to ask about or exercise any rights you may have regarding your information, contact Braeside Dev at info@braesidedev.com, via the contact information listed on the App Store, or by mail at the address listed in the Terms of Service.