WIP: [DRAFT] users: add birth date field for age verification #2499

I think there are a few issues here.

First, this absolutely has to be an configuration option.

Second, there is no guarantee that accountsservervice is in-use or is installed at the point of user creation.

Lastly, is there some general alignment that this is the appropriate place to store this information? It seems questionable to store DOB in plain text.

@dalto wrote in #2499 (comment):

I think there are a few issues here.

First, this absolutely has to be an configuration option.

Second, there is no guarantee that accountsservervice is in-use or is installed at the point of user creation.

Lastly, is there some general alignment that this is the appropriate place to store this information? It seems questionable to store DOB in plain text.

AccountsService keyfiles are root-owned (0600), so they're not world-readable.

IMO this probably should not be merged. Some jurisdictions with age verification laws in planning or already passed may make changes to them to exempt some open-source software from the requirements, so this might not be needed at all. If it is needed, KDE and GNOME are currently working on an implementation that goes through xdg-desktop-portal and allows the backend to implement this functionality however it sees fit. AccountsService is probably not going to be where the information is stored in the long run, and AccountsService itself may be going away entirely. See https://github.com/flatpak/xdg-desktop-portal/pull/1922 and https://fosstodon.org/@carlrichell/116201429639953387 for context (ignore the Reddit-induced witch hunt on the linked Github PR). It's also worth noting that some jurisdictions allow simply providing a birth year, not a birth date.

If this kind of functionality was ever needed, it would need to be aware of how each xdg-desktop-portal backend implemented this. None of them do yet, so this can't be implemented yet.

I already mentioned this above but I agree with @ArrayBolt3 in that we should not modify Calamares until there is some approach that DEs/distros are taking towards this.

Calamares should not be the implementation driver here. There should be an implementation and then Calamares should be modified to support that.

This also contradicts laws of other countries.
And opens doors to add of regional laws compliance modules.
Just my opinion - this PR is malicious by nature, and should be considered as act of sabotage.
It cannot be trusted to not contain subtle "errors" and stuff.
The same person tries to put "age verif" changes all over github. Its not a usual contribution activity.

@Nyanraltotlapun wrote in #2499 (comment):

This also contradicts laws of other countries. And opens doors to add of regional laws compliance modules. Just my opinion - this PR is malicious by nature, and should be considered as act of sabotage. It cannot be trusted to not contain subtle "errors" and stuff. The same person tries to put "age verif" changes all over github. Its not a usual contribution activity.

I'm not sure it contradicts laws of other countries, but I think there are two changes that need to be made here:

• There should be a flag to opt in/out of having this field render set at build time (as some distros may not care to comply with laws)
• Display of this should be able to be made conditionally on the country selected (i.e. only Brazil/USA)

this PR is malicious by nature... The same person tries to put "age verif" changes all over github. Its not a usual contribution activity.

No. People are unaware of how operating system development works when you have multiple moving pieces that need to work together.

Firstly, userdb/accountsservice as the storage layer
Then, installers for having a date picker/field during account creation
And last, something like the xdg-desktop-portal for being a broker from the storage layer to applications so they get an 18+ signal instead of direct access to PII.

It is not atypical to make related PRs that are designed to work with one another (see: any other project, GNOME/KDE, etc. with complexity). Also, my PRs actually link to one another with explanations of how the pieces work together and this development is being done in the open.

The outrage I'm seeing over a birth date field and a date picker is staggering. There's literally no verification whatsover, not is there realistically any way to add it even if someone wanted to.

@dalto wrote in #2499 (comment):

I already mentioned this above but I agree with @ArrayBolt3 in that we should not modify Calamares until there is some approach that DEs/distros are taking towards this.

Calamares should not be the implementation driver here. There should be an implementation and then Calamares should be modified to support that.

This should wait for a final version of the storage layer/portal to go in, let me mark as draft for now.

@dylanmtaylor

But how exactly does any of this concern people outside of California? If California passed a law tomorrow requiring a backdoor, would you roll it out globally as well?

There is still the issue of encryption. While many jurisdictions consider DOB PII, some of the more stringent ones consider it SPI. This is means it must be encrypted. Requiring permissions to access it is not at all the same as encryption and will not satisfy this requirement.

@Nyanraltotlapun wrote in #2499 (comment):

@dylanmtaylor

That's all well and good, but how exactly does any of this concern people outside of California? If California passed a law tomorrow requiring a backdoor — as Australia requires — would you roll it out globally as well?

