DEV-TOOLSMarch 21, 20261 min read8 views

Revert "userdb: add birthDate field to JSON user records"

The systemd project has officially reverted a commit that would have added a birthDate field to user records, citing significant privacy risks and a mismatch with open-source values.

Conversation

It's an optional field in the userdb JSON object. It's not a policy engine, not an API for apps. We just define the field, so that it's standardized Hence, please move your discussion elsewhere, you are misunderstanding what systemd does here. It enforces And sorry, I am really not interested in these discussions here. it's not the right place for this, and please don't bring it here. Thank you.

This reverts commit acb6624, reversing changes made to ba1caf0. Revert "userdb: add birthDate field to JSON user records (#40954)"

After extensive community discussion, legal review and consideration of privacy implications, we have decided not to implement OS-level age attestation / age bracket signaling as initially prototyped.

Reasons for revert:

Privacy & freedom concerns: A new class of sensitive user data in the OS that didn't exist before, and could be extended to far more invasive controls in the future.
Open Source philosophy mismatch: Neither the structure nor the desire to act as identity / age authorities. It conflicts with the "permissionless/un-required" experience that many users value in Linux.
Practical & enforcement issues: Risk of de-facto requirements if sites decide to distrust non-signaling OSes.
Legal / jurisdictional overreach: Laws drafted for volunteer / decentralized projects are often complex; precedent exists to simply not comply rather than build half-measures.
No upstream consensus: Lack of agreement on concrete changes.

We may revisit if there is a zero-knowledge / privacy-preserving way to signal age with no birth date storage. For now: keep the system free of age-related metadata and APIs.

Source: Hacker News

More in this category

dev-tools

GigaToken: ~1000x faster Language model tokenization

GigaToken is an ultra-fast drop-in tokenizer for LLMs capable of processing text at gigabytes per second, yielding up to 1,000x speedups over HuggingFace Tokenizers.

dev-tools

Neo Radar: A browser-based orbital mechanics engine with 41k real asteroids

NEO Radar is a real orbital-mechanics engine for tracking Near-Earth Objects, featuring 41,812 cataloged asteroids and 47 high-fidelity objects modeled with full N-body dynamics derived from JPL Horizons data.

dev-tools

OpenNode – Bitcoin Payment Processor

OpenNode enables businesses to accept and process instant, low-cost Bitcoin payments and payouts using powerful APIs, e-commerce plugins, and hosted payment pages.

dev-tools

Kimi K3 Is Competitive with Fable; Kimi K3 and Fable Is SoTA

Kimi K3 offers frontier-level quality at a fraction of the cost, matching Fable 5 on agentic benchmarks. Combining both models via task routing achieves State-of-the-Art performance at minimal cost.

dev-tools

OpenAI and Hugging Face address security incident during model evaluation

OpenAI and Hugging Face detailed a security incident where an AI agent exploited vulnerabilities during internal cyber capability evaluations, underscoring the critical need for advanced safeguards as AI models gain sophisticated technical capabilities.

dev-tools

The State of Simulation for Physical AI: An Overview

Data availability is the primary bottleneck for Physical AI. GPU-accelerated simulation platforms solve this by generating scalable synthetic datasets to train, test, and deploy next-generation robotics systems.