Want to help us grow?

Age Signaling Legal and Interface Considerations for Kicksecure and Whonix

From Kicksecure

Jump to navigation
Jump to search

Kicksecure

™

Download

On Computer
USB Installation
Intel / AMD64
ARM64
Raspberry Pi
PPC64
Windows (VM)
Mac
Linux (VM)
VirtualBox (VM)
Qubes (VM)
KVM (VM)
Debian morph to Kicksecure
More options
Source Code

About

Overview
Features
Why Open Source?
Project Activities
Contributors
Mission & Vision

Docs

Documentation
FAQ
Troubleshooting

Community

Forums
Forum Best Practices
Contribute

Support

Self Support First Policy
Search Engines, Docs and AI
Support (Limited)

Reporting Bugs
Contact (Restricted)

Tools
Upload file
Special pages
Recent changes
Print Version

Page meta
What links here
Related changes
Page information

Page
Read
Edit
History
Move
Protection
Unwatch
Watch
Delete
Purge

User
Preferences
Watchlist
Contributions
Logout
Create account
Login

Donate

Dev/cryptography

Design

Dev/Password Manager

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

Age Signaling Legal and Interface Considerations for Kicksecure and Whonix

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 (and Whonix).

It summarizes background, status, privacy, fingerprinting impact, legal considerations, objections, and links to related upstream discussions.

Status: For up-to-date plans by Kicksecure (and Whonix), see #status.

Forum discussion: Whonix adding age verification? (moderation comment)

DRAFT!

Contents

1 Disclaimer

2 Introduction

3 Background

3.1 Age API Laws Overview

3.2 Open Questions

3.3 Security Impact

3.4 Economic, Education and Social Impact

3.5 Absurdities

3.6 Discussions

3.6.1 Development Discussion

3.6.2 User Discussions

3.7 News

3.8 Organisation Commentary

3.8.1 EFF

3.8.2 mcneeslaw

3.9 Other Projects

3.9.1 freedesktop

3.9.2 systemd

3.9.3 MidnightBSD

3.9.4 Devuan

3.9.5 Ubuntu

3.9.6 system76

3.9.7 Arch Linux

3.9.8 FreeDOS

3.9.9 Tails OS

3.9.10 nixOS

3.9.11 elementary os

3.9.12 CachyOS

3.9.13 secureblue

4 Kicksecure

4.1 Status of Kicksecure and Whonix

4.1.1 Kicksecure for Qubes

4.2 Contingency Plan

4.2.1 Privacy Friendly Choice

4.2.2 Fingerprinting Risk

4.2.3 Security Impact

5 Interface Design Choice Details

5.1 Terms of Service Check

5.2 Age Setup Decision

5.3 Age Signaling Prompt

5.4 User Interface Design Rationale

5.4.1 Mandatory Blocking

5.4.2 Age of the Primary User Wording

5.4.3 Age versus Date of Birth

5.4.4 Prompt for Age instead of Age Bracket

5.4.5 No Default Choice

6 Alternatives

7 Objections

7.1 Status / timeline

7.2 Applicability / scope

7.3 Jurisdiction / enforceability

7.3.1 Non-U.S. Legal Entity

7.3.2 Jurisdiction Applicability and Enforcement Comparison Table

7.3.2.1 Applicability Risk

7.3.2.2 Enforcement Risk

7.4 Compliance options / alternatives

7.4.1 Prohibiting California residents in the Terms of Service and Geo-Blocking

7.5 Implementation / technical limitations

7.6 Ecosystem / responsibility allocation

7.7 Enforcement likelihood / practical risk

7.8 Legal impact in case malware is tampering with the age API

8 Activism / Campaigns / Outreach

8.1 Contribute by Taking on Legal Responsibility

8.2 Outreach

8.3 Legal Campaigns

9 Future

9.1 New York State Senate Bill S8102A

9.2 Potential Future California Age Verification Law Changes

10 Potential Arguments

10.1 commercially reasonable age assurance

10.2 more

11 Development

12 Related

12.1 Lawsuits

