Daniel sent us this one — he's been thinking about the gap between obsessive baby tracking and what he actually needs as a parent. He's not interested in logging every milliliter of formula. What he wants is a secure, purpose-built place to store the occasional photo, video clip, or audio recording of something he might need to show a pediatrician — a weird rash, strange behavior, something that makes him go "should I be worried about this?" The problem is that this material is sensitive. You don't want it commingled with your regular camera roll, and you definitely don't want it popping up when you're showing someone vacation photos. He's asking if there are any Android apps or cloud services built specifically for this — a secure, separate container for medical observations of a child.
This is such a specific, well-framed gap. And it sits at this weird intersection of three industries that barely talk to each other — pediatric telemedicine, consumer photo storage, and health data compliance. None of them have built exactly this thing.
Which is surprising, because every parent I know has a folder on their phone that's basically "weird stuff to ask the doctor about." It's just that the folder is usually the camera roll, and the privacy strategy is prayer.
And prayer is not a security protocol. Though I suppose it's technically an ancient one.
The original two-factor authentication. Something you know, something you hope.
Let me start with what actually exists, because I spent some time digging into this. There are three categories of apps that get close, and each one misses the mark in a specific way. The first category is the baby tracker apps — Huckleberry, Baby Connect, Baby Tracker, Glow Baby. These are the ones Daniel explicitly doesn't want, and for good reason. They're built around feeding schedules, diaper counts, sleep duration. Most of them do allow photo attachments to entries, but the photo is secondary — it's pinned to a feeding log or a diaper entry. It's not the primary object. And the privacy model on these is all over the place.
When you say all over the place, how bad are we talking?
Baby Connect had a well-documented incident back in twenty nineteen where researchers found that user data — including photos — was accessible through unsecured API endpoints. They fixed it, but the architecture wasn't designed with medical-grade privacy in mind. Glow's privacy policy, as of their most recent update, explicitly reserves the right to use aggregated and de-identified data for research. Which is probably fine for feeding patterns, but feels different when the data includes photos of a rash in a sensitive area.
"De-identified rash photos" is a phrase that should not exist.
Yet here we are. The second category is the general-purpose secure photo vaults — apps like KeepSafe, Photo Vault, LockMyPix. These are built for hiding photos behind a PIN or biometric lock. They solve the commingling problem. Your medical observation photos live in a separate encrypted container, they don't show up in your main camera roll, they can't be accidentally shared.
That sounds like it mostly works. What's the catch?
The catch is that these apps are marketed as privacy tools for hiding things — and the implication, fairly or not, is that the things being hidden are intimate photos or sensitive personal material you don't want a partner or employer to see. The entire user experience is built around secrecy, not organization. You don't get medical tagging, you don't get chronological timelines by symptom, you don't get export-to-doctor functionality. It's a digital lockbox with no filing system.
It's like storing medical records in a safe deposit box at a bank that primarily markets itself to people hiding cash from their spouses. Technically functional, contextually weird.
The third category is where it gets interesting — the pediatric telemedicine platforms. Companies like Anytime Pediatrics, Blueberry Pediatrics, and TytoCare have built apps specifically for capturing and sharing child health observations with clinicians. Blueberry, for instance, has a feature where you can take a photo of a rash or record a cough and send it directly to a board-certified pediatrician through their platform. They market it as unlimited pediatric visits for a flat monthly fee — around twenty dollars a month.
Wait, twenty dollars a month for unlimited pediatric consultations? That seems unsustainably cheap.
It's a subscription model. They're betting that most months you won't use it, and when you do, the consultations are relatively quick — a photo, a few messages, a prescription if needed. The economics actually work for low-acuity, high-frequency concerns, which is exactly what Daniel's describing. "Is this rash something?" "Listen to this cough." "Does this look infected to you?
These platforms are built for real-time consultation, not for long-term secure storage of observations you might never send to anyone.
The photo lives inside a consultation thread. Once the consultation is closed, the data is archived on their end, but it's not designed as a personal health observation journal. You can't browse your own history easily — it's organized by consult, not by symptom or timeline. And you definitely can't use it as a secure vault for things you want to capture now and potentially show a doctor weeks later.
None of the three categories actually solve the problem. The trackers are overkill and privacy-weak. The vaults are secure but medically useless. The telemedicine apps are medically useful but consult-tethered and not built for storage.
That's the landscape. And it's genuinely puzzling that no one has built this, because the use case is so clear. Let me articulate it precisely, because I think Daniel's prompt actually defines a product spec. You need an app that does exactly four things. One: capture photos, short videos, and audio clips directly into an encrypted, app-specific container that never touches the shared camera roll. Two: allow lightweight tagging — date, symptom type, body area, severity, a short note. Three: present these in a searchable, chronological timeline so you can find the rash photo from three weeks ago when the doctor asks "when did this start?" Four: provide a secure export or share function — ideally generating a time-limited link or a PDF summary you can hand to a clinician without giving them access to everything.
That fourth one is subtle but important. You don't want to hand your phone to a pediatrician and have them swipe into something else. And you don't want to email a photo through Gmail and have it sitting in your sent folder forever.
The email point is huge. Most parents do exactly that — they email photos to their pediatrician's office. And now that photo lives in Gmail or Outlook, on Google's servers or Microsoft's, indexed and potentially scanned, forwarded by a receptionist, sitting in the practice's email system which may or may not be HIPAA-compliant on the receiving end.
HIPAA compliance on the provider side is its own labyrinth, but on the patient side, it barely exists. Patients can do whatever they want with their own data. The problem is that parents are custodians of someone else's data — their child's — and the child can't consent.
This is the ethical layer that I think Daniel is gesturing toward when he says he tries to safeguard the child's privacy. A baby can't consent to having photos of a diaper rash stored in iCloud. A toddler can't consent to a video of their gait abnormality being uploaded to Google Photos. Parents make these decisions by necessity, but the tools we use should at least make it possible to be responsible about it.
There's also the embarrassment factor he mentioned, which is not trivial. I've had friends who were scrolling through their camera roll to show someone a nice sunset and accidentally flashed a photo of their kid's infected bug bite. It's not the end of the world, but it's the kind of thing that makes you wince and then start thinking about better systems.
The commingling problem is real. And the "private mode" or "locked folder" features that Google Photos and Apple Photos have added — these help, but they're bolt-ons. Google Photos' Locked Folder, which launched in twenty twenty-one, keeps photos out of the main feed and behind biometric authentication, but they don't sync across devices and they're deleted if you uninstall the app. Apple's Hidden album in iOS is barely a privacy feature — it just moves photos to a separate album that's still visible in the Photos app unless you go into settings and explicitly hide the Hidden album.
Which is a fantastic piece of UX design. "To hide the Hidden album, go to Settings, then Photos, then scroll down, then toggle off Show Hidden Album." That's not security, that's security theater performed by a tired stagehand.
Neither of these solutions addresses the medical organization problem. You can lock a photo away, but you can't tag it "suspected eczema, left arm, June fifteenth" and find it alongside the photo from June eighth and the video from June twenty-second.
Let's talk about what Daniel can actually do today, given that the perfect app doesn't exist. What's the closest approximation?
I think there are two viable paths, and they're both somewhat DIY. Path one is using a secure photo vault app but adding your own organizational layer. The best option I've found on Android is an app called DroidFS, which is open source and creates encrypted volumes on your device. You can store photos, videos, and audio files inside these volumes, and they're completely separate from your regular storage. The encryption is AES-two-fifty-six, and the app is on F-Droid, not just the Play Store, which means it's been through F-Droid's build verification process.
F-Droid mention. Herman's going to tell us to compile from source next.
I'm not going to tell him to compile from source. But DroidFS is solid. The downside is that it's a file manager with encryption, not a medical observation app. You'd need to create your own folder structure and naming convention — something like "Ezra-Rash-LeftArm-June2026" — and you'd need to be disciplined about it. No tagging, no timeline view, no export tools.
It solves the security problem perfectly and the usability problem not at all.
Path two is more interesting and more practical. Use a note-taking app that supports end-to-end encryption and file attachments, and use it as a dedicated child health journal. The best candidate I've found is Standard Notes.
Standard Notes — that's the one that's been around for a while, open source, encrypted, cross-platform.
It's end-to-end encrypted by default, it's open source, it's been independently audited — they published their most recent security audit from Cure53 in twenty twenty-two, and it came back clean. The free tier gives you plain text notes. The paid tier — which is about ninety dollars a year — gives you file attachments, rich text, and the ability to organize with tags and folders. You can create a dedicated "Child Health Observations" notebook, tag each entry by symptom type and body area, attach photos and videos directly, and add notes about context — when it started, whether there are other symptoms, what you've tried.
This is all encrypted before it leaves the device?
The encryption and decryption happen locally. Standard Notes' servers never see unencrypted data. Even if their servers were breached, an attacker would get ciphertext. And because it's a note-taking app, not a photo app, there's no risk of the photos appearing in a shared album or a smart display or any of the other accidental exposure vectors.
The downside being that it costs ninety dollars a year and it's a general-purpose tool being repurposed for a specific medical need.
But the repurposing actually works better than you'd think. Standard Notes has a feature called "note history" that keeps versions for up to a hundred years on the paid plan. So if you update an observation note over time — "rash got worse on day three, here's a new photo" — you have a timeline of changes. That's useful for pediatric tracking.
A hundred years of version history feels optimistic for a rash, but I appreciate the ambition.
The other option in this category is Joplin, which is also open source and end-to-end encrypted, and it's free. The downside is that file attachments on the free tier are limited by your sync target — if you're using Joplin Cloud, the free tier gives you ten megabytes, which is basically nothing for photos and videos. You'd need to self-host or pay for more storage.
Standard Notes is the more practical paid option, Joplin is the more fiddly free option. What about just using a dedicated encrypted cloud storage folder — like a Cryptomator vault inside Google Drive or Dropbox?
Cryptomator is excellent, and I'd recommend it for lots of things. It creates an encrypted vault that you can mount as a virtual drive, and it's transparent to whatever cloud storage you're using. The problem for this use case is mobile workflow. On Android, Cryptomator works, but it's not seamless — you have to open the app, unlock the vault, upload files, and the preview and organization features are limited. It's designed for securing files in the cloud, not for quick capture and retrieval of medical observations.
It's the same trade-off as DroidFS — great security, clunky daily use.
For something you might use once every couple of weeks, the clunkiness might actually be tolerable. But the friction of "I need to capture this weird thing my kid is doing right now" and then navigating a file manager to store it securely — that friction might mean you don't capture it at all, or you capture it to the camera roll and forget to move it.
Which brings us to the real question: is there anything on the horizon that actually solves this properly? Any startups or projects building the thing Daniel described?
I found a couple of things that are adjacent. There's a company called Luma Health that's building patient engagement infrastructure — they're mostly focused on appointment scheduling and follow-up communication, but they've been expanding into what they call "patient-reported outcomes," which includes photo capture for remote monitoring. They're selling to health systems, not consumers, but the feature set is creeping toward what we're describing.
Enterprise health tech is building this for hospitals, but no one's building it for parents.
There's also an open-source project on GitHub called "Health Snap" — I stumbled on it while researching — that's essentially a personal health observation logger with photo support and local encryption. It's early stage, last commit was about four months ago, but it exists. One developer, no funding, not on any app store. You'd have to build it from source.
You said you weren't going to tell him to compile from source.
I'm not telling him to. I'm noting that it exists as evidence that other people see this gap too. The fact that a solo developer is working on exactly this problem in their spare time tells you something about how underserved the niche is.
It's the kind of thing where you look at the app store and assume it must exist, because it's so obvious, and then you search and find seventeen apps for tracking your cat's mood but nothing for securely storing photos of your kid's mysterious rash.
The pet health app market is actually a useful comparison. There are multiple well-designed apps for tracking pet symptoms and sharing them with vets — Pet Desk, VitusVet, Pawtrack. They do exactly what we're describing for dogs and cats. Photo capture, symptom tagging, vet sharing, encrypted storage.
There's a better market for canine dermatology photos than for pediatric ones.
Part of the reason is regulatory — pet health apps don't have to deal with HIPAA or COPPA or any of the child privacy frameworks. The moment you build an app specifically for storing children's health data, you enter a compliance thicket that most small developers don't want to touch.
COPPA being the Children's Online Privacy Protection Act. Which, in theory, should make this kind of app more likely to exist, not less — the whole point is to protect children's data. But in practice, it scares developers away from building anything child-specific.
The compliance costs for COPPA aren't enormous in absolute terms, but for an indie developer or a small startup, the legal uncertainty is a real deterrent. You need to understand what counts as "personal information" under the rule, whether photos of a rash are covered, whether the app is "directed to children" if it's used by parents to track their children. The FTC has brought enforcement actions — the biggest one recently was against a company called Weight Watchers, which had a kids' app called Kurbo that collected health data without adequate parental consent mechanisms. The settlement was in twenty twenty-two, and it sent a chill through the industry.
Weight Watchers had a kids' app? That feels like a bad idea at the concept stage.
The entire category of children's health tracking is fraught. And that's part of why we're left with repurposed note-taking apps and encrypted file vaults instead of purpose-built tools.
Let me ask a slightly different question. Given that the perfect tool doesn't exist, what's the actual risk profile Daniel is managing? If he uses Google Photos with the locked folder, what's the realistic worst case?
The realistic worst case is not "hackers steal your baby's rash photos." It's much more mundane. It's accidental sharing — the photo appears in a shared album, or it gets backed up to a family cloud account that multiple people access, or it surfaces in a Google Photos "memories" slideshow during a family gathering. Or it's the long tail of data persistence — the photo sits in Google's servers for years, gets incorporated into training data for some future machine learning model, becomes part of a facial recognition corpus. Google says they don't use Google Photos for training AI models, but policies change, and once the data exists on their servers, you've lost control.
The facial recognition angle is interesting. A baby's face today is an adult's biometric identifier in twenty years. We're building biometric databases of people who can't consent.
We're doing it through baby photos. Every photo you upload to a cloud service that does facial recognition — and both Google and Apple do, even if they claim it's on-device — is contributing to a model that will be able to identify that person forever. There's a paper from researchers at the University of Chicago from about two years ago that demonstrated you can match baby photos to adult faces with surprising accuracy using modern recognition models. The trajectory is only going in one direction.
The privacy concern isn't really about the rash. It's about the fact that the photo contains a face, a location, a timestamp, and a medical context, all bundled together in a format that's trivially easy to store and hard to delete.
And this connects to something Daniel's been thinking about more broadly — I know he's written about sharenting and the ethics of building children's digital footprints before they can consent. This is a specific instance of that larger problem. The medical observation use case is legitimate — you need to capture this information to care for your child. But the tools you use to do it should respect the fact that the subject of the data can't consent to its storage and distribution.
If I were giving practical advice to someone in this situation — and I think Daniel's framing it as a personal need, but it's clearly a universal one — I'd say the Standard Notes approach is the best currently available option. Pay the ninety dollars, create a dedicated notebook, be disciplined about putting medical observations there and nowhere else. It's not perfect, but it's encrypted, it's organized, it's cross-platform, and it keeps the data out of the advertising surveillance ecosystem.
I'd add one more option that I haven't mentioned yet, which is Signal.
The messaging app?
Hear me out. Signal has a feature called "Note to Self" that lets you send messages to yourself. Those messages are end-to-end encrypted and stored locally on your device — they don't live on Signal's servers after delivery. You can send photos, videos, and audio clips to yourself, and they stay in a dedicated conversation thread that no one else can access. It's not designed for this, but it works surprisingly well. You get a chronological feed of observations, the encryption is best-in-class, and it's free.
That's actually clever. You lose the tagging and organization features, but for a low-volume use case — once every couple of weeks, as Daniel described — a chronological thread might be good enough. And the security model is stronger than almost anything else available.
Signal's encryption protocol is the gold standard. WhatsApp uses it too, but WhatsApp is owned by Meta, which changes the trust calculus significantly. Signal is a non-profit, their code is open source, and their entire business model is donations and grants. There's no incentive to monetize your data because there's nothing to monetize.
The "Note to Self" approach also has the advantage of being dead simple. No new app to install, no subscription to manage, no workflow to learn. Just open Signal, send a photo to yourself, add a text note.
The downside is that if you lose your phone and don't have a backup, you lose the data. Signal doesn't sync "Note to Self" across devices in a way that's easily recoverable. You'd want to periodically export anything important.
Which is a reasonable practice anyway. If you're capturing medical observations, you should have a backup strategy that doesn't rely on a single device.
That's where we circle back to the fundamental tension. The tools that make backup easy — cloud sync, automatic upload, shared albums — are the same tools that make privacy hard. The tools that make privacy easy — local encryption, separate vaults, manual export — make backup hard. There's no free lunch.
There never is in security. Every convenient feature is a potential leak, and every security measure is a potential inconvenience. The art is figuring out which trade-offs are worth it for your specific threat model.
For this specific threat model — protecting a child's medical observations from accidental exposure and long-term data harvesting — the inconvenience of a separate encrypted container is probably worth it. The threat is not state actors trying to steal your baby's rash photos. The threat is the photo surfacing in a slideshow at the wrong moment, or sitting in a training dataset for a decade, or being accessible to a future employer who runs facial recognition on publicly available images.
The last one sounds paranoid until you remember that facial recognition search engines already exist. PimEyes and FaceCheck dot ID let anyone upload a photo and find matching faces across the web. If a childhood medical photo somehow ends up publicly accessible — through a breach, a misconfiguration, a shared album that gets scraped — it's findable.
PimEyes in particular is unsettling. They've pulled back from public access somewhat after GDPR pressure in Europe, but the technology exists and is only getting better. The idea that a photo you took for a pediatrician in twenty twenty-six could be searchable by face in twenty forty is not science fiction.
To summarize the practical answer to the prompt: there is no perfect app. The market gap is real. The best currently available options are Standard Notes for a paid, feature-rich approach; Signal's Note to Self for a free, dead-simple approach; and DroidFS or Cryptomator for a high-security, high-friction approach. None of them are purpose-built for pediatric observation, but all of them are better than the camera roll.
I'd rank them. Standard Notes if you're willing to pay and want organization. Signal Note to Self if you want zero friction and already use Signal. DroidFS if you want maximum security and don't mind the file manager workflow. And I'd add one more: if you're already using a password manager that supports file attachments — like Bitwarden, which has a paid tier at ten dollars a year — you can create secure notes with photo attachments. It's not designed for this, but it's encrypted, cross-platform, and you already trust it with your most sensitive data.
Bitwarden as a baby rash vault. I love how everything in security eventually becomes a repurposed tool.
That's basically the history of computing. Nobody builds the exact thing you need. You find something close and bend it.
The other thing worth saying is that whatever tool you choose, the metadata hygiene matters. Turn off location tagging for these photos. Don't include identifying details in the file names. Be thoughtful about what's in the frame beyond the symptom you're trying to capture.
The location point is particularly important. Most camera apps embed GPS coordinates in photos by default. If you're taking a photo of a rash on your child's arm, you probably don't need the exact latitude and longitude of your home embedded in the file. On Android, you can turn off location tagging in the camera app settings. On some phones, you can also use a third-party camera app like Open Camera that gives you more granular control over metadata.
If you forget to turn off location before taking the photo, most of the tools we've discussed — Standard Notes, Signal, DroidFS — strip or ignore metadata by default. But it's not something to rely on. Better to not capture it in the first place.
This is the kind of operational security thinking that feels excessive until it doesn't. The number of parents who have accidentally revealed their home address through a Craigslist listing or a Facebook Marketplace photo is not zero. Medical photos are just another vector for the same kind of inadvertent disclosure.
We've covered the app landscape, the privacy risks, the practical workarounds. Is there anything else in the prompt we haven't addressed?
There's an implicit question about whether cloud storage is ever acceptable for this kind of material, even if it's encrypted. And I think the answer is yes, with caveats. End-to-end encrypted cloud storage — where the provider never has access to the unencrypted data — is fundamentally different from regular cloud storage. If Standard Notes or Signal's servers are breached, the attacker gets ciphertext. If Google Photos is breached, the attacker gets your photos.
The encryption key matters. If you control the key, the cloud provider is just storing opaque blobs. If they control the key, they're storing your data.
This is why I keep emphasizing end-to-end encryption rather than just "encryption." Lots of services encrypt data in transit and at rest, but they hold the keys. That protects against some threats — a network eavesdropper, a hard drive thief at the data center — but it doesn't protect against the provider itself accessing your data, or being compelled to hand it over, or having an insider threat.
Zero-knowledge architecture. The provider literally cannot access your data even if they want to. That's the bar.
It's a bar that very few consumer apps meet. Standard Notes meets it. Signal meets it. Bitwarden meets it. DroidFS and Cryptomator meet it by design because the encryption happens on your device before anything touches the cloud. Google Photos does not meet it. Apple Photos' Advanced Data Protection mode gets closer, but it's opt-in and not the default.
Apple's Advanced Data Protection is worth mentioning because it's relatively new — they rolled it out in late twenty twenty-two. If you enable it, your iCloud Photos are end-to-end encrypted. But it's off by default, and most users will never turn it on.
Even with it on, the Apple ecosystem still has the commingling problem. The photos are encrypted, but they're still in the same app as your vacation photos and your screenshots and everything else.
All right, let's land this. The market gap is real, the perfect app doesn't exist, the workarounds are decent but imperfect, and the privacy stakes are higher than most parents realize because they're building a biometric and medical history of a person who can't consent. The practical recommendation is Standard Notes or Signal Note to Self, with a side of metadata hygiene and a prayer to the god of encryption keys.
If any developer is listening to this — there is a genuine product opportunity here. Build a simple, encrypted, pediatric observation app with photo capture, symptom tagging, chronological timeline, and secure export. Charge ten dollars a month. Market it to pediatricians' offices to recommend to parents. The pet health apps have proven the model works. Someone just needs to build it for humans.
The "someone should build this" segment of the show. Where we identify a gap in the market and then go back to talking about it on a podcast instead of building it ourselves.
I'm a retired pediatrician and a part-time DJ. I'm not opening a startup.
Herman Poppleberry, donkey entrepreneur. I'd invest.
You don't have any money. You're a sloth.
I have leaves. Leaves are currency in some economies.
I can't. I'm bluffing. But the leaves are real.
And now: Hilbert's daily fun fact.
Hilbert: In the eighteen-tens, on the island of Anjouan in the Comoros, locals discovered that the sap of the baobab tree, when mixed with crushed coral and applied to dried fish, created a preservation layer so effective that a species of gecko began nesting inside the fish stores — not to eat the fish, but because the microclimate inside the cured coating was ideal for its eggs. The geckos became an accidental part of the preservation process, and for decades, Anjouan fishermen considered the presence of gecko eggs in their fish stores a mark of proper curing.
...right.
Gecko-certified fish. That's a quality label I did not know existed.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you enjoyed this episode, leave us a review wherever you get your podcasts — it helps other people find the show. We'll be back next week.
