Age Signaling and Interface Documentation and Design for Kicksecure

From Kicksecure
Jump to navigation Jump to search
Design Previous page: Dev/cryptography Index page: Design Next page: Dev/Password Manager Age Signaling and Interface Documentation and Design for Kicksecure

This page documents potential operating-system age-signaling (age-bracket) interface requirements that may apply in some jurisdictions, and what they could mean for Kicksecure. It summarizes background, status, privacy and fingerprinting considerations, a draft setup prompt and its rationale (age vs DOB, "primary user" wording, mandatory entry, no defaults), alternatives, legal considerations, objections, and links to related upstream discussions.

draft DRAFT!

Disclaimer

[edit]

This is not legal advice. As per Terms of Service wiki chapter, there is No Legal Advice.

The Services are not for use by anyone under the age of 18.Terms of Service chapter Minimum Age

Introduction

[edit]

Some jurisdictions are proposing or enacting rules that require an operating system provider to expose an account setup interface that collects a birth date, an age, or both, for the purpose of signaling an age bracket to applications.

Background

[edit]

Law passed, effective from January 2027:

Draft (pending, moving) law:

This is unspecific to Kicksecure.

Most Linux distributions and most general purpose operating systems may be affected.

App Store and Device-Level Age VerificationEFF: The Year States Chose Surveillance Over Safety: 2025 in Reviewarchive.org iconarchive.today icon

law firmarchive.org iconarchive.today icon blog post: New laws in some states require app developers to verify users’ agesarchive.org iconarchive.today icon

Open questions:

  • server
  • Will server operating systems also have to comply?
  • A typical headless server deployment often has:
    • no "account setup" in the consumer sense, and
    • no "app store" experience aimed at end users (even though it installs packages).
    • AB 1043 defines "User" as a child who is the primary user of the device, which fits consumer devices much more than servers.

Absurdities:

Other Projects

[edit]
[edit]

More

[edit]

California results are not authorized to use MidnightBSD for desktop use in the state of California effective January 1, 2027. California law CA AB1043archive.org iconarchive.today icon requires a complex age verification system implemented for operating systems with no exceptions for small open source projects.https://github.com/MidnightBSD/src/commit/7d956a27123f2d77a05313826c29a0329a923254archive.org iconarchive.today icon

Kicksecure

[edit]

Privacy Friendly Choice

[edit]
  • Users may misstate age: One might expect users to lie about their real age.
  • Bracket-preserving entries: From the user's perspective, it might make sense, for privacy, to provide an age within their age bracket without revealing their real age.
  • Family friendly example: For a family friendly experience, a user might choose an age of 10 even if they are older.
  • Adult example: Someone of a higher age might choose 18 even if they are much older.
  • No recommended defaults: However, for legal reasons, it may be prudent for Kicksecure to abstain from recommending privacy friendly defaults.

Fingerprinting Risk

[edit]

Kicksecure (and WhonixOnion network Logo) specific fingerprinting impact.

draft DRAFT!

  • TODO: This is still being discussed. #Alternatives might exist.
  • What "fingerprinting" means: Fingerprinting is when an app tries to recognize a device by checking for differences between systems. A value that is the same for almost everyone does not help with that. Related: system identity camouflage and VM FingerprintingOnion network Logo.
  • Low to very low risk: Most installations will likely end up with the same age-bracket value, which reduces uniqueness.
  • No ID verification mandated: The law does not mandate ID verification.
  • Age only: The user is only asked to enter their age. Related: Prompt for Age instead of Age Bracket
  • Under 18 years age use prohibited by ToS:

The Services are not for use by anyone under the age of 18.Kicksecure Terms of Service (ToS) chapter Minimum Age (since at least 2019)

  • ToS denial: If a user enters an age under 18, setup-wizard-dist will prohibit use per ToS.
  • Expected on-disk value: On most (if not all) Kicksecure systems that upgrade the operating system, there will be a file $HOME/.age-api/age-bracket (file path and name not finalized at the time of writing) containing 4.
  • What 4 means: The number 4 is intended to be an internal code for the selected age bracket (meaning 18+).
  • What is not stored: The user's date of birth (DOB) or exact age is not stored on disk by this mechanism. If a user enters an age or DOB, it should only be used to determine the age bracket, and then only the bracket code (such as 4) is stored.
  • Why this lowers fingerprinting risk: If most systems contain the same value, it does not meaningfully help apps to distinguish one user from another. Therefore, the impact on fingerprinting risk is likely low.

