From nobody Tue Mar 10 12:33:28 2026 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fVYFn6CfSz6VZjc; Tue, 10 Mar 2026 12:33:33 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from ratatosk.b1t.name (smtp.b1t.name [130.61.88.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4fVYFn0GHXz4N9N; Tue, 10 Mar 2026 12:33:33 +0000 (UTC) (envelope-from arcade@b1t.name) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=b1t.name header.s=rat header.b=fj5mWV9J; dmarc=pass (policy=none) header.from=b1t.name; spf=pass (mx1.freebsd.org: domain of arcade@b1t.name designates 130.61.88.158 as permitted sender) smtp.mailfrom=arcade@b1t.name Received: from [10.125.1.20] (unknown [91.199.138.118]) by ratatosk.b1t.name (Postfix) with ESMTPSA id AD8E5EE3; Tue, 10 Mar 2026 12:33:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=b1t.name; s=rat; t=1773146010; bh=jELoR7yV08xHgBzdp3ePOi85+4adozAqMhw3eLvuQAg=; h=Date:From:Subject:References:To:In-Reply-To; b=fj5mWV9JbnKkbdA0mELcoRxoE9jmPDcHYI/7bdtKdeUBaafkKCgsKqQHe81P/ldf+ 13MlruVbmgYOwqPRc37ZJ2MhIZq5YJ85UzBhocTuQzQw0vAYkdJEBQ1kkD/LC+Wur8 O7rCojs4LT+cT3J4Y90NqB4UDQDkRGCWgzFYJzrd8APE+KQvL6Ca9ryNeiA809bgIb oCq9Zvb8nBzWlT30GKAvGxiZSXsE9rCszJCVbYQhE4FgXwvbFroWF+0pbtgwwZlsKO ATneaThR9DAbdkR0g+9lse6+CtImecnZui+xCx2wxmDbYvoyUydJhDCRgTfY7ej4df B7VGHbozNaduomR3aQaRu6rFVm0u4lueZRgknMkCi2V6ymrSKjrq2+A1G9rHmo+Zkr 9R0N2mz8+hl8q3xVRJxU0Ah9rn8xNeMNwzSLPhheJEYilN0CRWQB7ItQCWMycvRLjv qHP2psSCUGvn3R5NK44viWIP+GqB3iSdOmUIWw3moD/a1VAN9gUS6EYI6oM7HfORTA k89uuZbKnfrtV4hqlWy33iUhV/B7RVZRFCC3neKwewelyXkk5zkYXHkELHHJt7PJS0 ALJvv7mMWZ+dz2cqa0il8PBMoSbOXW3nJ8RKpNaHeOpa953IRXGNRui9zNo+BXflJV E5cHCNrixeLCrDXzfEITYxj8= Message-ID: Date: Tue, 10 Mar 2026 14:33:28 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Volodymyr Kostyrko Subject: Re: Practical suggestions for resolving the Age Verification problem References: <08dc619e-955a-438d-86ba-751b1fa63bce@vincentbentley.co.uk> <17977bb140d10505168a9af142dc09c8@bsdforge.com> Content-Language: en-US To: "freebsd-hackers@FreeBSD.org" , freebsd-pkg@freebsd.org In-Reply-To: <17977bb140d10505168a9af142dc09c8@bsdforge.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.79 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[b1t.name,none]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[b1t.name:s=rat]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:31898, ipnet:130.61.88.0/21, country:US]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-pkg@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[b1t.name:+] X-Rspamd-Queue-Id: 4fVYFn0GHXz4N9N X-Spamd-Bar: --- 10.03.26 11:39, Chris: > On 2026-03-10 00:44, Michael Schuster wrote: >> On Mon, Mar 9, 2026 at 11:13 PM Chris wrote: >> >>> On 2026-03-09 10:39, vermaden wrote: >>> > Lucas Holt from MidnightBSD just created aged(8) here: >>> > - https://github.com/MidnightBSD/src/tree/master/usr.sbin/aged >>> >>> While I think the initiative as written is untenable (unenforceable) >>> Wouldn't it be enough to write an additional field to adduser(8) >>> say; born / over 13? Then allow ports to use it as they so choose? >>> It's a dead simple approach w/ near zero work/overhead. >>> >> >> Speaking as a "naive" user and developer: >> Where would you want to store that information? the GECOS field is known >> nearly universally, you can't just change it, it'd break ... lots ot >> stuff. >> >> Besides: storing people's age in a publicly visible place probably >> wouldn't >> fly with many people, esp in the EU. > I was thinking more on the lines of permissions of different users in > the same > way their regulated already. Adding another category and applying > appropriate > perms to match. It basically changes nothing in the way a system regulates > user categories now. I was simply suggesting adding another (age based) > category. > Perms can be set accordingly. > Seemed like an painless possibility. Maybe I'm over/under thinking it? There's a really bad example on storing sensitive (PII) information. During World War ][ there was many more victims amongst jews in Netherlands then in all France, and one of the reasons for that was better government records. What is currently is being discussed is PII - Personally Identifiable Information, that can be used to select and target less protected citizens, easy pray. Storing this information in files in clear form makes this information accessible to anyone who can access host (including remote access). Storing this information in encrypted form to be available only under select user is also prone to be queried by any malicious software, including remote exploits resulting in targeting kids online. So I humbly ask all developers here to think twice before querying, storing and making available any sensitive information that is not required for system to function so none of us would later be liable for disclosure. -- Sphinx of black quartz judge my vow.