A family is not an account

The identity systems I am building on were designed for one user: an adult, acting alone, owning their own data. That assumption is everywhere — in how accounts are created, how sessions work, how a product decides what you are allowed to see. Nowhere in it is there a place to say “this person is six, and that person is responsible for them.” So the first real question of this whole effort is not a feature. It is whether the word ‘family’ can exist in a system that has only ever understood the individual.

The tempting answer is a new account type. Make a ‘child account,’ give it special rules, and every product can branch on it. I keep coming back to why that is a trap. A child under thirteen, created by a parent, is one case. But families also want to supervise a teenager who already has years of mail and contacts and purchases. That account isn’t a child account and never was. If ‘supervised’ means ‘is a child account,’ then the day a child turns thirteen the model has to lie, or break, or force a migration nobody asked for.

So I am arguing for supervision as a relationship, not a type. The truth of “who supervises whom” lives as an edge between a person and their family group, in the central relationship store. A child account implies that relationship; an existing account can opt into it. Every downstream product (Search, Play, the device) checks one thing: is this person supervised, and what may a parent do for them. They do not have to re-derive what a family is. They ask one question and get one answer.

The day a child turns thirteen, nothing in the account should have to be reborn. The relationship just changes its terms.

There is a separation I am being almost pedantic about, and I think it will matter for years. ‘Is this account supervised?’ and ‘does this account require COPPA treatment?’ are different questions, and I want different flags answering them. It is so easy to collapse them — supervised and under-thirteen feel like the same thing in 2016, because today they almost always are. But the regulatory obligation and the parental relationship are not the same fact, and the moment we serve teens they come apart. If we fuse them now, some service three years from now will check the wrong one and we will have a policy bug wearing the mask of a feature.

What makes me uneasy is that I’m choosing the harder build today to protect a flexibility I can only assert, not prove. The account-type approach would ship faster. Auditing what each consuming service means when it asks “is this a kid” is slow, unglamorous work, and I cannot point to the user who will thank me for it. I’m betting that ‘a family is a graph of relationships, not a special kind of user’ is the assumption the next five years will keep leaning on.

And I don’t fully know yet whether the products will respect the line we’re drawing, or quietly route around it the first time the relationship model is inconvenient. The model is only as honest as the least careful service that consumes it. That part isn’t settled, and won’t be for a while.