On Sun, 1 Mar 2026 12:21:17 -0800
Danielle Foré <danielle@elementaryos.org> wrote:
> Hey Aaron,
>
> Thanks so much for starting this conversation. My initial inclination
> was that this should be a part of the accounts portal and
> accountsservice as well. I think long term that should still be the
> goal and I'd like to see an option argument added to the accounts
> portal to request more granular information.
>
> But as you said, we need a stopgap solution since we'll be expected to
> provide this information as of January 1st 2027. A few notes about the
> proposal:
>
> * Naming is hard, sorry to be this person. I think we should avoid
> the word "verification" and use "declaration". This information is
> explicitly not verified and simply what the user has declared their
> age to be.
I had chosen "verification" because the title's name is "Age
verification signals: software applications and online services." I
agree, this is not verified, it is simply declared, but the law chose
to use the word "verification", so I think it easier to show that this
mechanism was intended to implement the feature required by the law if
it's named accordingly. The law also seems to make provision for users
who declare a false age, stating "An operating system provider or a
covered application store that makes a good faith effort to comply with
this title, taking into consideration available technology and any
reasonable technical limitations or outages, shall not be liable for an
erroneous signal indicating a user's age range...".
> * I wonder about possible future and conflicting age brackets. Apple
> released a white paper
> <https://developer.apple.com/support/downloads/Helping-Protect-Kids-Online-2025.pdf>
> last year about their implementation plan which also includes a 9+
> bracket and I feel like they probably know something I don't know. I
> also feel like returning the actual cutoff age instead of an enum to
> map to a bracket makes it easier for app developers to comply. So for
> example we'd return "4" for the ages 1-4 bracket and "16" for the
> ages 13-16 bracket.
Agreed, and it might make things more flexible in the future for in the
event another state decides to implement similar laws but with
different age brackets. I think that's what you're getting to when
mentioning Apple's inclusion of a 9+ age bracket.
(It does look like offering more fine-grained information is
> * I think it would leak less data to return the most restrictive age
> bracket instead of an error in the event that an age bracket is not
> set
True, but it may also make it more difficult for non-root applications
to determine that the user hasn't specified their age yet, which may be
useful for prompting users for their age post-installation. (This will
be necessary for existing installations of various distros, and the
bill points out that this scenario does have to be dealt with.)
Applications that aren't responsible for setting the age value *should*
treat an error the same as they treat the most restrictive bracket (or
at least that's what I imagine would be the most reasonable course of
action), but applications that are responsible for setting the value
need to know the difference.
--
Aaron