12.2 Related Court Rulings

12.3 Resources

12.4 Similar

13 Footnotes

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]

Age API Laws Overview
[edit]

Non-exhaustive list.

DRAFT!

Review required!

Overview of selected age verification laws

Jurisdiction

Status

Timeline

Sources

Notes

California

Passed

Effective January 1, 2026; operative January 1, 2027

Civil Code text, Bill text

operating system provider

Colorado

Draft

Passed Senate March 3, 2026; would take effect January 1, 2028 if enacted

Bill page, Bill text (PDF), Fiscal note (PDF)

operating system provider

New York

Draft

Senate amended and recommitted February 25, 2026; Assembly pending

Senate Bill S8102A, Assembly Bill A8893

Internet-enabled device manufacturer age assurance and real-time API digital signal.

Illinois

Draft

Introduced February 6, 2026; to Senate AI and Social Media February 25, 2026; operating-system provisions would apply by January 1, 2028 if enacted

Bill status (SB 3977), Bill text (SB 3977)

operating system provider

Michigan

Draft

Introduced May 6, 2025; referred to committee

Senate Bill 0284 bill page, Senate Bill 0284 bill text (PDF), House Bill 4429 bill page

Device-based "digital age signal" concept; age signal provided via an API.

Illinois (Digital Age Assurance Act)

Draft

Referred to House Rules Committee October 15, 2025; would take effect January 1, 2027 if enacted

Bill status (HB 4140), Bill text (HB 4140)

operating system provider

Utah

Passed

Signed March 26, 2025; general effective date May 7, 2025; main app-store provisions effective May 6, 2026

Enrolled bill (SB 142)

mobile operating system (OS)

Louisiana

Passed

Effective July 1, 2026

HOUSE BILL NO. 570 Bill history (HB 570), Act text (PDF)

mobile operating system (OS)

Alabama

Passed

Effective January 1, 2027

Enrolled act text (HB 161) (PDF)

mobile operating system (OS)

Texas

Passed (enjoined)

Effective January 1, 2026; preliminarily enjoined December 23, 2025

Enrolled bill text (PDF), Apple developer update, Google Play developer notice

mobile operating system (OS)

Kansas

Draft

Passed Senate February 18, 2026; House committee reported as amended March 18, 2026

Bill page Bill text - As Amended by House Committee

mobile operating system (OS)

Maryland

Draft

Introduced February 11, 2026; House hearing March 10, 2026; would take effect October 1, 2026 if enacted

Application Store Accountability Act Bill page, Fiscal and policy note (PDF) Maryland HB1179 - bill text

mobile device

Virginia

Draft (continued)

Continued to 2027 in Senate committee on February 4, 2026; bill would take effect July 1, 2027 if enacted

App Store Accountability Act Bill page and summary, Bill text

mobile operating system (OS)

Most Linux distributions and most general purpose operating systems may be affected. (This is unspecific to Kicksecure.)

Open Questions
[edit]

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.

Security Impact
[edit]

Possible unintended harm: Age declaration laws might actually cause more harm than benefit for some children.

Broad age signal requests: A website could ask for an age signal under some pretense.

Forum example: A forum might have a general area and an 18+ area.

Justification risk: That could be used as a reason to request an age signal from all users, not only from users who want to enter the 18+ area.

User profiling risk: Administrators could then single out the age bracket of each user.

Project specific impact assessment: This would be a general issue and unspecific to Kicksecure.

Two possible setups: There may be two main ways age verification might be implemented.

Date of birth based setup: The operating system knows the user's date of birth (DOB).

Automatic updates: This means it can automatically move the user into the next age bracket when their birthday arrives.

Likely common approach: This is likely what most operating systems would do.

Age based setup: The operating system knows only the user's age, or only the resulting age bracket.

Manual updates: In that case, the bracket usually does not update automatically and may need to be changed manually.

Privacy benefit: This may be more privacy friendly.

Additional privacy risk: A date of birth based setup may create an extra privacy risk.

Daily requests risk: If a website asks for the user's age bracket every day, it could notice the exact day when the bracket changes to the next one.