I'm not familiar with Australia laws, but no, that's not a feature I would work on. Nor could I be compelled to do so as an American citizen. Also, that's off-topic for an installer. As I mentioned in - the only asking for it in certain locales does make sense. I'm not sure if we prompt on state yet, but calamares would need a way to ask the user for not only their country but also the state to conditionally display that. Or, it could be limited to just certain countries for simplicity -- a growing US states are requiring age checks, and I think it's not unreasonable to have a date picker. It would be a real burden/challenge for FOSS projects to keep track of what states require this and keep that up to date in the source code. If the checks were to become less privacy-preserving, that'd be a different conversation, and I'm not sure how FOSS projects would handle it, but right now it's "tell the operating system what age you are (pinky promise not to lie), and we'll tell the apps you're 18+ or some other range if they ask". I don't think that's unreasonable, and I believe a lot of Linux users will be celebrating birth days on January 1st.

As for encryption - that would be out of scope for the installer. That's something whatever is storing it should address. I don't know if the bits themselves need to be encrypted or if file system level permissions would suffice. Generally, we want these bits to not be readable by anyone, but if the users themselves can read their own birth date, so can any app that is not sandboxed. I think the solution here is to have proper app sandboxing whatever that looks like - it is a good privacy practice anyways. I know people have some mixed feelings about Flatpak, but that is one benefit they offer when configured correctly.

I'm not an expert on sensitive/non-sensitive PII, but I will reference https://www.fortra.com/blog/pii-vs-spi-what-you-need-know-effective-data-protection. It seems that A date of birth (DOB) is generally considered non-sensitive Personally Identifiable Information (PII). The AccountsService PR does attempt to implement reasonable policy kit controls to protect access to the field's value.

@dylanmtaylor
You don't see the problem — you're trying to project the legal issues of a specific region onto the entire world. The Australia analogy is pretty direct: how are they any different with their backdoor law? What you're doing is exactly what Australian contributors could have done — and possibly did — back in 2018. What's to stop every other jurisdiction from demanding the same, now that a convenient mechanism exists to deliver it?

It's no surprise the community is bewildered by your requests. You clearly don't understand how open source works. The project will simply get forked and the unwanted code removed. You're not the first to attempt this and you won't be the last — it always ends the same way: project splits, the people who accepted such changes get condemned, and trust in the original is permanently undermined.

Countries with laws that can explicitly compel developers to implement backdoors or covert access mechanisms:

🇦🇺 Australia — Assistance and Access Act (2018) — can secretly compel individual developers to insert vulnerabilities, with a gag order prohibiting disclosure
🇬🇧 UK — Investigatory Powers Act (2016) — compels backdoors in software and services, gag order included
🇨🇳 China — National Intelligence Law (2017) — any citizen or organization must cooperate with intelligence services on demand
🇺🇸 USA — CALEA (1994) + FISA Section 702 — telecom backdoors mandatory, broader software compulsion via secret court orders !!!
🇨🇦 Canada — Bill C-26 (pending) — would grant similar compulsion powers

Note the common thread: every single one includes a gag order. A contributor under such a law cannot tell you they were compelled. That is the entire point.

@dalto wrote in #2499 (comment):

I think there are a few issues here.

First, this absolutely has to be an configuration option.

src/modules/users/users.conf line 314 of the current diff makes this configurable already, but I think it might be worth doing a compile time option so distros can choose whether or not to have this field included is pragmatic. Then distros that need to request a birth date can do so, and distros that wish to not prompt for this data can opt out. We can even make the default false. The important thing here is that for commercial distros that DO need to prompt for this to comply or where maintainers are not comfortable not asking for a birth date, there is an option that will let them choose to do so based on preferences.

Second, there is no guarantee that accountsservervice is in-use or is installed at the point of user creation.

True, it might have to set it by copying something like a one-off script to the target system that handles that on first boot or something, from a root-only readable file.

Lastly, is there some general alignment that this is the appropriate place to store this information? It seems questionable to store DOB in plain text.

We'll see what that looks like. The systemd project has merged in the userdb change as the whole internet is aware. AccountsService mirrors that change with a getter and setter for birth date. Not storing it in plain text would be hard, because you'd have to have a keypair on the filesystem that is accessible to anything that needs to decrypt it, so it might make the encryption key world readable or maybe even readable to any process that user has. Security theater. I'm not sure how you'd make it not plain text. And anything running on a user's computer as them has access to much more sensitive info, like all of their browser cookies, unless proper sandboxing via something like flatpak is enabled.

I have locked this topic to contributors since the conversation was turning grossly inappropriate.

That being said, I want to be clear that it, in my opinion, it isn't Calamares' role to gate keep and decide if this is good/bad or right/wrong. That is up to the distros who use Calamares to decide. Calamares' role is to ensure this option available to distros who choose to use it.

However, we do need to make sure that it is fit to purpose and technically/logically sound.