Permissions are not a small click at the start. They show how an app is built. Microphone, camera or local-network access can fit a baby monitor when the reason is clear. Location, contacts or ad IDs without an obvious need should make parents cautious.
| Permission | Plausible when … | Concerning when … |
|---|---|---|
| Microphone | The baby device needs to send live sound | The app cannot explain why it needs it now |
| Camera | Video is a real and optional feature | Video is not central, cannot be disabled, or is requested preemptively |
| Local network | The app clearly supports local discovery or same-network setup | No explanation is given for why local-network access matters |
| Location / contacts / ad identifiers | Only in rare cases with a very strong reason | Usually, because they do not fit the core monitoring task |
Role logic
Which permissions fit which role?
Baby device
Microphone almost always, camera only for video, and possibly local-network access for local pairing.
Parent device
Often needs less: audio output, notifications, and possibly microphone access for push-to-talk.
Optional features
Video, push-to-talk or local discovery justify extra rights only when those features are visibly used.
Timing matters as much as the permission itself
Android and iOS both expect protected resources to be requested in context. For parents, that means a serious baby monitor app explains the device role first and asks for microphone or camera afterwards. If everything is requested on first launch, that may be convenient for the app, but it is bad for trust.
The dialog text matters too. “This device needs microphone access to send sound from the nursery” is understandable. “Please grant access” without context is not enough. In a nursery, permissions should be taken seriously in the wording as well.
Android and iOS differ, but the core question is the same
Android
Android guidance emphasizes runtime requests, context, and checking whether a permission is still genuinely needed. Battery optimization often becomes part of the real-world story as well.
iOS
Apple treats microphone, camera, and local-network access as protected areas with explanation-heavy system prompts. The principle is the same: access can be reasonable, but it must be justified.
Extra permissions are often the clearest red flag
Parents should pay attention when a baby monitor app asks for location, contacts, ad IDs or other rights that do not belong to the core product. Not every extra permission is automatically wrong, but it needs a concrete reason. The more general the explanation, the weaker the signal. For family and child-related products, the bar should be higher than for ordinary lifestyle apps.
Another warning sign is mixing the core function with extras. If a simple audio monitor suddenly wants many kinds of system access, the app may be pursuing more goals than parents expect.
How to spot problematic permissions
it is often reasonable — such as microphone on the baby device or camera for opt-in video.
parents should push harder before trusting the request.
the product probably is not thinking cleanly in device roles and scenarios.
Permission checklist before installation
- Does every requested permission map clearly to a visible feature?
- Is the request made in the right moment rather than all at once?
- Do the baby and parent devices plausibly need different rights?
- Do extra permissions such as location or contacts really make sense?
- Is video optional, or does the app turn camera access into a default state?
Sources and further reading
- Request app permissions · Android Developers
- Requesting access to protected resources · Apple Developer Documentation
- NSLocalNetworkUsageDescription · Apple Developer Documentation
- MediaDevices: getUserMedia() · MDN Web Docs
- Families policy requirements · Google Play Help
- Authenticate with Firebase anonymously · Firebase Documentation
- Babyphone Timmy security and architecture · Babyphone Timmy
- Nani: The safest baby video monitoring app · Nani