Approximate DOB exposure: That could reveal the user's approximate date of birth.

Economic, Education and Social Impact
[edit]

As system76 pointed out.

Most System76 employees installed operating systems and created accounts on their computer when they were under 18. They did this out of curiosity. Many started writing software. Some were already writing operating systems. I’m sure the story is similar at most tech companies. Limiting a child’s ability to explore what they can do with a computer limits their future. Removing user limitations to the computer (proprietary software, locked-down platforms like Android and iOS) is why System76 exists.System76 on Age Verification Laws

Absurdities
[edit]

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?

FreeDOS

Transporting a computer into different jurisdictions might invoke different legal requirements.

end-users may be considered device manufacturer responsible for age API compliance
Theoretically, it might be the case that end-users may be considered device manufacturer responsible for age API compliance.

As system76 pointed out.

In a bizarre twist, under its current wording, a Linux distribution downloaded from the internet could technically make the downloader the “device manufacturer”. They are the entity responsible for providing a freely distributed operating system to the device. In practice, this type of language is rarely enforced.System76 on Age Verification Laws

Discussions
[edit]

Development Discussion
[edit]

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

debian-devel

debian-legal

fedora-devel

fedora-devel

ubuntu-devel

xdg-devel

User Discussions
[edit]

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

https://discourse.vanlug.ca/t/age-verification-for-qubes-os-and-whonix-among-other-linux-distributions/148

https://www.reddit.com/r/privacy/comments/1rhd48i/how_exactly_is_linux_going_to_get_age_verified/

https://www.reddit.com/r/linux/comments/1rpo7je/age_verification_is_coming_to_the_linux_desktop/

https://forum.level1techs.com/t/system76-responds-to-laws-requiring-age-verification-at-the-os-level/246809

https://www.reddit.com/r/privacy/comments/1rok2wi/ageless_linux_now_tracking_multiple_state_laws/

News
[edit]

https://itsfoss.com/news/distros-response-age-verification-laws/

Organisation Commentary
[edit]

EFF
[edit]

App Store and Device-Level Age VerificationEFF: The Year States Chose Surveillance Over Safety: 2025 in Review

mcneeslaw
[edit]

law firm blog post: New laws in some states require app developers to verify users’ ages

Other Projects
[edit]

Compilation of some major statements and/or (proposed) source code changes by some other operating systems / Linux / BSD distributions.

freedesktop
[edit]

https://www.freedesktop.org/

https://en.wikipedia.org/wiki/Freedesktop.org

xdg-devel

https://gitlab.freedesktop.org/accountsservice/accountsservice/-/merge_requests/176

https://github.com/flatpak/xdg-desktop-portal/pull/1922

systemd
[edit]

https://github.com/systemd/systemd/issues/40974

https://github.com/systemd/systemd/pull/40954

MidnightBSD
[edit]

https://x.com/midnightbsd/status/2027101491211718765

California residents are not authorized to use MidnightBSD for desktop use in the state of California effective January 1, 2027. California law CA AB1043 requires a complex age verification system implemented for operating systems with no exceptions for small open source projects.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

might not be drafted by a lawyer

new plan:

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: Prohibiting California residents in the Terms of Service and Geo-Blocking

Update:

https://www.phoronix.com/news/MidnightBSD-4.0.4

https://github.com/MidnightBSD/src/commit/02764656fa21e788d8a53fd5ebac4747fc1a244d

Devuan
[edit]

https://x.com/jaromil/status/2034694340249821329

Ubuntu
[edit]

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

https://github.com/canonical/ubuntu-desktop-provision/pull/1338

https://github.com/canonical/ubuntu-desktop-provision/pull/1339

system76
[edit]

In a bizarre twist, under its current wording, a Linux distribution downloaded from the internet could technically make the downloader the “device manufacturer”. They are the entity responsible for providing a freely distributed operating system to the device. In practice, this type of language is rarely enforced. Nonetheless, it highlights how laws written for centralized platforms like iOS and Android struggle to define who is responsible in open computing ecosystems where anyone can install or distribute the operating system.System76 on Age Verification Laws

