{{Header}} {{title|title= Age Signaling and Interface Documentation and Design for {{project_name_short}} }} {{#seo: |description=Documentation for operating system age-signaling (age-bracket) interface requirements that may apply in some jurisdictions. Covers background, {{project_name_short}} privacy/fingerprinting impact, user interface (UI) wording/rationale, alternatives, legal considerations, objections, and related resources. }} {{intro| This page documents potential operating-system age-signaling (age-bracket) interface requirements that may apply in some jurisdictions, and what they could mean for {{project_name_short}}. 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}} = Disclaimer = This is not legal advice. As per [[Terms of Service]] wiki chapter, there is [[Terms_of_Service#No_Legal_Advice|No Legal Advice]]. {{quotation |quote=The Services are not for use by anyone under the age of 18. |context=[[Terms of Service]] chapter [[Terms_of_Service#Minimum_Age|Minimum Age]] }} = Introduction = 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 = California: Law passed, effective from January 2027: * https://california.public.law/codes/civil_code,_division_3,_part_4,_title_1.81.9 ** https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB1043 Chicago: Draft (pending, moving) law: * https://leg.colorado.gov/bills/SB26-051 ** https://leg.colorado.gov/bill_files/110990/download New York: Draft (pending, moving) law: * https://www.nysenate.gov/legislation/bills/2025/S8102/amendment/A This is [[unspecific|unspecific to {{project_name_short}}]]. Most Linux distributions and most general purpose operating systems may be affected. {{quotation |quote=App Store and Device-Level Age Verification |context=EFF: [https://www.eff.org/deeplinks/2025/12/year-states-chose-surveillance-over-safety-2025-review The Year States Chose Surveillance Over Safety: 2025 in Review] }} [https://www.linkedin.com/company/mcneeswallacenurick/ law firm] blog post: [https://www.mcneeslaw.com/age-verification-laws-app-developers-compliance/ New laws in some states require app developers to verify users’ ages] Open questions: * {{anchor|show=true|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: * [https://github.com/microsoft/MS-DOS Microsoft is distributing MS-DOS 4.0]: Do they have to stop distributing MS-DOS or comply with this law? This may be applicable to binary builds only, not source code? * [https://www.freedos.org/ FreeDOS] * Transporting a computer into different jurisdictions might invoke different legal requirements. == Discussions == === Development Discussion === * https://github.com/flatpak/xdg-desktop-portal/pull/1922 ==== On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states ==== * [https://lists.debian.org/debian-devel/2026/03/msg00016.html debian-devel] * [https://lists.debian.org/debian-legal/2026/03/msg00000.html debian-legal] * [https://mail-archive.com/search?l=devel@lists.fedoraproject.org&q=subject:%22Fw%5C%3A+On+the+unfortunate+need+for+an+%5C%22age+verification%5C%22+API+for+legal+compliance+reasons+in+some+U.S.+states%22&o=newest&f=1 fedora-devel] ** [https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/thread/MYM452NNXF3ZJ7HPBYT4HDNTKRK2FWBX/ fedora-devel] * [https://www.mail-archive.com/search?l=ubuntu-devel@lists.ubuntu.com&q=subject:%22On+the+unfortunate+need+for+an+%5C%22age+verification%5C%22+API+for+legal+compliance+reasons+in+some+U.S.+states%22&o=newest&f=1 ubuntu-devel] * [https://lists.freedesktop.org/archives/xdg/2026-March/014764.html xdg-devel] === User Discussions === * https://discussion.fedoraproject.org/t/california-age-verification/181968 * https://discussions.unity.com/t/play-age-signals-api-support-is-unity-preparing-for-this/1689525 * https://forum.manjaro.org/t/california-and-colorado-laws-an-os-age-verification/185960 * https://discuss.privacyguides.net/t/age-verification-for-qubes-os-and-whonix-among-other-linux-distributions/35984 == Other Projects == === MidnightBSD === * https://x.com/midnightbsd/status/2027101491211718765 {{quotation |quote=California residents are not authorized to use MidnightBSD for desktop use in the state of California effective January 1, 2027. California law [https://legiscan.com/CA/text/AB1043/id/3269704 CA AB1043] requires a complex age verification system implemented for operating systems with no exceptions for small open source projects. |context=https://github.com/MidnightBSD/src/commit/7d956a27123f2d77a05313826c29a0329a923254 }} * https://github.com/MidnightBSD/src/blob/4e64ffa192dbd651a07a7f8295e682296c4d6c30/COPYRIGHT#L7 * https://x.com/midnightbsd/status/2027820452828139625 * https://x.com/midnightbsd/status/2028195352520626576 ** https://docs.google.com/document/d/1_NKq0bpN1pOrMpHePuilJY7saXqXqhss6LwPTC6nSto/edit?tab=t.0#heading=h.45e7p9clyiqo Blocking California in the terms of service / license might be insufficient, see: [[Age-api#Prohibiting_California_residents_in_the_Terms_of_Service_and_Geo-Blocking|Prohibiting California residents in the Terms of Service and Geo-Blocking]] === Ubuntu === * https://discourse.ubuntu.com/t/ubuntus-response-to-californias-digital-age-assurance-act-ab-1043/77948 ** https://www.phoronix.com/news/Ubuntu-Digital-Age-Assurance = {{project_name_short}} = == Privacy Friendly Choice == * 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 {{project_name_short}} to abstain from recommending privacy friendly defaults. == Fingerprinting Risk == [[About|{{project_name_short}}]] (and {{whonix_wiki |wikipage=About |text=Whonix }}) specific fingerprinting impact. {{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 {{whonix_wiki |wikipage=VM_Fingerprinting |text=VM Fingerprinting }}. * 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: [[Age-api#Prompt_for_Age_instead_of_Age_Bracket|Prompt for Age instead of Age Bracket]] * Under 18 years age use prohibited by ToS: {{quotation |quote=The Services are not for use by anyone under the age of 18. |context={{project_name_short}} [[Terms of Service]] (ToS) chapter [[Terms_of_Service#Minimum_Age|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) {{project_name_short}} 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. * Forum discussion: [https://forums.whonix.org/t/whonix-adding-age-verification/22969 Whonix adding age verification?] == Kicksecure for Qubes == Potential effect on [[Qubes|Kicksecure for Qubes]] and {{whonix_wiki |wikipage=Qubes-Whonix |text=Qubes-Whonix }}. 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 [https://www.qubes-os.org Qubes OS] 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: [https://github.com/QubesOS/qubes-issues/issues/10744 legally mandatory age verification API compliance may be required #10744] Qubes forum discussion: [https://forum.qubes-os.org/t/how-much-do-we-gotta-worry-about-this-linux-age-verification-bs/39788 How much do we gotta worry about this Linux “age verification” BS?] = Interface Design Choice Details = These drafts are competing, alternative or complementing. Undecided. == Parental Controls Design Draft == {{draft}} At the first boot, the user can decide * {{IconSet|h2|A}} Use parental controls: Enable parental controls at first boot. * {{IconSet|h2|B}} parental-controls removal: Use [[Debian_Packages#dummy-dependency|dummy-dependency]] to remove parental-controls. But if using parental controls, * {{IconSet|h1|1}} One-time age configuration: The age can be configured only once. * {{IconSet|h1|2}} Sysmaint required for changes: Further age changes require a sysmaint session. * {{IconSet|h1|3}} Sysmaint password required: A sysmaint password is required. * {{IconSet|h1|4}} Bootloader password required: A bootloader password is required. * {{IconSet|h1|5}} BIOS password recommended: A BIOS password is recommended. 
WARNING for PARENTS!

This system is not certified for use by people below 18 years.
== Interface Design Draft == {{draft}} {{quotation |quote= 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: [https://www.kicksecure.com/wiki/Terms_of_Service#No_Legal_Advice This is not legal advice.] For further information, see [[age-api]]. }} == Mandatory Blocking == Device/account setup must be '''required'''. Bold emphasis added. {{quotation |quote=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 == 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. {{quotation |quote=(i) “User” means a child that is the primary user of the device. }} == Age versus Date of Birth == Bold added. Underline added. {{quotation |quote= 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 == 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. {{quotation |quote= 1798.502. [...] allows an account holder to indicate the birth date''',''' age, '''or''' both, [...] }} == No Default Choice == Why not configure "under 13" or "older than 18" by default? {{quotation |quote= 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 = 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 = == Status / timeline == * 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 == * Not applicable: Unfortunately it is applicable. {{quotation |quote=(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 {{os}}: Possibly. Risky. This is an unresolved legal question. == Jurisdiction / enforceability == * 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 [https://en.wikipedia.org/wiki/FATCA FATCA] 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. ** [https://california.public.law/codes/code_of_civil_procedure_section_410.10 California's long-arm statute is broad: California courts may be able to exercise jurisdiction on any basis consistent with state/federal constitutions.] ** [https://en.wikipedia.org/wiki/Piercing_the_corporate_veil Piercing the corporate veil] ** [https://en.wikipedia.org/wiki/Enforcement_of_foreign_judgments Enforcement of foreign judgments] ** See also: Wiki chapter [[Trust#Legal_Jurisdiction|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. === Non-U.S. Legal Entity === {{IntroLike| This section explains why being outside the U.S. may reduce some risks but may not automatically make AB 1043 irrelevant when users are in California. }} * Not a force field: A non-U.S. legal entity may help in some legal cases, but it is not a force field. It probably does not guarantee protection. * Private plaintiffs may be discouraged: Being incorporated outside the U.S. may reduce risk from private plaintiffs because suing abroad and collecting abroad can be expensive and uncertain, so many private parties may not attempt it; some lawyers may discourage suing foreign entities due to added complexity, higher costs, higher fees, and a greater risk of an uncertain outcome. * State enforcement may still be a concern: Age verification AB 1043 enforcement responsibility may be with the California Attorney General. A state actor may have stronger enforcement incentives and tools, and has far more staff and funding than a private party. * Cross-border legal tools may exist: The state may have tools available such as [https://en.wikipedia.org/wiki/Piercing_the_corporate_veil Piercing the corporate veil]. In some cases, this can be used to try to reach past a company structure to individuals. The state may also use tools such as [https://en.wikipedia.org/wiki/Enforcement_of_foreign_judgments Enforcement of foreign judgments]. In some cases, this can be used to try to have a judgment from one country recognized or enforced in another. * Risk reduction is not non-applicability: Foreign incorporation might provide risk reduction but may not result in full non-applicability. It may reduce the chance or ease of enforcement, but still might not take the project out of scope. * U.S. company status may be unrelated: "But you are not a U.S. company" may miss the point. The law does not have to focus on where a provider is incorporated. The law does not say it applies only to California companies or only to maintainers who are residents of, or visiting, California. The key scenario it describes is users in California. * Focus may still be on people in California: California legislature writes laws to regulate people in California, for example users located in California. ** No need to mention California companies explicitly: The law does not have to say "applicable to California operating system provider companies / maintainers resident or visiting California" to still affect providers outside California if it is written around California users. ** No need to mention extraterritoriality explicitly: The law does not have to say "extraterritoriality" for it to be argued to apply when there is a California connection, such as users in California. ** No need to say worldwide explicitly: The law does not have to say "applicable world wide" for it to still be argued that out-of-state or out-of-country providers are covered when California users are involved. * Summary: A non-U.S. legal entity may make some lawsuits harder or less attractive, but it probably does not, by itself, prevent AB 1043 from being relevant if California users are involved. === Jurisdiction Applicability and Enforcement Comparison Table === {{IntroLike| These tables are written from the perspective of a non-U.S. provider. }} Step one: Can California obtain a judgment? Step two: If the defendant has no reachable assets or presence in the U.S., can California enforce that judgment abroad? ==== Applicability Risk ==== {{IntroLike| In this table, the column "Fact for this project?" uses Yes / No to mean true or false for this specific project (not good or bad). The column "Good sign for "not applicable"?" indicates whether the fact is a good sign for arguing the law does not apply. }} {| class="wikitable" |+ Facts that may matter for whether AB 1043 applies |- ! Fact someone points to ! Fact for this project? ! Good sign for "not applicable"? ! Why this may matter (plain language) |- ! Provider is a non-U.S. legal entity | {{Yes}} | {{No}} | Being incorporated outside the U.S. may reduce some practical risks, but it might not make AB 1043 irrelevant if users in California can still obtain and use the software; if the provider were a U.S. entity, overall exposure might be higher. |- ! The operating system provider is not a U.S. person, is not a U.S. resident, and never resides in or visits the U.S. | {{Yes}} | {{No}} | No personal U.S. ties may lower some practical risks, but it might not settle applicability if the law is written around users in California; if the provider did reside in, visit, or otherwise have strong U.S. ties, enforcement risk might increase. |- ! A user may be in the state of California (resident or visitor) | {{Yes}} | {{No}} | This is often the most intuitive "hook": rules like this may be written around users who are physically in the state, even if the provider is elsewhere; that means the provider may still be in scope when California users are involved. |} ==== Enforcement Risk ==== {{IntroLike| In this table, the column "Fact for this project?" uses Yes / No to mean true or false for this specific project (not good or bad). The column "Good sign for lower enforcement risk?" indicates whether the fact may make enforcement or collection harder in practice. }} {| class="wikitable" |+ Facts that may affect practical enforcement / collection risk (even if AB 1043 may apply) |- ! Fact someone points to ! Fact for this project? ! Good sign for lower enforcement risk? ! Why this may matter (plain language) |- ! Provider is a non-U.S. legal entity | {{Yes}} | {{Yes}} | Enforcing across borders may be more complex and expensive than a local case, which may reduce some practical risks; if the provider were U.S. based, enforcement might be simpler. |- ! The operating system provider is not a U.S. person, is not a U.S. resident, and never resides in or visits the U.S. | {{Yes}} | {{Yes}} | Avoiding U.S. residence and travel may reduce some personal exposure scenarios tied to physical presence; if the provider did travel to or reside in the U.S., practical risk might increase. |- ! A user is in the state of California (resident or visitor) | {{Yes}} | {{No}} | California users may increase the chance of complaints, attention, or a perceived California connection; reducing California usage might reduce this risk, but it may be difficult to guarantee in real-world distribution. |} == Compliance options / alternatives == * You should just ignore this and not comply: [[Trust#Legal_Compliance|Legal Compliance]] * Should do this/that instead: See [[Limitations_on_Free_Speech_on_Website_and_Chat#Personal_Liability|Personal Liability]]. * Should fight this in court: {{project_name_short}} 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 [[Age-api#Legal_Campaigns|Legal Campaigns]]. === Prohibiting California residents in the Terms of Service and Geo-Blocking === {{anchor|Prohibiting California residents in the Terms of Service}} {{IntroLike| This section explains, in plain language, why a "no California users" Terms of Service clause may reduce risk in some cases, but might not guarantee that the project is fully outside California law or enforcement attention. }} * Not a full solution: Prohibiting California residents in the TOS is probably avoidance, not legal resistance or legal compliance. ** Probably cannot contract out of public law: A TOS clause may be able to govern a user relationship, but it probably cannot remove statutory obligations if the project is otherwise considered in scope. ** May create a false sense of safety: The text may look decisive, but it probably does not prove that California residents are actually excluded in practice. * A jurisdiction carve-out: This approach probably relies on licensing / terms of service language, sometimes paired with geoblocking downloads. ** Scope probably depends on facts, not labels: A jurisdiction disclaimer may be only one factor. Actual distribution, availability, outreach, and contacts may still matter. ** Other ties may still exist: Hosting, fundraising, support channels, contributors, or other operational connections may create California related contacts even if the TOS says "no California users". * Does not implement compliance with law AB 1043: It does not provide what AB 1043 describes (an age setup prompt plus an age-bracket signal to applications). ** Substantive requirements may remain unmet: If the obligation is to provide specific functionality, a TOS prohibition probably does not provide the required functionality. * Easy to implement: It is probably mostly text changes, maybe with optional download geoblocking. ** TOS acceptance is not guaranteed: Many users may never affirmatively accept the TOS from the viewpoint of the state, especially when software is downloaded from mirrors, package repositories, torrents, or third party redistribution. ** Downstream redistribution may bypass your terms: Forks, repackagers, and unofficial images may remove, modify, or fail to present the TOS while still distributing the software to California users. ** Geo-blocking, Kicksecure, Whonix specific: It probably cannot be implemented without disabling the project's [https://www.kicksecure.com/?#explain-onionwebsite .onion domain]. ** Geo-blocking is hard to enforce: Enforcement may be weak due to mirrors, torrents, and third-party redistribution. ** Geo-blocking is bypassable: Even when implemented, users may be able to bypass it using VPNs, proxies, Tor exits, remote machines, or alternative download sources. * May create debate and distraction risk: In forums, issue trackers, etc. others might claim that a specific person is in California and therefore "not allowed to use" the project, and demand bans. This might happen with or without evidence, for example pointing to a personal website where someone states they are in California, and it could encourage arguments, harassment, or a witch-hunt dynamic. * May reduce exposure: It may reduce ties to California users and may reduce "doing business" indicators. ** Reduction is not elimination: Reduced exposure may help, but it might not remove all plausible California connections or all possible covered user scenarios. * Existing users: Blocking California may not resolve prompting existing users for compliance. https://discussion.fedoraproject.org/t/california-age-verification/181968/92 * No guarantee of being out of scope: Even if exposure is reduced, it might not guarantee being outside the scope of the law. ** One California user may reintroduce risk: If even a small number of California residents still obtain and use the software, the project may still face complaints, inquiries, or enforcement attention. ** Evidence may accumulate unintentionally: Bug reports, support requests, community posts, donations, or other interactions may create a record of California use despite the TOS clause. * Conclusion: A TOS / Geo-Blocking based California prohibition may lower risk in some scenarios, but it might not reliably prevent California use or contacts, and therefore may not be a dependable way to fully avoid legal exposure by itself. == Implementation / technical limitations == * Easy to bypass: Users can trivially bypass an age prompt by entering a false age. * Currently may be sufficient: This may still be "good enough" for now because the law does not yet require the age prompt to be reasonably difficult to bypass. * Future rules might be stricter: In the future, laws might require making this reasonably difficult to bypass, which could pressure projects into using stricter measures that may be harder on users. * Stricter measures '''not''' currently mandated: Fortunately, the law does not yet mandate measures such as the following (which may increase control over the user's device or reduce user freedom): ** ID verification: Requiring proof of identity (for example, uploading or scanning identity documents). ** Certified software: Requiring a specific "approved" software environment rather than allowing user modified systems. ** Device attestation: [[Miscellaneous_Threats_to_User_Freedom#Device_Attestation_such_as_SafetyNet|Device Attestation such as SafetyNet / Google Play Integrity API]] which can make a device prove it is unmodified or "trusted" before an app will run. ** Locked bootloaders: [[Miscellaneous_Threats_to_User_Freedom#restricted_boot|restricted boot]] which can prevent installing alternative operating systems or custom system images. ** Root refusal: [[Miscellaneous_Threats_to_User_Freedom#Administrative_Rights|administrative ("root") rights refusal]] where apps refuse to run if the user has full administrative control over their own device. ** Cryptographic secure APIs: Tamper resistant (sometimes hardware backed) checks intended to make bypassing more difficult. ** Other similar mechanisms: Additional technical controls with similar effects, etc. ** Broader concern: This trend might be part of the [[Miscellaneous_Threats_to_User_Freedom#War_on_General_Purpose_Computing|War on General Purpose Computing]], where general purpose devices are increasingly restricted through technical controls, policy requirements and user freedom being lost. * Implementation is not good enough: Opinionated. A reasonable effort has been made. Four related mailing lists have been contacted, see [[Age-api#On_the_unfortunate_need_for_an_"age_verification"_API_for_legal_compliance_reasons_in_some_U.S._states|On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states]]. [[Age-api#Development|Development]] has been done. {{quotation |quote=(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 == * The base distribution (Debian) needs to implement this, not derivatives such as {{project_name_short}}: It is correct that Debian may also need to implement this. However, {{project_name_short}} has no influence on that. The topic has been raised at the Debian mailing list [https://lists.debian.org/debian-devel/2026/03/msg00016.html debian-devel: On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states]. * Other distributions potential reactions: Might react in various ways: ** not noticing; ** wait and see; ** not taking it seriously; ** waiting to get fined or sued; ** TOS (terms of service) prohibiting California residents ** implementation of age declaration or age verification == Enforcement likelihood / practical risk == * 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. No applicable empirical basis for that analogy has been found yet by the author. = Legal Campaigns = 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/prestonjbyrne in this tweet https://x.com/prestonjbyrne/status/2028940016915759579 Interesting sounding ideas: {{quotation |quote=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. ~vince |context=https://lists.debian.org/debian-devel/2026/03/msg00029.html }} At the time of writing, no statements by FSF, GNU, FSFE, OSI or EFF existed to the knowledge of the author. = Future = Potentially. == New York State Senate Bill S8102A == Might apply to device manufacturers only? Does not seem so. Underline added. {{quotation |quote=6. "COVERED MANUFACTURER" SHALL MEAN A MANUFACTURER OF AN INTERNET-EN- ABLED DEVICE, AN OPERATING SYSTEM PROVIDER, OR AN APPLICATION STORE. |context=The New York State Senate: [https://www.nysenate.gov/legislation/bills/2025/S8102/amendment/A Senate Bill S8102A] ([https://web.archive.org/web/20260305182153/https://www.nysenate.gov/legislation/bills/2025/S8102/amendment/A archived]) }} Bold added. Underline added. {{quotation |quote=To require devices to conduct '''commercially reasonable age assurance''' for users under the age of 18 at the point of device activation, unlocking the ability to enforce all other digital privacy and safety laws for underage users |context=The New York State Senate: [https://www.nysenate.gov/legislation/bills/2025/S8102/amendment/A Senate Bill S8102A] }} Bill PDF * live: https://legislation.nysenate.gov/pdf/bills/2025/s8102a * archived: https://web.archive.org/web/20260305091554/https://legislation.nysenate.gov/pdf/bills/2025/s8102a Law status at the time of writing: "Introduced" - that is as per quote of above website. It has not "Passed Assembly", not "Passed Senate". It is not in effect yet. In laymen terms, one could say "it's planned / a draft". {{anchor|show=true|referral to other article by draft amendment}} Bold added. Underline added. {{quotation |quote=1. "Age assurance" shall mean any method to reasonably determine the age category of a user, using methods that reasonably prevent against circumvention. Such method may include a method that meets the requirements of article forty-five of this chapter, '''or''' may be a method that is identified pursuant to new regulations promulgated by the attorney general consistent with section fifteen hundred forty-five of this article |context=https://web.archive.org/web/20260305091554/https://legislation.nysenate.gov/pdf/bills/2025/s8102a }} Section fifteen hundred forty-five might refer to [https://www.nysenate.gov/legislation/laws/GBS/1501 The Laws of New York Consolidated Laws of New York CHAPTER 20 General Business ARTICLE 45 Safe For Kids Act, SECTION 1501]. {{quotation |quote=(a) the covered operator has used commercially reasonable and technically feasible methods to determine that the covered user is not a covered minor; or (b) the covered operator has obtained verifiable parental consent to provide an addictive feed to a covered minor. }} {{quotation |quote=2. (a) The attorney general shall promulgate regulations identifying commercially reasonable and technically feasible methods for covered operators to determine if a covered user is a covered minor required pursuant to subdivision one of this section, and any exceptions thereto. }} {{quotation |quote=(c) Such regulations shall also identify the appropriate levels of accuracy that would be commercially reasonable and technically feasible for covered operators to achieve in determining whether a covered user is a covered minor. Such regulations shall set forth multiple commercially reasonable and technically feasible methods for a covered operator to determine if a covered user is a covered minor, including at least one method that either does not rely solely on government issued identification or that allows a covered user to maintain anonymity as to the covered operator of the addictive social media platform. }} {{quotation |quote=5. Information collected for the purpose of obtaining such verifiable parental consent shall not be used for any purpose other than obtaining verifiable parental consent and shall be deleted immediately after an attempt to obtain verifiable parental consent, except where necessary for compliance with any applicable provisions of New York state or federal law or regulation. }} {{quotation |quote=2. (a) The attorney general shall promulgate regulations identifying commercially reasonable and technically feasible methods for covered operators to determine if a covered user is a covered minor required pursuant to subdivision one of this section, and any exceptions thereto. }} {{quotation |quote=consider the size, financial resources, and technical capabilities of the addictive social media platform }} It's talking about "social media platform". Why might this apply? See [[Age-api#referral_to_other_article_by_draft_amendment|referral to other article by draft amendment]]. ag.ny.gov: [https://ag.ny.gov/resources/individuals/consumer-issues/technology/protecting-children-online Protecting Children Online, Notice of Proposed Rulemaking] {{quotation |quote=(h) Age Assurance Method. The term Age Assurance Method means any type of age estimation, age inference, or age verification. |context=ag.ny.gov: [https://ag.ny.gov/sites/default/files/regulatory-documents/safe-for-kids-act-nprm.pdf Stop Addictive Feeds Exploitation, (SAFE) for Kids Act, Office of the New York State Attorney General Letitia James, Economic Justice Division, Notice of Proposed Rulemaking] }} {{quotation |quote=8. Age Assurance Method The proposed rule defines “age assurance method” as any type of age estimation, age inference, or age verification. “Age assurance” is typically used as an umbrella term for various types of methods that can support a conclusion regarding an individual’s age or age status, often for the purpose of making an age-related eligibility decision. For purposes of compliance with the proposed rule, OAG has identified three categories of age assurance that are considered age assurance methods, each of which contains one or more methods that can meet the accuracy minimum if effectively implemented and executed. The OAG seeks comments on the proposed definition of age assurance method }} {{quotation |quote=Under the proposed rule, self-declaration is not an age assurance method. However, self-declaration as a minor qualifies a covered user as a covered minor for purposes of compliance with section 700.4. }} {{quotation |quote=An age assurance method would be required for all covered users who do not selfdeclare as minors. By proposing to define age assurance method through categories of methods rather than specific methods, OAG would allow covered operators to determine the method or methods that are best suited to the online platform and users. It also would allow operators to remain flexible in choosing methods as age assurance methods and technology continue to evolve. The accuracy minimum and requirements of section 700.4 ensure that the methods operators ultimately choose are effective. }} == Potential Future California Age Verification Law Changes == {{quotation |quote=OFFICE OF THE GOVERNOR [...] Streaming services and video game developers contend that this bill's framework, while well-suited to traditional software applications, does not fit their respective products. Many of these companies have existing age verification systems in place, addressing complexities such as multi-user accounts shared by a family and user profiles utilized across multiple devices. As this bill does not take effect until January 1, 2027, I urge the Legislature to enact legislation in 2026 to address these particular concerns. [...] |context=gov.ca.gov: [https://www.gov.ca.gov/wp-content/uploads/2025/10/AB-1043-Signing-Message.pdf AB 1043 signing message] }} = Potential Arguments = == commercially reasonable age assurance ==
commercially reasonable age assurance
It may be commercially unreasonable to implement anything ID-based due to a combination of our goals (which would be fundamentally incompatible with Kicksecure, Whonix) and thus damage the economic viability of the company and its resources, potentially leading to bankruptcy. Forbidding use by anyone under the age of 18 and providing an "age locking" mechanism may be the most that is commercially reasonable for a smaller business. Judging from forum discussions and Reddit discussions, the overwhelming majority of people commented very negatively regarding age verification API implementation. Many have threatened to switch to another Linux distribution should their current Linux distribution implement such a feature. = Development = * https://github.com/Kicksecure/age-api * [[Dev/todo#Age_API|development TODO task: Age API]] = Related = == Lawsuits == May be related to app store age verification rather than operating system age signaling: * https://ccianet.org/library/ccia-v-paxton-wd-tex-sb2420-complaint/ * https://www.texaspolicyresearch.com/texas-app-store-law-faces-first-amendment-lawsuit/ == Related Court Rulings == * https://cbsaustin.com/resources/pdf/70c794d9-f8d7-489d-b4d0-9409fd2d36fb-189114911210.pdf ** https://www.reuters.com/legal/government/judge-blocks-virginia-law-restricting-social-media-children-2026-02-27/ == Resources == * https://actonline.org/2025/01/14/the-abcs-of-age-verification-in-the-united-states/ * https://www.eff.org/pages/does-tech-even-work * https://news.bloomberglaw.com/legal-exchange-insights-and-commentary/states-use-app-store-controls-to-keep-online-content-from-minors * https://compliancehub.wiki/californias-tech-surveillance-laws-what-compliance-teams-need-to-know-about-ab-56-sb-243-and-ab-1043/ * https://developer.apple.com/documentation/declaredagerange/ = Footnotes = {{Footer}} [[Category:Documentation]]