Consentful Software: Designing for FRIES

Most of us learned what real consent requires in a context that had nothing to do with software. Consent has to be freely given, reversible, informed, enthusiastic, and specific. Planned Parenthood turned that into an acronym people actually remember: FRIES.

In 2017, Una Lee and Dann Toliver did something quietly brilliant with it. In a zine called Building Consentful Tech, they pointed the same five tests at technology and asked: what if we designed software the way we're supposed to treat each other? They released it under Creative Commons so anyone could build on it. This is me building on it.

Your data is a body

Start with their reframe, because everything follows from it. You've got a physical body. You've also got a digital body: your data, your metadata, your attention, your history. Like your physical body, it can be harmed. Unlike your physical body, it's scattered across servers, databases, embeddings, logs, and third-party processors you've never heard of - usually without your awareness, and almost never with your real consent.

Once you see data as a body, "we collected some analytics" stops sounding neutral. You did something to a person. The only question is whether they agreed to it, and whether that agreement was real.

FRIES is how you check.

The five tests, pointed at your product

Run your data handling through each one honestly.

Freely given. Consent made without pressure or manipulation. In software: if the interface is designed to nudge people into something they wouldn't otherwise choose, it isn't consentful. Ask: can a user decline this collection and still use the core product? Or is "accept all" the only path that doesn't punish them? A choice between "yes" and "lose the thing you came for" isn't freely given.

Reversible. People can change their minds, any time. In software: users should be able to withdraw and actually have their data removed. Ask: is deletion real - gone from backups, caches, and embeddings - or cosmetic, hidden from the UI and retained forever? And how much harder is the opt-out path than the opt-in was? If it took one tap to say yes and six screens to say no, that's a design choice, and it's the wrong one.

Informed. Be honest, in language people understand. Ask: could a non-technical user actually understand what they agreed to? Are you disclosing data practices in proportion to their impact, or is the highest-risk use buried deepest in the terms? Here's the test I use: if a journalist described your data practices in plain language, would you be comfortable with the headline?

Enthusiastic. Not reluctant compliance - genuine willingness. In software: if people hand over data because they have to in order to get a service they need, that isn't consent, it's a toll. Ask: are users opting in because they want to, or because declining makes the product unusable? Would they still share this if they fully understood how it gets used?

Specific. Yes to one thing isn't yes to everything. In software: use only the data a user directly gave, for only the purpose they agreed to. Ask: if you want to use their data for something new - training a model, a new feature, a partner integration - do you ask again, or do you treat the original yes as a blank check?

A cross-tenant leak is a consent failure

Here's where this stops being philosophy and starts changing how you build.

Every engineer knows cross-tenant data contamination is a bug: one customer's data influencing another customer's results. We file it under security. But look at it through FRIES. When tenant A's data shows up in tenant B's experience, you've used person A's data for a purpose person A never agreed to. That's not just a security failure. It's a consent failure, and a specific one.

Which means row-level security, per-tenant isolation, and scoped retrieval aren't just security controls. They're consent controls. And consent controls belong in the product spec, not just the security review at the end. I've caught world-readable tables right before launch more than once, and every time it was because someone on the team treated "who can see this data" as a product question from the start, not a thing security would find later. The teams that ship consent failures are usually the teams where nobody owned the question until it was an incident.

Consent is ongoing, and it's bigger than your users

Two things the zine gets right that most product teams miss.

First, consent isn't a one-time checkbox. Saying yes once - linking a profile, sharing a location, granting a permission - shouldn't mean yes forever. The products getting closer to consentful are the ones that check in periodically and make changing your mind easy, not the ones that got a signature at signup and considered it settled.

Second, the people affected by your product often aren't your users at all. Someone tagged in a photo they didn't post. Someone whose contact info sits in a shared file. Someone whose data an AI feature surfaces without them ever opening your app. Consentful design considers the non-user at the table, which is exactly the person no roadmap prioritizes and no metric measures.

Why bother

Because the cost of getting consent wrong doesn't land on the company evenly. It lands hardest on the people with the least power to absorb it - the ones most likely to be surveilled, doxxed, outed, or harmed when a system leaks. Designing for FRIES is how you make sure the person who bears the cost of your data practices is the same person who got to decide about them.

Treat data like a body. Run it through five tests. Put consent in the spec, not the incident report. It's a low bar for how we say we want to treat each other. Our software should clear it.

Sources

• The FRIES framework, the "digital bodies" concept, and consentful technology come from Building Consentful Tech by Una Lee & Dann Toliver (2017), released under CC BY 4.0, which adapts Planned Parenthood's FRIES consent model for technology.