Some of these laws impose requirements on System76 and Linux distributions in general.

We are accustomed to adding operating system features to comply with laws. Accessibility features for ADA, and power efficiency settings for Energy Star regulations are two examples. We are a part of this world and we believe in the rule of law. We still hope these laws will be recognized for the folly they are and removed from the books or found unconstitutional.

Should these laws stand, I'd hope to only do the bare minimum required to comply with the spirit of the law.https://lists.freedesktop.org/archives/xdg/2026-March/014801.html

https://lists.debian.org/debian-devel/2026/03/msg00178.html

Arch Linux
[edit]

https://www.reddit.com/r/archlinux/comments/1rk3qdb/any_response_from_the_arch_devs_about_california/

https://github.com/archlinux/archinstall/pull/4290

https://lists.archlinux.org/archives/list/[email-masked]/thread/UCOAUXM5PPRIUOC3CXV74EBIMKRQO6IH/

FreeDOS
[edit]

https://sourceforge.net/p/freedos/mailman/freedos-devel/thread/trinity-ea582184-aa57-47fe-a9ca-1eaf3c3e7066-1772568482107%40trinity-msg-rest-gmx-mailcom-live-66f5884f57-86bbb/

Tails OS
[edit]

https://gitlab.tails.boum.org/tails/tails/-/work_items/21457

nixOS
[edit]

https://discourse.nixos.org/t/compliance-with-u-s-age-verification-laws/75791

elementary os
[edit]

https://mastodon.online/@danirabbit/116250765623660340

https://www.reddit.com/r/linux/comments/1rybg4z/statements_from_elementary_os_ceo_on_californias/

CachyOS
[edit]

https://discuss.cachyos.org/t/age-verification-systemd/26316

secureblue
[edit]

https://discussion.fedoraproject.org/t/california-age-verification/181968/167

https://github.com/secureblue/secureblue/issues/2008

https://bsky.app/profile/secureblue.dev/post/3mgddiwxxas2y

Kicksecure
[edit]

Status of Kicksecure and Whonix
[edit]

At the moment, Kicksecure and Whonix do not expect to add an age API. This assessment may become more definite later. If future releases or upgrades require changes in this area, those changes would be announced in advance.

Current assessment: Unlikely: Kicksecure and Whonix are currently unlikely to implement an age API.

Possible revised assessment: This may later be updated to "highly unlikely" or "no changes planned".

Expected timeline: A more certain statement may be available at the end of May 2026.

If plans change: If future releases or upgrades require changes in this area, those changes would be announced in advance. Stay Tuned.

Contingency plan: An Contingency Plan had been drafted prior to this status update.

Long-term future: This is speculative. At the moment, users show overwhelming opposition to age verification APIs built into operating systems.

Possible first step: Current operating system age verification laws may be only the first step.

Possible future laws: Future laws might require applications such as web browsers to actually use the operating system's age API. Otherwise, there would be little point in the operating system providing such an API if browsers do not use it and pass the result on to websites that request it.

Possible browser reaction: If the law were to require this, browsers might refuse to operate on operating systems that do not provide the required age API.

Other possible browser reaction: Browsers might instead fall back to the lowest age group, or perform their own age verification.

Possible privacy impact: That could be less secure or worse for privacy.

Possible user response: In that situation, users might start requesting that the operating system at least implement a stub API.

What a stub API means: This would be a minimal API that always reports the same age bracket, such as always signaling the lowest age bracket for family-friendly operating systems, or always signaling the highest age bracket for adult operating systems.

Kicksecure for Qubes
[edit]

Potential effect on Kicksecure for Qubes and 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 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: legally mandatory age verification API compliance may be required #10744

Qubes forum discussion: How much do we gotta worry about this Linux “age verification” BS?

Older statement by Marek on a different topic: European Union And OS level Backdoors (2020)

Contingency Plan
[edit]

DRAFT!

