From Age Labels to Access Rules
The proposed Meta settlement now presents a connected problem rather than a set of separate clauses. The legal case defines the kinds of risk the states say Meta created; age assurance turns those legal categories into user states; and the product rules decide what those states mean in daily use. The useful judgment is whether a proposed protection has a clear trigger, changes a real behavior, gives authority for any exception, and can be checked without hiding its costs.
That four-part test matters because “protect children” is too broad to evaluate. A rule can name a protected group but leave the interface unchanged. A default can change the interface but be easy to evade through another account. A measurement can show that a switch was flipped without showing whether the switch controlled the behavior that mattered. The proposed agreement is strongest when these pieces connect—and most uncertain when one of them is only promised or defined in general terms.
A default is a four-part control loop
Start with the legal track. COPPA supplies an under-13 privacy boundary: the FTC’s summary identifies services directed to children under 13 and services with actual knowledge that they collect personal information from a child under 13. The states’ broader consumer-protection allegations concern the design and description of Facebook and Instagram for young users, including teenagers. The proposed consent judgment joins these concerns in one negotiated package, but joining them does not erase their different functions.
The legal terms answer a question of authority: what conduct are the states asking Meta to change, and under what agreement could that change become binding? They do not, by themselves, tell the product exactly which screen to show or which counter to increment. That work appears in the operational provisions. The agreement defines U13 users and Teen Users, sets age-assurance requirements, and then attaches different product and data duties to those states. The legal category is the reason for the control; it is not the control itself.
The second part is the user state. A state is a condition that can change what the system does: an account may be unassessed, treated as a teen, classified as a Teen User, or placed in a U13 enforcement process. The proposed framework does not make uncertainty disappear. An account that has not been assessed receives provisional protections, and after the initial period an account still not assessed is treated as a Teen User regardless of its stated age, with specified protections for accounts stating that the user is an adult. This is a design decision about risk: the system favors a protective starting position instead of treating missing information as proof of adulthood.
The third part is the product default. It is the behavior that occurs without an extra act by the user or parent. In the agreement, a teen state can activate limits on time and notifications, choices about feed ranking, reduced visibility of likes or reactions, content-safety settings, and contact warnings. For a likely U13 user, it can activate a detection and removal process. A default is therefore more than a preference in a settings menu. It determines which path is ordinary and which path requires effort or permission.
The fourth part is authority and verification. If a teen or parent can make a setting more restrictive, that is one kind of authority. If a less restrictive change requires a Supervising Parent, that is another.