Kicksecure for Qubes

[edit]

Potential effect on Kicksecure for Qubes and Qubes-WhonixOnion network Logo. This is unknown at this point. No changes might need to be made to any Qubes Templates maintained by the developers of Kicksecure and Whonix.

At this point, it has not yet been discussed with the maintainers of Qubes OSarchive.org iconarchive.today icon how they plan to react, if at all, to the age verification law.

Since Qubes OS may be the entity distributing Templates, the decision of what Templates can and should do will ultimately rest with the Qubes maintainers.

Qubes upstream ticket: legally mandatory age verification API compliance may be required #10744archive.org iconarchive.today icon

Qubes forum discussion: How much do we gotta worry about this Linux “age verification” BS?archive.org iconarchive.today icon

Interface Design Choice Details

[edit]

Interface Design Draft

[edit]

What is the age (in years) of the primary user of this device?

[ age input box ]

Computed age bracket (not selectable): [ Under 13 | 13 to under 16 | 16 to under 18 | 18 or older ]

Note: To support age-bracket signaling for applications (for legal compliance in some jurisdictions), this interface asks for an age in years rather than an age bracket.

Privacy: The entered age is used only to compute the bracket and is not stored. Only the computed bracket is stored locally in the file ~/.age-api/age-bracket.

Note: This is not legal advice.archive.org iconarchive.today icon

For further information, see age-api.

Mandatory Blocking

[edit]

Device/account setup must be required. Bold emphasis added.

1798.501. (a) An operating system provider shall do all of the following: (1) Provide an accessible interface at account setup that requires an account holder to indicate the birth date, age, or both, of the user of that device for the purpose of providing a signal regarding the user’s age bracket to applications available in a covered application store.

Age of the Primary User Wording

[edit]

Why ask the awkward question What is the age (in years) of the primary user of this device? instead of How old are you? Because the law requires asking for the age of the user, not necessarily you.

(i) “User” means a child that is the primary user of the device.

Age versus Date of Birth

[edit]

Bold added. Underline added.

1798.502. (a) With respect to a device for which account setup was completed before January 1, 2027, an operating system provider shall, before July 1, 2027, provide an accessible interface that allows an account holder to indicate the birth date, age, or both, of the user of that device for the purpose of providing a signal regarding the user’s age bracket to applications available in a covered application store.

Prompt for Age instead of Age Bracket

[edit]

Why prompt for the age instead of the age bracket? The law clearly asks for date of birth or age and not for an age bracket.

1798.502. [...] allows an account holder to indicate the birth date, age, or both, [...]

No Default Choice

[edit]

Why not configure "under 13" or "older than 18" by default?

1798.502. [...] allows an account holder to indicate the birth date, age, or both, [...]

Therefore, a family friendly by default or adult by default setting is not permissible.

Alternatives

[edit]

Jurisdictional avoidance / additional policy gates.

Prompt.

Are you currently located in, or ordinarily resident in, any comprehensively sanctioned jurisdiction (for example Cuba, Iran, North Korea, Syria), or acting on behalf of someone located there?

Not offered in certain US states

Are you currently located in, or ordinarily resident in, California?

Or are you acting on behalf of someone located there?

  • [ Yes ] | [ No ]
  • If Yes → prohibited.

Instead of being an alternative, this might be a separate legal defense layer.

Objections

[edit]

Status / timeline

[edit]
  • This is only a draft: Not a draft. The law has passed and is final. It will come into effect in January 2027.

Applicability / scope

[edit]
  • Not applicable: Unfortunately it is applicable.

    (g) “Operating system provider” means a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device.

  • Applies to commercial vendors only: There is no passage in the law that limits this to commercial vendors.
  • A VM is not an operating system (OS): Possibly. Risky. This is an unresolved legal question.

Jurisdiction / enforceability

