The age gate pockets your number and sells it

Section 1: Opening Claim

Age verification, as deployed, does not verify age. It collects identity. The systems marketed under that label gather phone numbers, emails, and birthdates from every user who passes through them. Per the facts available, that collected data is not used to confirm whether a user meets an age threshold. The label describes an intent. The data flow describes the actual operation. The two do not match.

A control is defined by what it enforces, not by what it is called. If the identifiers a system collects do not feed an age check, then age checking is not the function the system performs. The stated purpose and the operating purpose are different things, and here they diverge. When a control does not perform its stated function, it is not that control. It is something else operating under that name.

The confirmed downstream use is resale. The collected data is sold to advertisers and data brokers. That is the observable behavior. Protecting minors is the stated objective. Collection and resale are the documented mechanism. Named accurately, this is a data acquisition pipeline operating under a protection label. Everything that follows proceeds from that single distinction between what the system is called and what it does.

Section 2: The Original Assumption

The assumption built into these deployments is that collecting a phone number, an email, and a birthdate is required to confirm a user’s age, and that holding this data serves the goal of protecting minors. The assumption is rarely stated directly. It is embedded in the design. Submit your identifiers, and the act of submission is treated as the safety control. The user accepts this because the framing tells them the data exists to protect someone.

That assumption does not survive examination. Establishing that a user meets an age threshold does not logically require the retention and resale of their phone number and email. Confirming a fact about a user and collecting durable identifiers from that user are separate operations. The assumption collapses the two. Identity is the boundary. The moment a system collects and holds identifiers rather than checking a fact and discarding the input, it has crossed from verification into accumulation. Those are not the same activity, and one does not require the other.

The assumption is what enables the collection. Users surrender phone numbers, emails, and birthdates on the belief that these identifiers feed a safety control. The facts state the data is not used for that purpose. Whether these systems protect minors at all is not confirmed by the facts provided. What is confirmed is that the data is sold. The trust relationship runs in one direction. The user extends trust based on a stated purpose, and the stated purpose is not the operating purpose. Trust extended on a false premise is not a control. It is exposure.

Section 3: What Changed

The facts establish a gap between the label and the behavior. The collected data, phone numbers and emails and birthdates, does not verify age, and it is sold to advertisers and data brokers. The mechanism is described as a honeypot for credential harvesting. That term is precise. A honeypot concentrates data of value in one location. These systems concentrate exactly the identity fields that hold value, drawn from the full population of users routed through them.

Phone number, email, and birthdate are core fields in identity theft and account recovery. Aggregating them across a user base creates a single high-value target where one did not previously exist. This is the expansion of the attack surface the facts identify. The implication is logically necessary and does not depend on any specific breach: a centralized store of identity fields is a target, and the larger the store, the larger the target. The exact scale of any individual collection is not confirmed. The direction is not in question.

The facts name this a systemic failure in privacy controls. Defined in control terms, the boundary that should limit collection to what the stated purpose requires is not enforced. Data crosses past the verification function and into resale. A system that permits identifiers collected for one stated purpose to be repurposed and sold is not enforcing a collection boundary. It has none that hold. Controls that are not enforced are not controls. If a system allows the data it gathers to be sold, that is not a risk of misuse. It is the documented use.

Section 4: Mechanism of Failure or Drift

The mechanism begins with collection that has no consuming check. A user submits a phone number, an email, and a birthdate. The facts state these identifiers are not used to confirm age. The submission therefore terminates in storage, not in a verification operation. There is no point in the described flow where an age check consumes the input and releases it. The identifiers are retained. Retention with no consuming function is the first observable failure. The system accepts identity fields and holds them. It does not spend them on the task printed on the label.

The second part of the mechanism is repurposing. The retained data is sold to advertisers and data brokers. Collection authorized by one stated purpose feeds a different operating purpose. The drift is structural. The stated purpose authorizes the collection. The collection produces a store of identifiers. The store is monetized. Each step follows from the one before it, and none of them require an age check to occur. The age label is the entry condition for the pipeline. It is not a stage inside it. A function that is never executed cannot be the function of the system.

The third part is concentration. The facts describe a honeypot for credential harvesting, and that term is exact. A honeypot is defined by the concentration of valuable data in one location. Phone number, email, and birthdate are core identity and account-recovery fields. Drawing them from every user routed through the system aggregates them into a single store. That store did not exist before the system was deployed. The mechanism produces the target as a direct output of normal operation. Whether any breach of that store has occurred is not confirmed. The concentration does not depend on a breach. It exists the moment collection runs at scale. A breach would convert a standing exposure into a realized loss. The exposure is present without one.

Section 5: Expansion into Parallel Pattern

The pattern is verification implemented as collection. A check establishes a fact about a user. The fact, once established, does not require the underlying identifiers to be kept. When a system is built to collect and retain those identifiers in order to run the check, the identifiers outlive the check and become a store. This is the mechanism described in the age-verification case, stated at the level where the label drops away. The label is the only variable. The structure underneath it is fixed.

Read at that level, the failure is not a property of age verification specifically. It is a property of any control where the verifying step does not consume and discard its input. The check needs a fact. The system collects durable identifiers. The gap between those two is where the store forms. Wherever a one-time determination is built as durable collection, the same drift is available, because the same conditions are present: identifiers retained past the moment of use, and no boundary that limits collection to what the check requires. The mechanism reproduces wherever those conditions repeat. It does not require intent to reproduce. It requires only that the collection is not bounded.

Identity is the boundary, and this pattern moves it. A check that asks a single question about a user and answers it by keeping a durable identifier has converted a question into an asset. The asset persists. Any persistent store of phone numbers, emails, and birthdates carries the same value to an attacker and the same value to a buyer, independent of the front-end purpose that produced it. The supporting case is the one already described: the same fields, collected for a stated check, retained, and sold. The pattern is not a comparison to a different concept. It is the same mechanism observed wherever collection is not bounded to the check it claims to serve.

Section 6: Hard Closing Truth

Name the system by its data flow, not its label. The confirmed flow is collection of phone numbers, emails, and birthdates, followed by resale to advertisers and data brokers, with no age check consuming the data. Defined by that flow, this is a data acquisition pipeline operating under a protection label. The name on the front end is not a control. It is marketing applied to a collection function. Treating the label as the control is the error that lets the collection run.

What must now be true is a collection boundary that holds. A check consumes a fact and discards the input. Identifiers that do not feed the check are not collected, and they are not retained. If a system collects identity fields it does not need for the stated function and sells them, that is not a risk of misuse to be managed later. It is the documented use, occurring now. Controls that are not enforced are not controls. A privacy control that permits collected identifiers to be repurposed and sold enforces nothing, and the facts already name this a systemic failure in privacy controls.

If a system allows the data to be sold, the data will be sold. That is not a prediction. It is the behavior the facts record. The store of identity fields is a standing exposure for every user routed through the system, and that exposure exists whether or not it has yet been breached. Trust extended on the stated purpose does not validate the operating purpose, and trust that is not continuously validated is not a control either. Age verification, as deployed, verifies nothing. It collects identity and sells it. Define it that way, or keep funding the pipeline under its own name.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.