The following is a contingency plan only. It is not a specific implementation plan. It is a thought experiment about the following question: if Kicksecure, Whonix or any other project ever needed such a feature, what might a compliant implementation look like, what would the fingerprinting impact be, and what would be the most secure and privacy-preserving way to implement it? It also includes a graphical user interface (GUI) design draft.

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]

Status: Contingency Plan only. Not planned for implementation at the time of writing. For up-to-date plans by Kicksecure (and Whonix), see #status.

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 Fingerprinting.

Why the risk is likely low to very low: Most installations will likely end up with the same age-bracket value, which reduces uniqueness.

No ID verification required by law: The California law may not mandate ID verification yet.

Age only: The user is only asked to enter their age. Related: Prompt for Age instead of Age Bracket

Use by anyone under 18 is 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)

What happens if a user enters an age under 18: If a user enters an age under 18, the setup program setup-wizard-dist will prohibit use per ToS.

Expected value stored on disk: 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.

Forum discussion: Whonix adding age verification?

Security Impact
[edit]

What if malware tampers with local the age-api by malicious editing any age-api related data storage files?

If malware can write the age-api storage file, it usually means the attacker already has local code execution and enough privileges to modify user files (or worse). In many threat models, that is already "game over", so the marginal risk from "malware can flip the age bracket" is small.

This does not increase system compromise; it only changes the reported bracket. Tampering can change how apps behave, but does not grant new system privileges.

Related: Legal impact in case malware is tampering with the age API

Interface Design Choice Details
[edit]

This section contains multiple design components with different goals. Some are alternatives, some are complementary. The project has not yet decided which combination will be used or if any will be used at all.

Contingency Plan only. Not planned for implementation at the time of writing. For up-to-date plans by Kicksecure (and Whonix), see #status.

Terms of Service check: Policy / eligibility checks. This might be insufficient for AB 1043 compliance by itself.

Age setup decision: Decide whether age signaling should be enabled now (required in some jurisdictions), skipped (if not required), or removed.

Age signaling prompt: The AB 1043 related age prompt and local age-bracket storage / signaling mechanism.

User interface design rationale: Why the wording, why no defaults, why blocking might be required, etc.

Terms of Service Check
[edit]

DRAFT!

Policy / eligibility.

Prompt.

Can you confirm that none of the restrictions below apply to you?

Age requirement

You are at least 18 years old.

Not offered in certain U.S. states

You are not currently located in, do not ordinarily live in, and are not acting on behalf of someone located in California or any other jurisdiction that has age declaration laws.

[ Yes, I confirm none of the restrictions apply ]

[ No, one or more restrictions apply ]

If No → prohibited.

Because you selected that one or more restrictions apply, you are prohibited from using this software.

Age Setup Decision
[edit]

DRAFT!

This prompt appears at first boot.

It is blocking: the user must make a choice to continue.

There may be legal requirements in some jurisdictions to provide age-group signaling for application compliance. In other jurisdictions it might not be required. The privacy and data protection impact (including any EU GDPR considerations) is currently unclear and may depend on jurisdiction and implementation details.

Age setup decision

This system is intended for adults (18+). This system is not officially approved for use by minors.

Some jurisdictions may require age-group signaling so applications can comply with local regulations.

Do you want to enable age-group signaling now?

[ Yes, set up age-group signaling now ]

[ No, I am not in an affected jurisdiction and I want to skip this for now ]

[ Uninstall age-api (remove age prompts and API) ]

Notes:

Choosing "skip for now" is intended only for users who concluded they are not in a jurisdiction where age-group signaling is required.

If the user chooses "skip for now", the age-group signaling can be configured later if needed.

"Uninstall age-api" uses dummy-dependency to remove age declaration prompts and API. It can be re-installed later if needed. This might be unlikely to affect most things right now, but it may limit access to some applications in the future that request age bracket information.

For further information, see age-api.

If the user chooses to enable age-group signaling, enforce stronger change control:

1 One-time configuration: The age group can be set only once.

2 Sysmaint required for changes: Changing the age group later requires booting into sysmaint session (maintenance mode).

3 Sysmaint password required: A sysmaint login password is required to make changes.