[edit]
  • Jurisdiction not applicable:
    • Financial analogy: It's similar to a financial service, like a bank account. An EU bank providing financial services to the USA, Canada, etc., will not do that unless they are authorized by the banking authority of that country (USA, Canada, ...). Banks outside the USA are typically very careful when onboarding U.S. customers, either complying fully or rejecting U.S. persons. Even non-U.S. persons must sign FATCAarchive.org iconarchive.today icon forms, where they must confirm that they are not a U.S. person.
    • Weak argument risk: Hard argument to make solid. Someone can point out "but there's an agreement where this isn't necessary in this specific case", thereby creating the impression that the argument is generally junk.
    • Common misunderstanding: It may be a common misunderstanding to think "CA" means "California companies".
      • User scope: AB 1043 is written around users in California, not around where the operating system distributor is headquartered. The definition of "account holder" is tied to a user "under 18 years of age in the state."
      • What "CA" refers to: "CA what?" Residents? Visitors? Distributors? Devices? The statute does not say "OS providers incorporated in California." It regulates "operating system providers" and "covered application stores" generally.
    • Law "hook": The hook is typically where the affected users/devices are (California), and then whether California can exercise jurisdiction over the provider.
  • Not enforceable because you are outside of the jurisdiction: California can try to apply its laws to out-of-state actors when there is a California nexus. California's long-arm statute is broad: California courts may be able to exercise jurisdiction on any basis consistent with state/federal constitutions.archive.org iconarchive.today icon
    • See also: Wiki chapter Legal Jurisdiction mentions examples how U.S. authorities enforced laws against non-U.S. persons that never resided in the U.S., never visited and never had any company there.

Compliance options / alternatives

[edit]
  • You should just ignore this and not comply: Legal Compliance
  • Prohibit California residents in TOS (terms of service): Not a solution. It's not legal resistance. It's not legal compliance. It's avoidance. It may be risky. This is a jurisdiction carve-out via licensing / terms of service (TOS) language (sometimes perhaps paired with geoblocking downloads). This isn't implementing what AB 1043 actually describes (age setup prompt plus age-bracket signal to applications). It's easy to implement (text + maybe download geoblocking). It's hard to enforce (mirrors, torrents, third-party redistribution). It may reduce exposure (fewer ties to CA users / fewer "doing business" indicators), but it doesn't guarantee being outside the scope of the law.
  • Should fight this in court: Kicksecure is a small project run by a non-U.S. founder, non-U.S. company and is not well positioned to challenge this U.S. law in court. See also Legal Campaigns.
  • Should do this/that instead: See Personal Liability.

Implementation / technical limitations

[edit]
  • Users can trivially bypass this by lying about their age: This is correct, but the law does not yet mandate it being reasonably difficult to bypass. In the future, laws might require making this reasonably difficult to bypass. Fortunately, the law does not yet mandate ID verification, certified software (Device Attestation such as SafetyNet / Google Play Integrity API), locked bootloaders (restricted boot), administrative ("root") rights refusal, cryptographic secure APIs, etc. This might be part of the War on General Purpose Computing.
  • Implementation is not good enough: Opinionated. A reasonable effort has been made. Four related mailing lists have been contacted, see On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states. Development has been done.

    (b) 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 or any conduct by a developer that receives a signal indicating a user’s age range.

  • You should use the standard API: An age API convention/standard does not exist yet. If one were to exist, it would be considered.

Ecosystem / responsibility allocation

[edit]

Enforcement likelihood / practical risk

[edit]
  • Probably technically illegal but not enforced as long as no adult content is shown to children: Possibly. Risky.
  • Enforcement will take years and it's a bit like being struck by lightning (rare): Might be true, but it is risky.

Legal Campaigns

[edit]

At the time of writing, the author is unaware of any initiatives with the goal of challenging this law in court.

Offer for help by https://x.com/prestonjbyrnearchive.org iconarchive.today icon in this tweet https://x.com/prestonjbyrne/status/2028940016915759579archive.org iconarchive.today icon

Interesting sounding ideas:

I doubt the state of California can actually succeed in applying the law to Debian, Ubuntu and other free, open-source OS's. A few arguments come to mind. Under the Bernstein v. DOJ, source code is protected speech. The attempt at "compelled speech" probably won't pass muster. There is an arguable constitutional right to anonymous speech probably infringed upon by any compusory technical requirement for age disclosure. California lacks the jurisdiction to enforce its state laws against providers outside its borders. Enforcement is impossible. Under the license, any user can legally fork the software to remove the age-verification module. And there is always the commerce clause argument. The rush to comply could be a waiver of all these arguments. ~vincehttps://lists.debian.org/debian-devel/2026/03/msg00029.htmlarchive.org iconarchive.today icon

At the time of writing, no statements by FSF, GNU, FSFE, OSI or EFF existed to the knowledge of the author.

Development

[edit]

Related

[edit]

Lawsuits

[edit]

May be related to app store age verification rather than operating system age signaling:

Resources

[edit]

Design Previous page: Dev/cryptography Index page: Design Next page: Dev/Password Manager

Notification image

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 13 year success story and maybe DONATE!