# Mary Camacho — Full Writing Archive
https://marycamacho.com
## Draw, Antonio. Draw.
https://marycamacho.com/writing/draw-antonio
Published: 2026-08-13
Last week I read a novel that used a line credited to Michelangelo, scrawled on a practice sheet belonging to
his student Antonio Mini: "Draw, Antonio. Draw, Antonio. Draw, and don't waste time." It had me think.
It might be the best mentoring ever done in under ten words. Antonio couldn't be taught into becoming
an artist. He could only draw his way there. The drawing was the learning.
And I want to say what drawing actually does. When you draw,
the drawing is *there*. You can look at it. You can see what you know: the parts where your hand was
sure, the things you got right without ever noticing you'd learned them. And you can see what you
missed: the line that went wrong, the proportion you couldn't hold, the things you didn't know you
couldn't see until the drawing was on the page, not showing what you thought it would show. It tells you what you still need to practice, and deeper than that, what you still need to learn about how to *see*. That's the mechanism. It was never effort for effort's sake. The thing you created is the only mirror that shows you both what you can do and what you can't yet do.
The verb changes with the century, and yet, the mechanism doesn't change. Draw, Antonio. Code,
Antonio. Build, Antonio. Create, Antonio, create.
I've been circling around these ideas for a while, because I was afraid they had stopped
being true.
I was afraid enough that I wrote a song about it, the better part of a year ago. (Yes, I write songs. That's
its own story, for another piece.) It's called [*The Vanishing Aha*](/music/the-vanishing-aha), and it's about a whole new world... a second sea that "shimmers in my hand, claims to hold all knowing, and gives before I'm ready". In plainer
terms: it's the shiny new thing that has us think it is everything. But what it does is replace the
hard work of learning. I name that gap in the song:
> It gives me everything but the climb.
Because the climb is precisely where the 'ahas' live. In the song, I described the past when learning hurt a little, "discovery came like lightning... split you open, and for a breath you were new." It's that lyric where my fear lived. I was afraid AI would erase my glorious experience of learning.
Learning can happen in so many ways - I learn easily by listening and by doing. And the best learning I've experienced is hard. I learned how to lay tile - by cutting tile and laying tile and doing it until it was right. Tile pushes back. Matthew Crawford calls that working against a recalcitrant object: a thing that doesn't care what you believe about it and won't negotiate. You can't read your way past it. Your hands learn something your head can't be told.
That kind of doing builds calluses. So my entire fear in 4 words: false mastery without calluses.
I'm not the only one who's been afraid of this. My friend Alejandra Parra-Orlandoni just published a societal version of this same fear. She calls it [the comfort ratchet](https://callmemapo.substack.com/p/the-comfort-ratchet). As she argues, we keep redefining difficulty as harm, then build technology to remove it, one reasonable step at a time, until we've engineered away forms of difficulty that were helping to form us. She's examining that pattern across war, intimacy, and cognition at a civilizational scale. I was writing a song about myself. Same fear.
The song ends on a question it refuses to answer: is it benign?
Well, I want to report back from the other side of 8 months, because what I experienced using AI to create is pretty much the opposite. And I think I know why.
In the last seven months I built three applications. One is live. One is ready for a closed alpha
test. The third one, which I'm most excited about, is coming last on purpose. I think it's my best
business application, and it comes last because the first two are my drawings. Each one is a sample I
can hold, poke at, and understand the gaps from. Each one shows me what I did and what I missed, and what I
still couldn't see when I made it. The third app gets built by whoever I am after looking deeply at the
first two.
And the learnings are not small. I'm not just learning my apps, or privacy features. I'm learning entire new worlds in my infrastructure tooling but more importantly I'm learning how to
deliver value on infrastructure that works fundamentally differently from what platforms have been
built on for the last twenty years. Nobody could have lectured that into me. I couldn't have simply read it in a book. It had to come through doing. I built my calluses.
Here's something about how I learn. I'm fast, but I'm also broad. I work across more context than most
people, which means I often need a lot of different kinds of learning before the pieces can connect.
My ahas don't come from one domain. They come when enough different pieces get close enough to each other. At the old pace of building, the pieces arrived months apart, and through larger teams, and I couldn't always see the connections when they showed up.
And importantly, working with AI agents at the speed they produce outputs has not taken away the judgement or the difficulty. What it changed is how many drawings land on the page, and how fast I can reassess them. That's it.
That's the whole mechanism. Speed didn't skip my ahas. There were enough mirror experiences, close enough together, to see in the creation both what I had already learned and what was missing, while everything was still fresh.
So the fear I had was backwards. The tool didn't remove the practice that builds the artist. It
compressed the time needed to do the learning work. More drawing, not less. I am Antonio. I am drawing. I'm drawing faster than I
ever have, and my capacity is sharpening faster and more clearly than at any point in thirty years of building.
Now for a caveat about what a drawing can show me. Code pushes back, but only so far. I can easily build something correct that nobody wants. The recalcitrant object becomes the consumer, and she doesn't negotiate. So there is a whole other set of drawings coming related to GTM. I'll be using many of the same tools to speed up that work, and sharpening myself on iterations of experimentation and analytics. Same mechanism, harder mirror.
I want to name a fork, because the fear isn't wrong for everyone or in all circumstances. There are two ways to use these tools, and I've watched them produce opposite people, opposite experiences, and this is exactly what Alejandra's essay is addressing. If you let AI do the work for you, things ship, but you never look at a drawing of your own. There's a verse in my song about navigators who lose sight of the stars behind a thousand glowing screens... "We arrive everywhere, but travel nowhere." All output, but no experience.
But using AI in your creative process can also give you more reps. You draw more, not less, and every rep is still yours - you're the one deciding, correcting, connecting the pieces. The tool doesn't decide whether you're still drawing. You do.
So the song finishes with a question: is it benign? All these months later, I say this new world is neither
benign nor malign. It's indifferent, and it's a mirror. It gives you "everything but the climb" only if
you stop climbing. Keep climbing and it turns out there's more mountain in front of you than you could ever reach. The pace that you can keep with agent partners might be just what you need for achieving more reps that are closer together, allowing you to connect dots and think newly or differently. My calluses are not vanishing.
They're building up faster than they ever have.
So, five hundred years later, the advice survived the arrival of AI. When used this way, what you create with AI is still only your mirror. If you don't create, you simply don't learn.
Draw, Antonio. Draw.
Create, Antonio. Create.
---
## Is private data processing PIE in the sky?
https://marycamacho.com/writing/pie-in-the-sky
Published: 2026-07-28
The core of Cirdia's Private Intelligence Engine (PIE) was just published in the [Technical Disclosure
Commons](https://www.tdcommons.org/dpubs_series/11179/) and it runs on commodity cloud infrastructure. This is about how everyday businesses could be
ensuring privacy... even when apps need AI-scale compute that isn't possible on a device.
> Quick note for those not familiar with the saying ['pie in the sky'](https://waywordradio.org/pie-in-the-sky-origin/). This is a common saying that came from a song written by a labour organiser in the US, and it generally means impossible to achieve or a dream that can never become reality.
Most people who build software assume you get one or the other. Either you keep people's data on their
own device, where it's safe and where you can't do very much with it, or you bring it into your cloud,
where you can actually compute on it and where you now hold the most personal thing your customers
have. Pick a lane. Privacy or capability.
I don't think that's true, and when I started building Cirdia and wellness tech, I decided to demonstrate it. This week I put the whole design into the commons, under a Creative Commons license, so anyone can check my work or take it and build their own.
## What it does at a high level
Here it is stated simply - in the way my company and our customers use it today. Your wellness data lives on your phone. Not on our servers. Not in a cloud
database. On the device you control. When it's time for an AI analysis, the app encrypts that data and
sends it to a temporary, private computer that was created for that one person, for that one job. It
runs the analysis, sends encrypted results back to your phone, and then that computer is destroyed. Not
shut down. Not wiped. **Destroyed.**
Open the diagram full size
The part that surprises people is the middle. There's a thing in there I call the mailbox, and its
whole job is to be too stupid to matter. It holds encrypted blobs and public keys. It runs no
cryptography of its own. It can't decrypt anything, and it isn't asked to. Your phone drops something
off, a worker picks it up, and the two of them never speak to each other directly, not once, in the
entire process.
The worker is the other half of it, and the important thing about the worker is how short its life is.
It comes into existence for one job. It generates its own keys the moment it starts, in memory, from
scratch, receiving nothing from us. It does one person's analysis. Then it's destroyed, and the keys
are destroyed with it, which means anything still sitting in the mailbox afterward is encrypted to keys
that no longer exist anywhere in the world. The only place the information can be used is the one mobile
phone that started the process.
## Why not just keep it all on the phone?
That's the obvious question, and for a long time the answer was that we did. We started building hardware, a wearable.
We were doing on-device processing with Rust algorithms, and it was working. The chips are
standardised now, and they pre-process most of the sensor data before it ever reaches the app. The
sensor side is largely handled.
What we couldn't do on the device was lived context. Lived context is what I have been saying wearables miss, and I have been saying it for a long time. Here is an example. How do you actually experience your sleep - not just the sensor data of how much or of what type, no, how do you feel when you wake up? Refreshed and rested, or still tired? Another example of lived context is when you describe your walking as dog walking. Someone I know was told by their device that they had balance problems. Their reality is that they walked their dog and they were pulled off balance by the dog. When you are analysing your health and wellbeing, these kinds of details matter, and they get missed by wearables - which is why Cirdia was always going to build apps as well.
Anyway, earlier this year, we pivoted away (temporarily) from our device work, and built Tapestry as our first app. Tapestry is precisely a journal for lived context. It lets you log how you feel, what you do, and anything you think might be related. The goal of the app is to help people discover what is connected to what, personally and privately. For this app, the data was never going to be a fixed list of things the way sensors on a device work. We have no idea what a person may choose to track, be it a symptom, a habit, an activity, a feeling or mood. Anything goes. Whatever their life actually is.
To be able to analyse this sort of data we knew we couldn't do it on the device. Phones can run small models, and they do useful work. What they can't do is look across months of somebody's arbitrary, self-named trackables and find what connects to what, and keep getting better at it without shipping a new app to everybody. We simply had to have cloud based AI processing. That's the fork in the road, and almost everyone takes the same path: centralise the data in our company databases where we can see all of it. I did not want that, so the question I needed to address in a design was whether you could have the compute without the custody.
Now that you can see what it is and what started me down this path - let's get into why this matters, and then how it works.
## The distinction everything sits on
Every app collects two kinds of personal data and treats them as one thing.
**Contact data** is who you
are and how to reach you. Name, email, account and billing identifiers. Every app holds this
legitimately; it's how the relationship runs.
**Confided data** is what you reveal about yourself. Your
body, your mind, your behaviour, what you track.
Conventional systems store both in the same place, and that's the original sin. That's the exact move
that turns a login table into a dossier of somebody's private life. And policy can't fix it. Policy is
only as durable as the people holding it, and a promise made by today's operator binds nobody. Not the
acquirer, not the new board, not the successor with different incentives. If the data persists, the
promise is temporary and the data is not.
So the fix has to be structural.
I'm going to pause here for a moment and share a bit about the stakes. Many people might see what I've written above and say 'yeah, whatever, I don't really care about someone knowing my mood, I already share it on...' and then they mention one or more of the most popular social media apps used around the world: Facebook, Instagram, TikTok, Line, WhatsApp or Discord groups.
But what's missed here is that there are things we don't share - things we intend to keep more confidential. Maybe those things have to do with your financial situation, your sex life, drugs or alcohol, issues with mental health, legal issues, or just symptoms and habits that you are working to understand. Those things are what apps capture every day. And I'll make a stronger point about this because it's real and it's only getting worse. Those confided details are the bread and butter for fraud. When someone threatens us with information we thought was private, we trust that they know it for a good reason. They can impersonate company representatives, doctors or medical establishments, financial institutions, and we are more likely to believe them. This is why privacy in apps matters.
Now back to the privacy engine itself.
## What we actually built
*This part gets a bit wonky so skim it if you don't love the tech.*
### The dumb thing in the middle
Let's start in the middle of the flow (see my diagram above). I knew before we wrote a line of this that I wanted the two sides never to talk to each other. The
user's device and the worker that processes their data never connect directly. Both poll a deliberately
dumb mailbox that holds ciphertext, public keys, and status codes, and nothing else. It runs no
cryptography. It can decrypt nothing. When a worker takes a job, it writes its claim once, and nothing can overwrite it. First one there wins. That matters because otherwise a second worker could come along later, swap in its own key, and get handed data meant for somebody else.
Now notice what isn't in that picture. Nothing is sitting above all of this directing traffic and deciding who gets what job. The worker picks its own. And nothing keeps a record of which jobs ran or what came back from them. Both of those are missing on purpose. A traffic controller would have to know who was doing what, and a ledger of jobs and results would be a pile of exactly the thing I don't want to be holding. Yes, this misses important details about how to make that work at scale. But let's continue.
### Keys that are born and die with the job
Keys are born per job and die with it. Each job runs a bidirectional hybrid key agreement, X25519 plus
ML-KEM-768 (the NIST post-quantum KEM), combined into one symmetric key. The worker generates its
keypair in process memory after startup, from local entropy, and receives nothing from our storage.
Nothing. The device and the worker each derive the identical secret independently, so the key never
crosses any wire, and the input and response directions use two independent agreements, so compromising
one direction tells you nothing about the other. When the worker is destroyed, the keys are gone, and
whatever ciphertext is still sitting in the mailbox is encrypted to keys that no longer exist anywhere.
I want to be precise about what that means: retrospective decryption isn't something we forbid
ourselves from doing. It's something that cannot be done.
### One job, one person, never shared
One job is one user's single payload. One person's data, one analysis, one encrypted result, then
destruction. No instance that touches plaintext is ever shared between users. Not at the same time, not one after another. Never.
### The part I can't design away
And yes, while a job runs, that one user's decrypted data exists in that one worker's memory for a few minutes. Every system that actually computes on plaintext data has that moment, and anyone claiming otherwise is selling something. If you want to close even that small loop, you can run this on hardware that encrypts memory itself. The disclosure says exactly where that moment lives, because I'd rather show you the boundary than pretend I built something that doesn't have one. Purists might say this defeats the purpose. I say a pragmatic approach is exactly what privacy and security are all about - and I'll be writing more about how this connects to real and imagined risk in future posts.
### Keeping the model in its lane
Now, let's talk about the design of the processing workflow that runs in the cloud. The inference pipeline is deterministic in the middle. A model proposes findings, using a server-enforced schema. In our case the findings are about statistical relationships between trackables or about patterns of individual items tracked. Patterns and relationships are the output. After that, ordinary, boring, testable code validates each finding with a registered statistical procedure and recalculates from the actual data, and we apply a measurement-level gate so we can avoid stupid mistakes like averaging ordinal level data. Finally, a second model call writes prose around the validated findings, pinned to exactly this run's finding ids, ensuring it can't merge them, invent new ones, or add entries. Two model calls. Every computed value is deterministic.
The takeaway from what I'm describing in the processing workflow is that designs need to account for the various failure modes of AI. Our product choice, for now, is to surface patterns and stay out of diagnostics altogether. But even for workflows that might incorporate diagnostics one day, what matters is how workflows are designed with layered steps that have deterministic gates between them, creating a safety mechanism. So you're not relying on the model to behave.
Bias is one of those failure modes. In Cirdia's example, all of our apps are dealing with health, wellness, and adjacent information. AI models have been trained on medical research which predominantly studied male bodies and published results as if they described everyone, thereby creating deep bias. In some areas of women's health it's far worse than bias: perimenopause and menopause affect every system in the body, and the research has barely scratched the surface. So a model asked about a woman's body is working from a half-empty knowledge base, and it answers with exactly the same confidence as if the knowledge were whole.
Precision is the other one. We have our data schemas interacting with prompts precisely to prevent diagnostic or even normalised assessment. Most apps adding AI are adding chat. Someone asks a question, the model interprets. That pulls the worst out of the model, because interpretation is where the bias comes through, along with the opinionated normalising that decades of bad algorithms have been doing all along, assessing somebody against what the system thinks normal is. It's not that you can't have a model do this. It's that chat models by themselves are not precise enough for the answer to mean anything about you, because unlike a purpose-built algorithm they have no bounded dataset behind them, just whatever they absorbed. Yes, people do want to know what they can do with their data. But when you can't be precise enough to have it make a difference, don't pretend.
### When something breaks
Errors are the part people expect to be complicated, but this design keeps it simple. No error subsystem at all. An error is one more record in the mailbox, a category code from a closed set, riding the same path a result would. No free text, which means a worker that has seen your
plaintext has no channel to leak it through. Not even by accident. Not even in a stack trace.
What this means in plain terms is that most errors just go to the device and the device will reprocess the data. This borrows from distributed designs and is a form of self-healing. Some error codes received by the mobile device are forwarded to the company API so that we can get aggregate information to see if there are patterns of failures in the system. That's it.
### Don't take my word for any of it
And all of it is checkable. The disclosure specifies the design as compartments with testable
invariants: plaintext locality, numeric authorship, single-user-per-instance, content non-persistence,
operator non-custody. Auditors who don't trust us can inspect persistent storage for prohibited key
material, audit logging and retention configuration, run cross-invocation isolation tests, and trace
any output number back to its computation. It runs in production today on ordinary commodity cloud. No
special silicon. No attestation-gated key release. The disclosure marks what's built, what's
designed-in, and what's forward-looking, and it even flags an improvement we recommend over our own
reference construction. I'd rather be checkable than impressive.
Any one of these choices is worth its own piece, and I'll write them: the mailbox, the key lifecycle,
what 'one job' actually means, why nothing leaks even in a failure mode. The disclosure has the complete
version in the meantime, at the level of detail an engineer would need.
## Why publish it
There are three reasons why we are publishing this instead of patenting, and they stack.
**The thesis demands it.** I've spent thirty years working on ethical business and ethical tech which has evolved to one fundamental question: how do we build organisations and systems that return
capacity to people instead of extracting it? What I've learned through my journey is that architecture
encodes values. Enclosure is a choice, the same way collecting everything is a choice. If I patented
this method, I'd be fencing off the one design I most want to become ordinary. Publishing it makes the
argument with the asset itself.
**Trust should be checkable.** A privacy promise you take on faith is policy wearing engineering's
clothes. A published method with testable invariants is different in kind. Users, integrators,
regulators, auditors: they need easy ways to distinguish what is safe and what is not. That's what 'privacy by architecture, not policy'
means when you follow it all the way down.
> Quick aside. For the last decade I worked in spaces and with teams that wanted perfect solutions. I want them too. But where I always find myself is in the pragmatic middle... I want architectures that can be adopted and used. I want architectures that don't have an extreme cost of conversion. I want architectures that already align with many standards and with existing tooling. I fundamentally want the most people to get the promised value. And I think data-privacy is a value and promise we are still struggling to define and to deliver to people using apps all over the world.
**And it's shrewd, not sacrificial.** When you disclose the core of the technology into the commons, you still leave patentable edges. If demand shows up there is territory for new patents that work adjacent to this. What we have in my company is the running fabric, the
applications, the operational maturity of doing this in production. A competitor who copies the method
still has to build all of that. Meanwhile every builder who adopts it moves the market toward assuming
this design should exist, that privacy can exist along with a business model. That is exactly what I want. That's not a concession. That's the strategy.
## How I want this taken on
I published this so it will be used. I want more privacy in apps. So let me be specific about who I mean.
If you build products where people confide anything (health, mood, journals, coaching, money), the
design is yours. The disclosure carries the trust model, the
key lifecycle, the pipeline, and the deployment variations. It was written to be buildable, not
admired. And if you need more, message me. I'm happy to share more.
If you break systems for a living, the invariants are your target list. Public disclosure means people can build their own and test the invariants. We want this tested by many people. I'd love to hear from you rather than from an incident. So, reach out.
If you write the rules, meaning policy and compliance, this is what I think it looks like when a privacy claim is checkable rather than asserted. Do you agree? I think
it's fair to start expecting these kinds of architectures. Schedule a meeting, maybe there is a working group to create.
The end state I actually want is for this design to become ordinary. Boring, even. The day 'we hold
the contact and never the confided' reads like a standard line on a privacy page instead of a
differentiator, this document has done its job.
## Credit
David Braden contributed the cryptographic design of the key agreement (each side derives the identical
secret independently; no key material ever crosses the wire) and part of the coordination-server
invariant.
The mailbox runs on Void Merge, David's company. Their platform is free and open source, and it runs
the same whether you self-host it, run it on a laptop, or pay them to host it.
## Read it, build on it
If you're building anything where people confide in your product, the design is yours now.
Hold the contact. Never hold the confided.
Find the full disclosure on the [Technical Disclosure Commons](https://www.tdcommons.org/dpubs_series/11179/).
---
## Who Wants Neurological Data on Midlife Women?
https://marycamacho.com/writing/who-wants-neurological-data-on-midlife-women
Published: 2026-05-12
A run of research in late January and February of this year has done something quietly significant. It has moved midlife symptom data from the wellness category into the neurological one. Almost no one is talking about what that means for the data women have already generated, or for where they generate it next.
In January, researchers at the University of Cambridge published an analysis of nearly 125,000 women from the UK Biobank, including around 11,000 with MRI scans. They found significant grey matter reductions after menopause in the hippocampus, entorhinal cortex, and anterior cingulate cortex. These regions are central to memory, emotional regulation, and the earliest signs of Alzheimer's disease.[^1] Two weeks later, Dr. Karen Horst, a reproductive psychiatrist at Baylor College of Medicine, made the framing institutional. She argued for understanding menopause as "a predictable neuroendocrine transition," pointing to evidence from SWAN, the Penn Ovarian Aging Study, and Mayo Clinic data showing that psychological symptoms often begin up to a decade before periods stop.[^2] Both build on Lisa Mosconi's 2021 brain imaging study in *Scientific Reports*, which established that menopause changes brain structure, connectivity, energy metabolism, and amyloid plaque deposition. Those changes come from endocrine aging, not just from getting older.[^3]
Taken together, this body of work does something that has consequences well outside neurology. It reclassifies midlife tracking data.
The cycle log you kept for a decade is not just a cycle log anymore.
It is a longitudinal record of the neurological transition that comes with menopause, however and whenever it arrives. For most women that is in their late thirties or forties. For others it comes earlier, through surgery, medication, or premature ovarian insufficiency. Sleep onset times, mood shifts, cognitive complaints, hot flash frequency, energy patterns: the things women have been writing into apps for years are now markers of what the science is calling a neuroendocrine transition with measurable downstream effects on cognitive trajectory.
That changes who wants the data.
## A quick word about how we got here
Before going further: the apps women have been using for years made this scientific shift possible. A meaningful share of the longitudinal research on cycle health, menopause symptoms, and midlife endocrine patterns has been done in partnership with the tracking apps that hold centralised data. Without those datasets, the clinical evidence base for midlife as a neurological event would not exist in the form it now does. Researchers needed scale. Apps had scale. The partnerships worked, and they should be acknowledged for what they made possible.
This post looks at what comes next, now that the data has been recategorised.
## What has actually changed
When midlife symptom data was framed as wellness data, the commercial appetite for it was bounded. Advertisers wanted hot flash relief shoppers. Wellness brands wanted intent signals around supplements, sleep aids, hormone replacement curiosity. That market existed and still exists. By today's standards, it is a narrow one.
When the same data is framed as neurological data, the appetite expands.
A record of cognitive complaints stretching from your late thirties into your sixties is interesting to anyone modelling cognitive trajectories. Documented sleep disruption through perimenopause is interesting to anyone modelling cardiovascular and dementia risk. A decade of mood and energy logs across the menopausal transition is interesting to anyone building AI that learns to read emotional patterns, including voice agents, health chatbots, recommendation systems, and conversational triage tools aimed at the same demographic.
The data did not change. Its market category did.
## Who, specifically
It is worth being concrete about who has commercial reason to want this data now that it has been recategorised. Some of what follows is documented user concern. A recent Royal Holloway study, published in *ACM Transactions on Social Computing* and surveying 310 UK women, found that respondents explicitly named workplace discrimination, targeted financial scams, and exploitation of sensitive data among their worries about menopause technology. The research team flagged that current platforms often do not meet GDPR standards for this category of data.[^4] What I'm doing here is mapping where those concerns actually land.
**Insurers and reinsurers.** Long-term care insurance, life insurance, disability insurance, and increasingly health insurance all price on cognitive and neurological trajectory. Women in their late thirties through fifties are the demographic most of those policies are sold to. They have also, historically, been the cheaper demographic to insure, because men die younger and carry more cardiovascular risk through midlife. That asymmetry has worked in women's favour for a long time. A cognitive-trajectory dataset is exactly the kind of new variable that reverses it. Actuarial models will incorporate the variable; that part is not in question. What is open is whether women keep generating the dataset that lets them.
**Pension and workforce planning models.** Employers and pension administrators are increasingly modelling cognitive workload capacity through midlife and into early old age. Self-reported brain fog data is exactly what those models want, especially when it can be correlated with productivity tracking from elsewhere in someone's digital footprint. The Royal Holloway study notes that nearly one million women in the UK have already left jobs because of menopausal symptoms.[^4] Alongside that, something quieter is happening in the conversations women are having with each other. They are deciding to stay silent at work, to keep what they are experiencing off the record, because they are afraid of how it will be recorded and used against them. The women who have left are countable. The silence of the ones still in their seats is not, and it is the larger story.
**AI training pipelines.** The next generation of consumer AI is being trained on patterns of how people describe their bodies and their cognition over time. Midlife women are underrepresented in those training sets. A body of self-tracking data from this population is therefore disproportionately valuable to anyone building AI for that segment, including voice agents, health chatbots, recommendation systems, and conversational triage tools.
**Legal discovery.** Tracking data is increasingly being requested in custody, employment, and disability disputes. Data logged as wellness gets read as evidence.
**Identity and targeted fraud.** A documented record of cognitive complaints, combined with biometric and behavioural data, is exactly the kind of background that voice cloning and impersonation fraud builds on. The Royal Holloway respondents named targeted financial scams as a specific concern.[^4] Fraud economies already target older women heavily. Adding long-term cognitive records to a target profile makes that targeting more precise.
None of these markets existed for cycle-tracking data ten years ago in any serious form. They exist for neurological data now.
## What tracking forward looks like
This is the piece worth thinking about if you track, or if you are considering starting. The apps women have been using were not a mistake. The research that has come out of them is part of why your symptoms are taken more seriously today. The question is whether the data you generate from here onward sits somewhere that matches the new category.
A few questions worth asking, if you want to keep tracking and are reconsidering where:
- **Where does the data physically live?** On the device, or in a corporate database somewhere? Data the company never holds cannot be subpoenaed, breached, or sold.
- **What is the company structurally able to do with the data?** A privacy policy can promise responsible behaviour. An architecture can make some behaviours impossible. Architectures survive a change of ownership. Privacy policies don't always.
- **What happens at acquisition?** Most companies are eventually acquired. The acquiring company inherits the data and the privacy policy, and is usually free to rewrite the policy. Architecture survives acquisition. Policy does not.
- **Is there third-party tracking embedded in the app?** Even when an app itself does not sell data, the analytics tools embedded inside it (things like crash reporters and usage trackers from big platforms) can route metadata and behavioural patterns elsewhere by default. There is already precedent for data classed as wellness moving through analytics tools into ad networks without users understanding the path.
These are the questions any midlife tracker is in a strong position to ask. The category of the data has moved, and a question that was reasonable to defer five years ago is harder to defer now.
## Where I'm writing from
I should say where I sit. I've been building privacy-architected wellness software for women in midlife, and the architecture is the product, not a wrapper around it.
What that looks like in practice: pattern intelligence runs in encrypted, temporary computing environments. Each environment spins up to compute against one woman's data, then destroys itself. Nothing is retained. No aggregated body-data warehouse, no per-user record sitting in a database to be queried, breached, subpoenaed, or sold.
That choice was made before the brain imaging research recategorised midlife data. There are honest trade-offs in any architectural choice. The question of where this data sits, and who gets to decide what it means later, is one worth asking now, while there is still time to choose.
## The underlying point
The brain imaging work being published right now is good news. It validates what midlife women have been describing for decades, and it gives clinicians a real evidence base to work from.[^5] The research depended on data that has been collected at scale, often through commercial apps, often in good partnership.
What the research also does, almost as a byproduct, is reclassify the data. It is no longer wellness signal. It is neurological baseline.
The question is no longer whether your cycle data is private enough. It is whether you keep generating the dataset that reprices your insurance, shapes how your employer manages around you, and trains the AI models being built for women your age.
---
[^1]: Zühlsdorff K, Langley C, Bethlehem R, Warrier V, Romero Garcia R, Sahakian BJ. *Emotional and cognitive effects of menopause and hormone replacement therapy.* Psychological Medicine. 27 January 2026. DOI: [10.1017/S0033291725102845](https://doi.org/10.1017/S0033291725102845). University of Cambridge announcement: [https://www.cam.ac.uk/research/news/menopause-linked-to-loss-of-grey-matter-in-the-brain-poorer-mental-health-and-sleep-disturbance](https://www.cam.ac.uk/research/news/menopause-linked-to-loss-of-grey-matter-in-the-brain-poorer-mental-health-and-sleep-disturbance).
[^2]: Horst K. *Menopause is a brain transition, not just a reproductive one.* Baylor College of Medicine Blog Network. 13 February 2026. [https://blogs.bcm.edu/2026/02/13/menopause-is-a-brain-transition-not-just-a-reproductive-one/](https://blogs.bcm.edu/2026/02/13/menopause-is-a-brain-transition-not-just-a-reproductive-one/).
[^3]: Mosconi L, Berti V, Dyke J, et al. *Menopause impacts human brain structure, connectivity, energy metabolism, and amyloid-beta deposition.* Scientific Reports. 2021;11(1):10867. DOI: [10.1038/s41598-021-90084-y](https://doi.org/10.1038/s41598-021-90084-y).
[^4]: Robinson T, et al. *User Risk Perceptions and Privacy Attitudes towards Menopause Data Collection and Use.* ACM Transactions on Social Computing. 18 February 2026. DOI: [10.1145/3797822](https://doi.org/10.1145/3797822). Royal Holloway University of London summary: [https://medicalxpress.com/news/2026-03-hidden-privacy-menopause-tech.html](https://medicalxpress.com/news/2026-03-hidden-privacy-menopause-tech.html).
[^5]: For a clinician-facing synthesis of menopause and brain function research, see Peter Attia, *Menopause and brain function:* [https://peterattiamd.com/menopause-and-brain-function/](https://peterattiamd.com/menopause-and-brain-function/).
---
## Privacy-Led UX Is the Surface
https://marycamacho.com/writing/privacy-led-ux-is-the-surface
Published: 2026-05-09
## What's the question underneath?
Every so often, a major report puts institutional language to something a lot of people have been feeling without quite having words for it. The new MIT Technology Review Insights report, [*Privacy-Led UX in the AI Era*](https://usercentrics.com/wp-content/uploads/2026/04/Privacy-Led-UX-in-the-AI-Era.pdf), produced in partnership with Usercentrics, is one of those moments.[^mit] Its core finding, that privacy-led UX is becoming a prerequisite for AI adoption rather than a competitive edge, names a shift that founders and product teams in privacy-adjacent categories have been feeling in their churn, their support tickets, and their user research for a couple of years now.
Before we get to what the report says, it's worth sitting for a moment with what it's responding to.
What *is* the thing people are feeling?
It looks like this. The woman who keeps two cycle-tracking apps installed and trusts neither of them. The user who stops logging symptoms the week things get personal. The hot flash recorded in a paper journal because the app feels like the wrong place to put it. The friend who tells you she loves the wellness product you built and then quietly opens her phone to show you she's been keeping the real notes in her camera roll.
None of these people can tell you, in technical terms, what they're protecting themselves from. They don't have the vocabulary for data minimization or training-set boundaries or schema-level retention policy. What they have is an unsettled feeling: a pre-rational sense that handing this particular kind of data to this particular kind of system is wrong, even when they can't quite say why.
That feeling is the market signal the report puts numbers to. 77% of global consumers say they don't fully understand how their data is collected and used. 82% have abandoned a brand over privacy concerns. 59% are uncomfortable with their data being used to train AI models, and 81% are concerned about AI's access to their data, even while 32% use AI daily. Perhaps most usefully: 73% of US consumers say they'd share *more* data if they had genuine visibility and control over it.
The report is rigorous, and its TRUST framework (Translate, Reduce, Unify, Secure, Track) is sound. It treats consent as an ongoing relationship rather than a launch artifact: plain language at the moment a user actually needs it, equal visual weight for accept and decline, consistency across touchpoints, end-to-end governance of data flows, measurement that goes past opt-in rate. It lives, deliberately, at the layer where most companies can act on it. The design layer.
What I want to do here is gently turn the report on its side and ask about the layer underneath.
## A different question
The layer underneath isn't a different framework. It's a different question.
The question the report's framework answers is roughly: *how do we design consent so it actually serves users?* That's a worthwhile question and a hard one, and the framework does it justice.
The question underneath is one most products in the AI era haven't sat with for very long: *are the things people would want to consent to or refuse even happening in our system in the first place?*
That can sound like a semantic distinction. I don't think it is. It opens up a fork in the road, and the two paths look almost identical from outside for the first year or two.
One path leads to better consent dialogs. Clearer toggles. Onboarding that doesn't hide where data flows. A "manage your data" page that actually lets you manage your data. Permission prompts that name the specific use rather than the category. Each of these is a real improvement, and the discipline of designing them well puts useful pressure on the underlying decisions. None of them are nothing.
But none of them change what the system does.
The data still flows where it flows. The model still trains on what it trains on. The third-party SDKs still phone home with what they phone home with. The UX is the place a person *encounters* the system, but it isn't the system. And in AI products, the gap between those two has become large enough to drive a company through.
The other path is the one the report's finding points at if you take it all the way. It treats privacy-led UX as the visible surface of a system designed so that the things users would object to are *structurally not happening*. Not "disclosed clearly." Not "managed responsibly." Not happening.
That's a different commitment, and it changes things downstream that policy can't reach. What you collect. Where it lives. Who can ask for it. What survives a server compromise, a subpoena, a board change, an acquisition. What questions a Series B investor can ask, and what answers exist because the architecture made them exist rather than because someone wrote them in a doc.
Here's a useful way to feel out which path a company is actually on. Ask:
I'd offer that less as a verdict and more as a diagnostic. Most teams I talk to assume they're on the second path, because they *care* about the second path. The architecture tends to have its own opinions about that.
## Where the difference becomes visible
For a while, the two paths produce similar artifacts. Both yield thoughtful onboarding flows. Both yield privacy pages that read well. The difference shows up at three moments.
When a breach happens. The first company explains how committed it is to user privacy and announces credit monitoring. The second company explains that the data wasn't there to take.
When a regulatory shift happens. The first company adjusts its policy and adds three new consent prompts. The second company doesn't have to adjust, because the regulated behavior wasn't possible in the system.
When the acquisition happens. The first company's user data becomes a balance-sheet asset, and the privacy policy is rewritten by the acquirer. The second company's user data isn't an asset, because it isn't sitting in a database to be sold.
Notice what these three moments have in common. They're all places where the gap between *what the policy promised* and *what the architecture allowed* gets exposed. They're also the moments users feel hardest. Most people I've talked to about this can name the brand that disappointed them at one of these three crossings. It's not abstract.
This is also where the report's framing around agentic AI lands hardest. As the report notes, when AI systems begin acting on a user's behalf, the traditional consent moment may never occur. Agent-generated data flows require infrastructure that goes well beyond the cookie banner. The TRUST framework asks where consent should live. The architectural question is whether the data exists in a form that consent could meaningfully cover at all.
## What it actually costs
So why doesn't everyone build this way? Two real reasons. One of them is the one most of the industry hasn't reckoned with out loud yet.
The engineering cost is real but bounded. Data minimization at the schema level, least authority across the request path, ephemeral processing in encrypted environments rather than always-on retention. These are well-understood patterns at this point. They work. They cost more operational complexity than the path of least resistance, which is "call a hosted model API and store the response in your own database." But the techniques themselves are not exotic.
The business model cost is the one that gets quieter at conferences.
If the data isn't centralized, it can't be the asset. If the inference runs in environments that hold nothing after the computation completes, the retained corpus can't be the moat. If the patterns surface against a user's own history rather than the aggregated behavioral exhaust of millions of strangers, the network effect doesn't compound through extraction. None of that is impossible to monetize. It's a different shape of monetization, with different unit economics, and it requires a different kind of story to investors than "we're building a data network."
That's the part I'd love to see more of the field talk about openly. Privacy-led UX is relatively cheap. Privacy-led architecture is a strategic choice that closes some doors permanently, the doors a lot of the venture playbook has been quietly assuming would stay open.
What the MIT/Usercentrics report makes harder to ignore, by virtue of where the consumer numbers are pointing, is that in this category those doors were going to close anyway. The question isn't really whether to walk through them. It's whether to walk through on purpose, while there's still time to design what's on the other side, or to be pushed through later under regulatory pressure.
## Where I'm writing from
I should say where I sit in this. I've been building privacy-architected wellness software for women in midlife, and the architecture is the product, not a wrapper around it.
What that looks like in practice: we don't run "everything on-device." That's a different design point with its own honest trade-offs, and it's not the one we made. What we built is server-side pattern analysis that runs in fully encrypted ephemeral instances, spun up to compute against an individual woman's data on demand or on a schedule, and then destroyed. The instance holds her data long enough to do the work and no longer. There is no retained corpus, no aggregated body-data warehouse, no per-user record sitting in a database that could be queried, breached, subpoenaed, or sold.
That's more infrastructure than calling a hosted model API. It is meaningfully more expensive than the alternative. And it produces a privacy guarantee that doesn't depend on a privacy policy, because the system literally cannot do the things a privacy policy would otherwise have to promise it won't do.
I'm not offering this as the only valid answer. There are honest trade-offs in any architecture, and there are categories where the surface answer is genuinely sufficient. Wellness data for women in midlife is not, in my view, one of them. The unsettled feeling I described at the top is too loud, and the asymmetry between what this kind of data reveals and what a user can recover if it leaks is too steep.
What I'd ask anyone building in an AI-saturated, sensitive-data category to sit with, coming out of this report, is the question underneath. Not just "how do we make our consent flow better." Better consent flows are good. But: *what is actually happening inside the system, and would the user, fully informed, consent to it?* If the answer is no, the design layer can soften it. It can't solve it. The architecture is where that question gets answered structurally, or doesn't.
The report draws the surface beautifully. The architecture is the thing the surface is reflecting back.
[^mit]: An accompanying article is published at [technologyreview.com](https://www.technologyreview.com/2026/04/15/1135530/building-trust-in-the-ai-era-with-privacy-led-ux/). Fair warning: the cookie consent flow you'll meet there is somewhat unreasonable given the topic of the article.
---
## A Different Kind of Vessel
https://marycamacho.com/writing/a-different-kind-of-vessel
Published: 2026-05-08
*What if there were a privacy-first federated AI model for women's wellness? And what if we, collectively in femtech, were the ones who owned it?*
---
The AI everyone is reaching for now is insufficient when the question is a woman's body. Ask any of the big assistants about your cycle, your hormones, the way your body has been changing in midlife, and you will run aground on the same set of disappointments: generalities dressed as advice, recommendations calibrated to a body that is not yours, the polite agnosticism of a system that has not, in fact, been trained on what it is being asked. The infrastructure that would do this better has not been built. It could be. And the form it ought to take is not a company.
*A note before I begin: this is an inquiry in progress, not a finished blueprint. Any technical mistakes here are my own.*
## The wellness layer
Companies are good at making products. They produce specific benefits for specific customers and sell them at margin, and that form works, and most of what we use every day is the proof. There is another category of value, though. The kind that has to live across many companies to mean anything at all. It asks for a different vessel.
Consider what is missing.
The clinical record knows you when you are sick. It knows your diagnoses, your prescriptions, the labs you ran the last time something was alarming enough to send you in. It does not know your sleep through perimenopause. It does not know the years of cycle data you have already logged. It does not know that the week before your period has been quietly demolishing your concentration since you were thirty-four, or that the migraines have been worse this year, or what your own theory of why is.
Public health research has been catching up, slowly, on what it left out for a century. The drug trials that excluded women of reproductive age. The cardiac science calibrated to male physiology and generalised as universal. The long quiet about pain and exercise and nutrition and sleep in bodies that are not the bodies most of the world's population lives in. The literature on this gap is now large. The correction is happening where it can. None of it is sufficient on its own, because the data women most need in order to understand themselves day to day does not live in clinical archives at all. It lives in the wellness layer.
It lives in the period app on the phone, the ring on the finger, the diary entry typed at 2 a.m. about a hot flash. It lives in millions of small private archives, kept by women who are tracking themselves because no one else thought to. This is where the data is. This is the layer the next generation of AI will need to be trained on if it is going to represent women's bodies as they actually are: in transition, in rhythm, in the texture of what women themselves notice and choose to record.
Some of that data is being trained on now. The big AI labs license what they can, scrape what they can't, and partner where the partnership produces a defensible corpus. The largest wellness operators have begun to train on their own data. A step forward. Also a sliver. Every operator's dataset is shaped by who they sold to. Rings do not work for women with arthritic fingers. Wearables sell at prices many women cannot pay and in form factors many do not want. Fertility apps describe women tracking fertility. Period trackers describe women who menstruate. Each company's dataset describes its users. None of them is the population. The combination begins to approach it.
So what if we built that combination together?
## The shape of what could be built
A cooperative of femtech and women's wellness operators. Member-built, member-governed, member-owned.
Here is what that means in practice. Each member operator runs training locally, on their own users' data, inside their own infrastructure. The data never leaves the member's environment. What does leave is the mathematical update, the encrypted summary of what the local model learned in a given round. Only that. A central process aggregates those updates into a shared global model. The members get access to the shared model on preferential terms. Non-members license it commercially. The protocols and tooling are open-sourced. The trained models, and the weights inside them, are the cooperative's collective intellectual property.
This is not theoretical. It is the architecture proved out by MELLODDY, the European federated-learning consortium of ten of the largest pharmaceutical companies on earth, all direct competitors, all holding proprietary chemical data they could not share. They shared a model anyway, by sharing the gradients and never the underlying data. Audited. Production-grade. Across borders, across the most paranoid IP regime in industry. It has been done.
The cooperative would be domiciled in Europe. That is deliberate, and it has consequences. The European regulatory ground supports cooperative governance, supports privacy by design, and, at this moment, shelters intimate health data from political pressures that elsewhere are moving in the wrong direction. The cooperative would begin in wellness rather than the clinical scope. That, too, is deliberate. Wellness data sits outside the heaviest regulatory regimes that govern clinical AI: outside US Protected Health Information rules under HIPAA, outside the European Health Data Space's clinical perimeter. The cooperative can launch under the EU AI Act's wellness obligations, which are real and which it must meet, without fighting clinical conformity assessments designed for software that diagnoses disease. Clinical comes later. Clinical comes with the right partners, on the right credentialing, by deliberate progression. Wellness is the door the cooperative can walk through now.
Building this once, together, is a different proposition than every operator building its own. Right now, every serious wellness company is paying for its own GPUs, its own engineering hours, its own electricity, in parallel, to produce proprietary models that each describe a slice of women. The cost is being duplicated. The result is being fragmented. The cooperative form is what makes one good model possible instead of many inadequate ones.
The form has a long history.
The Associated Press has held news distribution as a cooperative of member newspapers for nearly two centuries. Visa, before it went public, ran for decades as a member-owned association of issuing banks. Land O'Lakes is dairy farmers. Ocean Spray is cranberry growers. Mondragón is cooperatives at federation scale. In the digital era, OHDSI runs federated health-data research across more than eighty countries. What every one of these structures shares is that the people doing the work also own the work, and the value flows back to them on terms they wrote themselves.
The structure has been built before, in other industries, for other reasons. What would be new here is the application. A women's wellness operator cooperative, built privacy-first by architecture, oriented to representing this population correctly in the AI infrastructure of the coming decades, on terms its members choose.
In early 2026, Essity, Clue, Hertility, Daye, and Mooncup formed the Women's Health Visibility Alliance to challenge censorship of women's health content on social media. That coalition showed something useful. Operators in this sector will coalesce when the reason to coalesce is coordinated and clear. The reason for a wellness AI cooperative is larger. It is about who gets to be visible in the AI products of the coming decade, and on whose terms.
## How I came to be writing this
Around 2019, I began saying out loud that the domain in which I most wanted to see distributed systems do real work was health. The intuition was specific. The articulation was rough. I have been working out the difference ever since.
At Holochain, the work sat at the infrastructure layer: distributed systems, peer-to-peer architecture, the slow craft of making it possible for information to travel without aggregating power that should not be aggregated. Healthcare came up often in those conversations, because the values fit was so clean. Years of building sharpened the frame.
That sentence is the destination of seven years of thinking, not the starting point. I am not in clinical health tech and never have been. The questions I wanted to work on lived closer to daily life than to the doctor's office. That is how I came to the consumer wellness layer, and to building Cirdia, a privacy-architected intelligence engine for women's wellness, where the apps run pattern intelligence on each user's own data without aggregating that data into a central archive. The architecture is privacy-first because years working under the hood made it plain that privacy by promise does not last a funding round. Privacy by architecture might.
## What I am doing
There is no coalition to announce yet. No brand. What is in front of us is a set of conversations, in earnest, with people who might find this proposition compelling enough to help it emerge.
The work is real. Convening founding members. Designing governance that holds across borders and across decades. Writing privacy and consent standards a member would actually be proud to sign. Standing up the technical foundation, in pieces, with partners who have built federated systems before. Securing anchor funding from grants and philanthropic capital willing to underwrite mission-aligned infrastructure that markets, on their own, cannot build.
None of this is fast. None of it is easy. The cooperatives that have lasted all went through years of patient, unglamorous work before their value was visible from outside. The people I am gathering are the people who would do that kind of work.
Operators in women's wellness whose companies could be founding members. Technical leaders in federated learning, privacy-preserving computation, and cooperative infrastructure who have built this kind of system before. Philanthropic capital and program officers whose mandate is anchoring public-interest infrastructure that markets cannot build on their own. Convening authority in adjacent communities, trade alliances, women's health policy, AI governance: the kind that touches this work and would lend its weight.
If you are one of those people, I would value being in conversation with you. The brief I am working from is a document I share with people who want to see it. Not as a finished plan. As the shape of what I have so far, open to the people who would help shape it into something better.
You can reach me on LinkedIn, or send me a message [here](/contact).
---
*The infrastructure that will represent women's wellness in the AI of the next decade will be built one way or another. The question is by whom, and on what terms.*
*What I am doing is opening the conversation. What happens next depends on who joins it.*
---
## There Is No Privacy Paradox.
https://marycamacho.com/writing/there-is-no-privacy-paradox
Published: 2026-05-04
*A reaction to "In ChatGPT-Powered Virtual Influencers We (Dis)Trust?", Jin, S. V., Behavioral Sciences, 2026, 16, 651.*
A new paper in *Behavioral Sciences* examines what happens when ChatGPT-powered virtual influencers try to sell us things. Specifically: what predicts whether we will buy.
Most of the findings land where you would expect. People who feel they can benefit from AI trust ChatGPT more. People who trust ChatGPT more are more willing to buy what its avatars recommend. Lonelier users, with a higher need to belong, are more persuadable when access to AI is limited, and that gap closes when access goes up.
The finding worth sitting with is the last one.
Among users with **high access** to AI, the people who reported the **highest privacy concerns** also reported the **highest perceived benefits** of ubiquitous ChatGPT. Read that again. The people most worried about how their data is handled are the same people most convinced the system is good for them.
The literature calls this the *privacy paradox*: a long-documented gap between what people say about privacy and what they actually do online. The paper treats it as a psychological curiosity, a tension to be managed by better UI/UX and smarter targeting.
It is not.
## The mistake is treating the user as the unit of analysis
When you frame the privacy paradox at the level of the individual, it looks like irrationality. Why would a person who is afraid of how their data is used keep handing it over? The answer starts to feel like it has to be psychological. Cognitive dissonance. The seduction of convenience. Affective computing. The need to belong.
Step back one level and the paradox dissolves.
The user is not making a free choice between *privacy* and *benefit*. The system has been built so that the only path to the benefit runs through the data. There is no third option. There is no setting in which the user gets the recommendation, the assistant, the personalised reply, without also surrendering the input.
When you have engineered out the alternative, "willing disclosure" is no longer a meaningful category. The person with high privacy concerns and high access to AI is not paradoxical. They are coerced. They have correctly identified the cost, and they have correctly identified that there is no way to get the benefit without paying it.
That is not a paradox. That is a hostage situation with good UX.
## The model is not the point
There is a public conversation about AI privacy, and it has been almost entirely consumed by one question: *is this company training on my data?*
That is not a useless question. But it is a small one. And it has done useful work for almost everything else these companies are actually doing.
Sitting alongside the model is the platform. The platform is the same kind of thing every SaaS product has been since the early 2000s: a system that watches what you do. Which links you clicked from inside the chat. What you bought after a recommendation. What time of day you log in. How you configured your settings, your saved profiles, the persona instructions you gave the assistant about who you are. The new wave of AI health assistants is collecting all of this and more, regardless of what the company says about its training pipeline.
None of that is model training. None of it needs to be. It is platform telemetry. It is the same business model as ad-tech, as e-commerce surveillance, as enterprise SaaS upselling. The model is sitting in the middle of a Web 2.0 surveillance product.
When a company tells you it does not train on your data, that may be perfectly true and the platform layer is still doing the work. The promise is a narrow technical commitment about one channel, while the rest of the building is wired. The surveillance is happening upstream of the model, around the model, after the model. Almost anywhere except inside it.
This is why "make the model more private" is not a coherent answer to the privacy paradox. The model is not where the data goes when the data goes somewhere.
## What the paper does not name
The paper closes with practical advice for "UI/UX designers, digital marketers, and brand managers." It suggests using consumers' privacy settings to *customise marketing messages*. It suggests using follower counts as a proxy for the need to belong, so that virtual influencers can *better serve consumers' social needs*.
That is the recommendation set you arrive at when you accept that the data extraction is fixed and the only remaining variable is how skilfully to persuade.
There is another option. The paper does not consider it.
You can change the architecture.
You can build a system where the user gets the benefit without the system ever holding the input. Not as a policy commitment. Not as a privacy promise that the next acquirer can quietly walk back at the next funding round. As a structural fact: there is no centralised database. There is nothing in the warehouse to lose, sell, subpoena, or breach. The processing is ephemeral. The result is the user's. The company never sees the trail.
If you do that, the privacy paradox stops being a paradox. Not because users have learned to trust differently. Because the structural conditions that produced the paradox no longer exist. The trade-off was the bug. Removing the trade-off is the fix.
## Why this matters more in wellness than in shopping
The paper is about ChatGPT-powered virtual influencers selling products in e-commerce. The stakes there are real but bounded. A poorly chosen sweater. A recommendation that was actually a placement. A price you could have got cheaper elsewhere.
The same architecture is being deployed against intimate body data. Cycle tracking. Sleep. Mood. Reproductive intent. Symptoms. Sexual activity. Diary entries about the body that the user typed in themselves. These end up in the same kinds of centralised databases, governed by the same privacy promises, subject to the same exit-pressure incentives that walk those promises back when an acquisition is on the table.
A logged diary entry about a missed period is not less sensitive than a sensor reading. In a database, they sit on the same shelf.
The coercion is also more acute. Health is the place where people feel they have already run out of other options. They have struggled to get a useful answer from a provider in a fifteen-minute appointment. They have searched the open web and hit paywalls, ad bombardment, contradictory advice, and content engineered for clicks rather than comprehension. They are not turning to AI for their bodies because they are reckless about their data. They are turning to AI because every other path to a clear, plain-language, contextual answer about their own body has been broken or monetised out from under them. Broken information. Broken access. Broken time. AI walks into a vacuum the rest of the system created, and then the architecture extracts.
The privacy paradox in those systems is not a curious finding for marketers. It is the operational mechanism by which intimate data is harvested at scale from people who knew exactly what was happening and could not afford to opt out.
That is the real implication of this paper, even though the paper does not say it. When the only way to get a benefit is to give up the data, *high concern plus high access* will reliably produce high disclosure. The paper has documented the trap. The trap is what we should be talking about.
## The structural question
There is a single question that cuts through this entire literature, and it is the one I keep coming back to when people ask how to design a "trustworthy AI interface."
It is not "how do we make users trust us."
It is not "how do we communicate our privacy policy more effectively."
It is not "how do we calibrate the marketing message to the user's privacy settings."
It is: **how is it structurally impossible for the company to ever hold user data?**
That question has an answer. It is not easy, and it is not free, and the engineering decisions it forces are real. But once you build for it, the privacy paradox is not a finding in your user research. It is a relic of the architecture you replaced.
Until then, every paper that documents the paradox is documenting the same thing: a market being asked to choose between participation and protection, and correctly noticing there is no path that offers both.
The job is to build the path.
---
## Pre-Authorized
https://marycamacho.com/writing/pre-authorized-claude-desktop
Published: 2026-05-01
*A forensic report on Claude Desktop's silent browser-bridge installation is the AI industry's Flo moment. The same consent-stretch pattern femtech already learned, now playing out at the assistant layer.*
Source: [thatprivacyguy.com/blog/anthropic-spyware](https://www.thatprivacyguy.com/blog/anthropic-spyware/)
When you install an app, you expect it to do what it said it would do. Nothing more.
A forensic report published April 18 by privacy researcher [Alexander Hanff](https://www.thatprivacyguy.com/blog/anthropic-spyware/) says Anthropic's Claude Desktop, the macOS app for the company's AI assistant, does considerably more. On installation, it silently configures seven of your browsers to give a future Anthropic browser extension access to whatever sites you're logged into. The extension doesn't exist in any documented form a user could review. The doors are already open.
The user was not asked.
This is the architectural failure model I keep pointing at. Worth slowing down on, because the pattern is the same one wellness tech has been litigating for the last decade.
## The Permission You Granted, and the Permission You Didn't
The extensions don't exist yet in any documented form a user could reason about. The manifest is the door. The door is open. The user who walked through the front door of "install this AI helper" did not see the seven side doors that opened automatically when they did.
This is the same move that produced the Flo verdict.
In that case, users "consented" to a privacy policy. They did not consent to embedded Meta SDKs receiving their cycle data, their sexual activity logs, their fertility intent. The policy was a mile wide; the architecture was a sieve. A San Francisco jury in August 2025 decided the gap between what users agreed to and what the system did was actionable, at up to $5,000 per violation against millions of users.
The Claude Desktop pattern, as the report describes it, is that gap encoded in code. The user agreed to the app. The app extended the user's authority to bridges the user never saw.
This is what I mean when I say compliance is not privacy. A click-through can satisfy a regulator. It does not produce trust. Trust is what's left when the architecture wouldn't permit the surprise in the first place — and the user is certain about that.
## The Receipts
This is not a thought experiment. The author of the report ran a forensic audit on his MacBook and reproduced the findings on a second machine. The trail is specific.
When you install Claude Desktop, the app silently writes identical configuration files into the directories of seven browsers: Chrome, Brave, Edge, Chromium, Arc, Vivaldi, and Opera. Several of those browsers were not installed on the test machine. Claude Desktop wrote them anyway, ready to activate the moment one of those browsers is ever installed.
Each file pre-authorizes three specific Anthropic-owned browser extension IDs to invoke a helper program that runs outside the browser's protective sandbox at the user's full privilege level. The helper is signed and notarized by Anthropic and shipped through Claude Desktop's normal release channel. This is not a bug or a leftover from an internal build. It is intentional, production-grade infrastructure.
The macOS operating system stamps each file with a tamper-resistant signature identifying which application wrote it. The signature on every one of these files matches Claude Desktop's own log file. Across two machines, the author counted 31 separate installation events. The files are rewritten on every launch. **Deleting them does nothing. They reappear.**
Anthropic's published documentation states their browser integration supports Chrome and Edge, and is "not yet supported on Brave, Arc, or other Chromium-based browsers." The shipped behavior installs into all of them, plus three more.
Once a paired extension activates the bridge, the documented capabilities include reading the user's logged-in state on every site, reading the rendered contents of any page (the part HTTPS decrypts on the user's screen, including private messages, mid-typed forms, and on-screen two-factor codes), and filling form fields. Anthropic's own published research puts the prompt-injection success rate against this capability at 11.2% with current mitigations. That is roughly one in nine attempts by an attacker, using hidden instructions on a webpage, to hijack the assistant into doing something the user did not ask it to do.
The author argues, in his professional opinion as a privacy specialist, that this constitutes a direct breach of Article 5(3) of the EU ePrivacy Directive, which requires informed consent before storing or accessing information on a user's device, alongside potential exposure under various computer access and misuse statutes.
I am not a lawyer. I am a founder who builds for an audience that has been on the wrong end of consent stretching before. What I will say is this: the legal argument is serious enough that the next move is not Anthropic's marketing team's to make. It belongs to their general counsel.
## Why This Matters for Women's Health
The browsers Claude Desktop writes into are not abstract. They are where women type the things they have not told anyone else.
The message to a gynecologist describing six months of bleeding she has not mentioned to her partner. The free-text field in a fertility portal asking how many cycles she has been trying, what the last loss looked like, what she is willing to do next. The pelvic pain diary kept in a browser tab. The postpartum depression screening. The mid-composed email to an oncologist she has not yet sent. The 2am search bar: *is this normal?*, *am I overreacting?*.
Authenticated browser sessions are where the most intimate health writing of midlife now lives, and most of what makes it intimate is the text itself. Not the metadata. Not the visit timestamp. The words.
The report quotes Anthropic's own documentation: Claude "shares your browser's login state, so it can access any site you're already signed into," with capabilities for "data extraction" and "form filling."
That language describes a clinician's worst-case scenario hiding inside a user's productivity tool. A patient who tracks perimenopause symptoms in an app, books a hormone-therapy consult through a portal, and runs an AI assistant on the same laptop is not running three separate trust relationships. She is running one device, and the assistant has been pre-authorized to reach across all of it.
The threat model is not exotic. It is already in the room.
This is why we don't ship products that depend on the user trusting a corporate policy not to do what the architecture quietly enables. It is why wellness data on Cirdia's products is not retained in centralized servers in the first place. The architecture decides what is possible. The policy describes what is promised. Promises can be revised in the next version of the terms.
## The Pattern, Named
Three signals to read this story by.
**As a business signal:** the AI industry is reaching the point wellness tech reached in 2021, when "we got consent" stopped being enough and juries, regulators, and users started asking what the user could actually have understood. The Flo verdict was the turning point for femtech, with statutory damages of up to $5,000 per violation under California's Invasion of Privacy Act stacked across millions of users. The forensic finding here, if it holds up to scrutiny by other researchers, points at a comparable exposure surface for an AI vendor, with a parallel set of European levers in the ePrivacy Directive (Article 5(3)) the author cites. Either jurisdiction prices the same architectural choice into the billions. This is not a theoretical risk surface. It is a balance sheet.
**As a product signal:** users will feel this before they can articulate it. The unsettled feeling that something was done in their name, on their machine, that they did not authorize. They will not file lawsuits. They will quietly switch tools. The retention curve will bend. The product team will read the bend as a marketing problem and propose a campaign. It is not a marketing problem.
**As an architectural requirement:** the only response that holds up over time is to design systems where the pre-authorization cannot exist. Where "the AI helper extends your authority into seven browsers" is not a configuration option but a structural impossibility. Where what the user sees on the install screen is what the user gets, and nothing else.
## What Founders Should Take From This
The AI tooling boom is repeating the surveillance-tech playbook at compressed timescale. The pattern of consent at point A used to license behavior at point B, the one that took the wellness industry a decade to litigate, is now playing out in months at the assistant layer.
For anyone building in health-adjacent AI, particularly anything touching women's health: do not assume that because your product sits downstream of a model, the architectural choices upstream are someone else's problem. Your users do not draw that line. They see one experience and one trust relationship. If the AI assistant on their laptop can read their browser-authenticated session with their fertility clinic, that is your product surface, whether or not your code wrote it.
The defensible position is to encode least authority at every layer you touch. Don't bundle SDKs you can't audit. Don't depend on third-party assistants that pre-authorize themselves into your users' authenticated sessions. Tell your users, in plain language, what your system can and cannot reach. Then build a system where the plain-language answer remains true after the next release.
## The Agreement That Matters Most
A user who installs an AI assistant is not consenting to an architecture. They are consenting to an outcome, the help they came for. When the architecture extends past the outcome, the consent does not stretch with it.
The work of building wellness technology women can trust starts with refusing that stretch. Not because the law requires it, though increasingly it will. Because women have spent the last decade learning, from Flo and from a dozen quieter cases, that the policy and the system are not the same thing.
---
*Source: ["Anthropic secretly installs spyware when you install Claude Desktop,"](https://www.thatprivacyguy.com/blog/anthropic-spyware/) thatprivacyguy.com, April 18, 2026.*
---
## The $5B Wake-Up Call
https://marycamacho.com/writing/the-5b-wake-up-call
Published: 2025-08-15
When a San Francisco jury ruled that Meta intentionally intercepted menstrual health data from millions of Flo users, it wasn't just another privacy violation. With penalties of up to $5,000 per violation, Meta faces potential liabilities in the billions — roughly half of what Google paid for Fitbit.
For health and fitness app founders, this isn't just a cautionary tale. It's a fundamental shift in how the market values intimate data privacy, and a signal that surveillance-based business models may have hit their liability ceiling.
## The SDK trap that blindsided an industry
The Flo case exposes a blind spot affecting most consumer health apps: third-party SDKs that quietly transmit user data without explicit developer oversight. Flo integrated Facebook's SDK for analytics and marketing. That SDK automatically collected behavioral metadata — when users opened the app, which features they accessed, timing patterns around symptom logging.
Even without accessing diary entries directly, this metadata created detailed behavioral fingerprints that could predict menstrual cycles, fertility windows, and sexual activity. Flo's legal team argued the company wasn't a healthcare provider and users had agreed to their privacy policy. Meta got hit with the billion-dollar judgment anyway.
The legal precedent is stark: embedding third-party SDKs that collect intimate behavioral data creates liability, regardless of what your privacy policy says.
## What industry insiders are seeing
As someone building in this space, I've witnessed something that reveals the depth of this market shift. When we actually asked women what they wanted in health tech, they responded with unprecedented enthusiasm. We collected over 1,200 detailed surveys in 30 days, representing more than 60% of our waitlist signups during that period.
The insight isn't just that users value privacy — it's that they desperately want to help design the tools they'll use, but are rarely given the opportunity. This level of engagement signals pent-up demand for alternatives.
The Meta case also reveals something telling about industry assumptions. Meta chose to fight this in court rather than settle, likely confident their legal interpretation would prevail. That was a potentially expensive miscalculation. A jury of ordinary people concluded that existing privacy laws hold companies to a higher standard than many tech lawyers believed possible.
## Why body data hits different
This case highlights something the broader tech industry has been slow to recognize: users have fundamentally different privacy expectations for intimate health data compared to social media or e-commerce activity.
While consumers readily trade their shopping habits or social posts for free apps, biometric and reproductive health data triggers different psychological responses. The 23andMe breach, Strava's military base revelations, and now the Flo ruling all follow the same pattern — users who accept data sharing in other contexts feel genuinely violated when it involves their bodies.
For health and fitness companies, this creates both massive risk and clear opportunity. The risk is obvious: traditional freemium models built on data monetization face mounting legal exposure in the post-Roe landscape. But the opportunity is significant — users will pay premium prices for products that credibly protect intimate data.
## The market is responding
Smart health and fitness companies are building privacy into their technical architecture rather than relying on policy promises. Instead of processing health data in the cloud and adding encryption as an afterthought, they're designing local-first systems where biometric data never leaves the user's device.
This isn't just about compliance — it's about sustainable competitive advantage. Companies like Cirdia are building wellness platforms where pattern intelligence runs without centralizing user data, using transparent architecture and giving users complete control over what is shared and with whom. Others are adopting federated learning models that can improve algorithms without centralizing sensitive data.
Market signals validate this approach. Health & fitness apps already convert at 30–43% in app stores¹ — significantly higher than the 25% average across all categories² and far above the 1–2% typical for most mobile apps³. Meanwhile, the broader mHealth market is growing at 14.8% CAGR⁴, and regulatory pressure is intensifying: Maryland became the fourth state to pass consumer health data laws in 2024⁵, following Washington, Nevada, and Connecticut.
## The new playbook for founders
The Meta ruling forces a fundamental recalculation for any health app using standard development practices:
**Audit your SDKs immediately.** Every third-party integration that touches user behavior creates potential liability. Facebook, Google Analytics, Mixpanel, Amplitude — they all collect behavioral metadata that can reveal intimate health patterns.
**Rethink your monetization model.** Ad-supported and freemium models that rely on user data will face increasing legal and market pressure. Direct-pay and subscription models suddenly look more attractive.
**Consider technical architecture early.** Privacy-by-design is easier to build from scratch than retrofit. Local processing, end-to-end encryption, and user-controlled data sharing aren't just nice-to-haves anymore.
**Plan for regulatory expansion.** This ruling establishes precedent that will likely expand beyond reproductive health to other intimate data categories.
The technical tradeoffs are real: more complex infrastructure, higher development costs, limited analytics capabilities. But the business case is increasingly clear — trust has become a differentiating feature users will pay for.
## The companies that get this right will own the next decade
This isn't just about avoiding lawsuits. The Meta ruling signals a permanent shift in how intimate data privacy is valued legally and commercially. Early market signals suggest users are ready to pay for privacy in health tech, regulatory momentum is building, and traditional surveillance models face existential risk.
The companies that recognize this shift early — and build accordingly — will capture the massive opportunity created by broken trust in incumbent players. Those that don't may find themselves defending billion-dollar judgments.
The market is finally starting to price that in.
---
**Sources:**
1. AppTweak 2024 data (30.8%) and Statista 2022 (43.3%) — App Store Conversion Rate By Category
2. AppTweak 2024 — US App Store average conversion rate
3. CleverTap Mobile Marketing Glossary — average mobile app conversion rates
4. Grand View Research 2024 — Global mHealth Apps Market Analysis (14.8% CAGR 2025–2030)
5. Inside Privacy — Health Privacy Developments to Watch in 2025
