Re: Age Assurance Key Considerations

--Sig_/rgCx_hLZ.5GgtJKBDlWy/dl
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 5 Mar 2026 03:43:11 +0000
Anthony Ciani <[email protected]> wrote:

> Since you were the primary discussers, there are three key
> considerations for the age bracket or age assurance statutes:
>=20
>=20
>   1.  Date of Birth is considered as Personally Identifiable
> Information under various US Government regulations (FTC, NIST, DoW),
> and so cannot be collected or stored lightly.  It is also covered by
> EU's General Data Protection Regulation, the California Consumer
> Privacy Act, Health Insurance Portability and Accountability Act,
> Children's Online Privacy Protection Act, to list a few.

IANAL, but names are also PII, are they not? Most of the Linux distro
installers I've used over the years have asked for my name. Often I
give a useless value like "User", sometimes I give a pseudonym if it's
useful for distinguishing between multiple similar machines, sometimes
I give my real name.

I was also under the impression that these laws regulated an entity
that was collecting data from users (haven't done much study into it
though so I may be totally wrong here). An application requesting data
from the user to store locally isn't the same, an application might ask
for my date of birth because it wants to be able to display a "happy
birthday" notification every so often. The app author never gets the
age, so do these laws apply?

The sharing of age bracket information does provide the user's age to
other entities, but if a jurisdiction's laws require that, then one
assumes that law "wins" in that jurisdiction.

>   1.  The various statutes require storage of an "age bracket" or
> "signal", but this age bracket cannot be calculated (due to #1), and
> so must be user-configurable.  It must live under ${HOME} or some
> other location where the user can alter it.  Maybe
> ${HOME}/.age_bracket or ${HOME}/.age; except that age itself might be
> PII, and maybe even age bracket, which would mean that it cannot be
> collected or recorded at all.

California's law specifically required providing an age or date of
birth, simply declaring an age bracket is not permitted. If what you're
saying is true, then there is an irreconcilable contradiction between
the laws. As a not-a-lawyer, I'm not qualified to say if this is the
case, or which law should be followed if it is the case.

>   1.  The various statutes define different age brackets, and may
> define different standards of access, protection, verification, and
> control of the information.  Many of these requirements are likely to
> conflict, and as noted, transporting a computer into different
> jurisdictions could invoke different requirements.

One of the earlier proposals for how this could be worked around is to
ask the user what jurisdiction they're in. If they mis-declare their
jurisdiction, or forget to set it correctly, that isn't our fault. In
the absence of GPS hardware, there's no way for us to reliably
geolocate the user to change behavior based on jurisdiction.

> The brackets aren't standardized, which creates an implementation
> problem and an undue burden, or even impossible compliance.  Imagine
> traveling between jurisdictions and needing to recalculate the
> brackets from unavailable data, or restore brackets from data you had
> to irrecoverably delete.

In the worst case, an implementation can err on the side of reporting a
user as being younger than they are.

--
Aaron

> In the US, this regulatory nightmare is what the Dormant Commerce
> Clause (Healy v Beer) prevents.  The international version is
> International Comity (Soci?t? Nationale Industrielle A?rospatiale v.
> U.S. District Court).  Moreover, the statutes have very thin rational
> basis and are largely arbitrary: they don't require that the
> collected age bracket be used in any way; only that the app vendor
> could use it to automatically answer "are you over 13" when the app
> could simply prompt the user "are you over 13," and the user can lie
> either way since the user controls the data.  This goes to interest
> balancing (Pike v Bruce Church) or vagueness (Grayned v City of
> Rockford).  And then there's Reno v American Civil Liberties Union,
> which struck down age verification, which begs the question of why
> this is even being discussed.
>=20
> BTW, Google, Meta, and Internet Works advocated for this mess, mostly
> because they didn't need to solve it.  The MPAA was against it.
> Apple did not endorse it, and I'm surprised they are working on an
> impossible technical solution rather than a legal one.  Not sure
> about Microsoft, but they seem to care more about writing EULAs than
> proper statutory or regulatory compliance.
>=20
>=20
> Anthony Ciani
> Senior Scientist
> [Sivananthan Lab_LOGO 08JAN2010 small]
> Sivananthan Laboratories, Inc.
> 586 Territorial Drive Ste A
> Bolingbrook, IL 60440
> 630.226.0080
> 630.226.0081 Fax
>=20
> The contents of this email and any attachments are the proprietary
> property of Sivananthan Laboratories?. The information contained
> within is confidential and should not be shared, sold, or distributed
> without explicit permission of Sivananthan Laboratories?.
>=20


--Sig_/rgCx_hLZ.5GgtJKBDlWy/dl
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

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

iHUEARYKAB0WIQS8QsiCjFi4DcDBX+Q5rdye4jrrCAUCaaoffwAKCRA5rdye4jrr
CH0jAP9B9Hz6XU8p7dG8+PrgkACH2U4XHHN0EpRslRcv2yR9qAD+N8uMNgKjlxNI
BLScsxDLdr7LsgpRh9Zm7GKt03D5WQ0=
=DfT2
-----END PGP SIGNATURE-----

--Sig_/rgCx_hLZ.5GgtJKBDlWy/dl--