Re: IAB Statement on Age-Based Restrictions and Online Safety

Hi IAB,

In the mostly reasonable statement below, I think you (the
IAB) have made an implicit assumption that services should
be enabled/encouraged to grow to sizes beyond which they
can actually do things like moderation, as is largely the
case today with pretty much all the mega-commercial services
and other too-big entities.

Did you consider whether an Internet that consisted of many
much smaller service providers might be better than the one
we have today in terms of being less likely to result in the
imposition of age related restrictions by regulators? Would
or could some form of re-balancing sizes also help mitigate
some of these issues?

Do you know of a place where a discussion on this topic might
be had? (cc'ing [email protected] in case someone does)

Thanks,
S.

PS: Sorry, I didn't manage to produce a paper for the w/s.

On 24/08/2026 17:21, IAB Executive Administrative Manager wrote:
> The Internet Architecture Board has posted a new IAB Statement on Age-
> Based Restrictions and Online Safety.
> 
> View this statement in the Datatracker: https://datatracker.ietf.org/
> doc/statement-iab-statement-on-age-based-restrictions-and-online-
> safety/
> 
> The Internet Architecture Board (IAB) provides long-range technical
> direction for the Internet's development. The IAB has been guided
> since its origins in 1979 by the design principles that make the
> global, open Internet what it is.
> 
> IAB Workshop
> 
> The IAB shares the goal of protecting children online, and recognizes
> the urgency families and policymakers feel. In late 2025, we held a
> joint Workshop on Age-Based Restrictions on Content Access with the
> W3C to examine these issues with technical experts, child safety
> specialists, civil society participants, and policymakers. We
> encourage interested parties to review the resulting report,
> published as RFC 9998.
> 
> Concerns with Current Proposals
> 
> Many current efforts frame age restrictions as something a service
> provider or the network infrastructure enforces, by compelling them
> to establish that their users are of an appropriate age.
> 
> We are concerned that these approaches will fail, leaving youth less
> safe on the Internet. Mandating the creation of unproven new
> infrastructure (e.g., third-party age-assurance services) will
> concentrate sensitive data about everyone into a small number of high-
> value targets. Requiring individual sites to collect such data
> reduces online privacy and increases risks of identity theft.
> 
> An alternative approach would require networks to block access to
> services that do not perform age assurance. It fares no better:
> identifying which services to block requires visibility into traffic,
> putting pressure on the encryption every user, business, and
> government relies upon (see RFC 7754).
> 
> All of these approaches share a further weakness: many youth will
> route around them using techniques — free VPNs of unknown provenance,
> shared or fraudulent credentials, gray-market apps — that expose them
> to more cybersecurity risks.
> 
> Furthermore, building age-based restrictions in these ways risks long-
> term disruption to what societies, economies, and governments expect
> from the Internet. Architectures that entrench age-assurance vendors
> as gatekeepers create additional points of centralization for the
> Internet, with potential impacts on reliability, security,
> competition, and digital sovereignty.
> 
> When mandates differ significantly between jurisdictions, they also
> fragment the Internet. Services facing incompatible requirements will
> exclude users in some jurisdictions rather than satisfy all of them,
> making the Internet less global.
> 
> Most of these problems have common roots: the placement of controls
> in the network or on the services being consumed, and the disclosure
> of identity to a site or an intermediary each time age is
> established. Because today’s age-assurance proposals are largely
> vendor offerings certified against regulatory criteria, system-level
> properties like resilience, privacy, and decentralization often
> escape scrutiny.
> 
> Requirements for Workable Solutions
> 
> We argue that avoiding the outcomes described above requires certain
> properties, whatever technology delivers them. These include that the
> mechanism performing age assurance:
> 
> - discloses no more than a minimal purpose-specific age signal; -
> does not report the user's activity to anyone; - does not produce
> signals that can be linked across sites; - does not disclose those
> sites to the party that established the user's age; - does not create
> a centralized store of sensitive data; - does not create other
> significant harms or burdens for Internet users of all ages; and - is
> mediated through open, interoperable interfaces developed through a
> multi-stakeholder process.
> 
> We assess that given the current maturity of enabling technologies,
> mechanisms built into an end user's device are the most promising.
> Age signals established at the device can, in principle, confirm that
> a user is old enough to reach some content without disclosing
> identity to every site, without those checks being linkable across
> sites, and without concentrating sensitive data into a handful of
> high-value breach targets.
> 
> Device-based mechanisms do not remove the need to establish a user's
> age, and they give device and operating system vendors considerable
> leverage. But unlike the alternatives, the check can run on hardware
> the user holds, under their control, rather than on an intermediary's
> servers. But that depends on the interface between device and service
> being an open standard any device, operating system, or browser can
> implement — one that would require websites and services to request
> an age signal rather than collect identity themselves. Robust multi-
> user support on shared devices is also needed from mobile operating
> system vendors.
> 
> Conclusion
> 
> The building blocks of a privacy-preserving, user-controlled solution
> can be built — but not overnight, and not if the pressure to act
> immediately locks in today's designs first. Hastily deployed
> solutions are hard to dislodge once economic incentives and
> widespread dependency form around them; in Internet architecture we
> call this ossification, and it is a standing constraint on our
> ability to improve the Internet later, including the ability to adopt
> the better designs that could actually help families. A failed
> deployment is likely to set child-safety goals back further than a
> delay would.
> 
> Mandates should specify outcomes rather than particular technologies,
> so better mechanisms can be adopted as they mature; require open,
> interoperable interfaces, so no single vendor or platform becomes
> indispensable; and leave room for the standards work to happen.
> 
> _______________________________________________ IETF-Announce mailing
> list -- [email protected] To unsubscribe send an email to ietf-
> [email protected]

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQQwbnhHy1kPJkWsM6fk2On5l6gz3QUCaoySVAUDAAAAAAAKCRDk2On5l6gz3fhF
AP4qiqxd6Jo/RzifMyVJ3nzCu/ZrQRMXlVj5QdzdsGKYOQD+PciKpSXEDHK3oh6f2VS46rQyhd99
55NIEe5yxa41LQI=
=mzBF
-----END PGP SIGNATURE-----