4 Password required for administrative actions: Passwordless sudo etc. will be disabled by default.

5 Bootloader password required: A bootloader password is required to make changes.

6 BIOS password recommended: A BIOS password is recommended.

Age Signaling Prompt
[edit]

DRAFT!

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

[ age input box ]

Computed age bracket: [ 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.

For further information, see age-api.

Computed bracket display behavior:

Not selectable.

All brackets are always shown. The calculated bracket will be highlighted.

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

User Interface Design Rationale
[edit]

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.

The statute uses the word "requires", so implementations might need to be designed so the account holder cannot complete account setup without providing age or DoB. Until it is done, the account holder might be unable to access the relevant signal functionality.

That might suggest:

it cannot be treated as purely optional ("skip forever")

it cannot silently default without the account holder indicating something.

"Requires" does not explicitly say the user interface must be a modal that the user cannot close, or that the only acceptable user interface is a hard blocking prompt.

What might be required:

a setup step where "Next" is disabled until completed (blocking),

or an account setup flow that can continue but the operating system (OS) does not consider setup complete,

or repeated prompting that eventually forces completion.

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.

Moved to Terms of Service Design Draft.

No other known alternatives at the time of writing.

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 FATCA forms, where they must confirm that they are not a U.S. person.

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.

Piercing the corporate veil

Enforcement of foreign judgments

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.

Non-U.S. Legal Entity
[edit]

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 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 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
[edit]

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
[edit]

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.

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
[edit]

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.

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
[edit]

You should just ignore this and not comply: Legal Compliance

Should do this/that instead: See Personal Liability.

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.

Prohibiting California residents in the Terms of Service and Geo-Blocking
[edit]

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.

Non-freedom software: Discrimination against residents in certain territories downgrades Freedom Software to it non-freedom software because it violates the Free Software four essential freedoms, The Open Source Definition (OSD) and Debian Free Software Guidelines (DFSG) which states:

The license must not discriminate against any person or group of persons.

Avoid non-freedom software.

License proliferation: The resulting license proliferation can lead to license incompatibility, hence making Open Source collaboration harder. Software license should be drafted by lawyers, discussed with the broader community and lawyers (in places such as License Review) so these can be approved.

License approval:

Free Software Foundation (FSF) approved

Open Source Initiative (OSI) approved

DFSG approved

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 .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. [1]

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
[edit]

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. Similar laws in New York are an example, although they may not require as robust of measures as they initially seem to require.

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: 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: restricted boot which can prevent installing alternative operating systems or custom system images.

Root refusal: 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 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 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]

The base distribution (Debian) needs to implement this, not derivatives such as Kicksecure: It is correct that Debian may also need to implement this. However, Kicksecure has no influence on that. The topic has been raised at the Debian mailing list 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
[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. No applicable empirical basis for that analogy has been found yet by the author.

Legal impact in case malware is tampering with the age API
[edit]

What would be the legal impact if malware if downgrading or upgrading the age bracket API response?

While malware is always a security issue for the user, it may not be a legal issue for the operating system provider as far as California AB 1043 is concerned.

(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.

Related: Security Impact

Activism / Campaigns / Outreach
[edit]

Contribute by Taking on Legal Responsibility
[edit]

It may be unrealistic to expect developers who are already very busy to personally take on the risk of a legal case. So what is the alternative for someone who still wants to help this effort?

One possible alternative would be volunteers who are willing to be personally identified. This could include providing their real name, address, and any identity verification that may be required. They would need to complete all required paperwork, such as forms, registrations, contracts, and other legal documents. They would also need to accept full personal liability for whichever project(s) they choose to cover. In other words, they would personally take on the legal risk and possible financial costs if something goes wrong.

This is based on the as-yet unconfirmed assumption that volunteers can legally take on this kind of responsibility at all.

If such volunteers existed and were willing to challenge age-API in court, for example by arguing that "code is speech" or by using any other arguments recommended by legal counsel, more projects might be willing to refuse compliance by not implementing age-API.

Outreach
[edit]

https://fosstodon.org/@carlrichell/116201429639953387

Legal Campaigns
[edit]

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

Recently found:

https://agelesslinux.org/

https://agelesslinux.github.io/

https://github.com/agelesslinux

https://github.com/agelesslinux/agelesslinux.org

Update Kicksecure / Whonix status to reflect current plans

https://github.com/agelesslinux/agelesslinux.github.io

https://github.com/agelesslinux/church-of-open-source-software-and-hardware

https://goblincorps.com/ageless-linux.html

https://www.reddit.com/r/privacy/comments/1rkorfy/ageless_linux_a_debianbased_distro_that_is/

Offer for help by https://x.com/prestonjbyrne in this tweet https://x.com/prestonjbyrne/status/2028940016915759579

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.html

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

Future
[edit]

Potentially.

New York State Senate Bill S8102A
[edit]

Might apply to device manufacturers only? Does not seem so.

Underline added.

6. "COVERED MANUFACTURER" SHALL MEAN A MANUFACTURER OF AN INTERNET-EN- ABLED DEVICE, AN OPERATING SYSTEM PROVIDER, OR AN APPLICATION STORE.The New York State Senate: Senate Bill S8102A (archived)

Bold added. Underline added.

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 usersThe New York State Senate: 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".

referral to other article by draft amendment

Bold added. Underline added.

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 articlehttps://web.archive.org/web/20260305091554/https://legislation.nysenate.gov/pdf/bills/2025/s8102a

Section fifteen hundred forty-five might refer to The Laws of New York Consolidated Laws of New York CHAPTER 20 General Business ARTICLE 45 Safe For Kids Act, SECTION 1501.

(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.

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.

(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.

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.

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.

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 referral to other article by draft amendment.

ag.ny.gov: Protecting Children Online, Notice of Proposed Rulemaking

(h) Age Assurance Method. The term Age Assurance Method means any type of age estimation, age inference, or age verification.ag.ny.gov: 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

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

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.

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
[edit]

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.

[...]gov.ca.gov: AB 1043 signing message

Potential Arguments
[edit]

commercially reasonable age assurance
[edit]

commercially reasonable age assurance

It may be commercially unreasonable to implement anything ID-based or voice, photo, video selfie-based due to Kicksecure's Privacy an Whonix's goals (which are fundamentally incompatible with de-anonymizing and fingerprintable verification methods) and thus damage the economic viability of the company and its resources, potentially leading to bankruptcy. Zero-knowledge proofs are likely not sufficient to preserve the user's anonymity.

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.

more
[edit]

Potential conflict with:

licensing such as GPLv3

other jurisdictions such as EU GDPR

federal law

FTC

NIST

DoW

Development
[edit]

https://github.com/Kicksecure/age-api

development TODO task: Age API

Related
[edit]

Lawsuits
[edit]

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
[edit]

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
[edit]

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/

Similar
[edit]

https://metro.co.uk/2026/01/15/teens-outsmarting-australias-social-media-ban-wrinkling-faces-look-older-26306429/

Footnotes
[edit]

↑
https://discussion.fedoraproject.org/t/california-age-verification/181968/92

Dev/cryptography

Design

Dev/Password Manager

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

Kicksecure

A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by
Power Up Privacy,
a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place.
(Strictly subject to our sponsorship policy.)

At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements:
Terms of Service,
Privacy Policy,
Cookie Policy,
E-Sign Consent,
DMCA,
Imprint

2012-
2026 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

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 14 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Age-api&oldid=108315"

Category:

Documentation

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent.

More informationOK

Navigation menu

Personal tools

Not logged in

Talk

Contributions

Create account

Log in

Namespaces

Page

English

Views

Read

Edit

View history

More

Search

Menu

HOME

DOWNLOAD

DOCS

FAQ

HELP

CONTRIBUTE

NEWS

Tools

What links here

Related changes

Printable version

Permanent link

Page information

Content is available under Copyrights unless otherwise noted.

Terms of Service

Privacy Policy

Cookie Policy

E-Sign Consent

DMCA

Imprint