Compliance with U.S. age verification laws

Meta
81

Same. I asked the foundation board to allocate resources for lawyers to look into how exposed we are to this new law, and the head of the board Ron did say that he’d have them look into the legal perspective.

My hope is that we won’t have to take any serious measures just because the US decided to implement a bad law (just like if the UK did it, since the foundation is based in the NL and not for profit).

Distributions need to directly answer this with the refusal of using systemd.

I disagree.

For people that live in the US, if they were specifically required to comply with this new law, it would make sense to support their use case so that they don’t have to use windows. Even if they have to obey a problematic law.

Not leaving them with an alternative isn’t freedom fighting, it’s just posturing that harms actual peoples freedoms.

That doesn’t mean it should be default behavior, but there is nothing wrong with providing people options instead of just leaving them out to dry, just because they’re in a repressive regime.

I’m honestly now sure why we are blaming systemd for creating an option to move forward? Pretending there isn’t a problem wont change anything, and it’s no substitute for actual actions that could help change this law. It seems like shifting the blame away from the actual institutions that caused this problem, and blaming the project that seems to be trying to patch that reality.

That said, ideally, larger organizations like CNCF, the Linux Foundation, and others with the actual size to affect industry laws should step up to contest this.

5 Likes
82

look carefully, systemd wants to be the centralized entity for age-verification

if it happens, this is an easy way for anyone to integrate age verification.

Distros may refuse using original systemd, or at least disable its age-verification methods and implement custom non-usable in large scale methods to “comply”.

Its bureaucratic games after all. Comply, with the worst solution possible, to make the law ineffective.

3 Likes
83

Don’t get me wrong, I am by no means in favor of the law, as a father I see the idea, the value in the communicated intend, still the way it is written, is problematic.

But I can not follow all the orwell style conspiracy everyone sees.

And sure, operating system providers should speak with the lawmakers, but thats not me, thats on RedHat, Canonical, Apple, MicroSoft, the foundation, the debian poeple, the Arch poeple, but again, not me, not you.

And so far, the only operating system provider that so far seeked actual contact to the law makers is System76 to my knowledge, reaching out to the state of NY, but only that one state.

Discussing in a forum whether or not your favorite distro and software should obey to the law is not the right thing.

From a standpoint of a software manufacturer, if you can not negotiate you have to obey. Obeying can mean to adjust the EULA to exclude certain legislations from using the software (as pointed out above) or to actually implement what is asked for in the law.

And as neither the foundation nor the comitee said anything here, the official stance seems to be “sit it out”, and that is the worst stance they can take.

I’d really appreciate someone official dropping an official roadmap or information, maybe there are indeed negotations for excemptions? Maybe there are plans to just not care, maybe there are plans to adjust the EULA? So far everything that happens within NixOS/nixpkgs, is just merging updates from software developed out of our control.

And I am aware of users plans to contribute liberated systemd as an alternative to mainline systemd. I do not know how far they are though.

3 Likes
84

You’re potentially right, but seems that System76 has a valid point that it’s highly likely that there will exist multiple competing implementations for this anyway, so surely a standard will eventually emerge that systemd would simply piggyback on?

Honestly regardless, Pottering is taking this more lightly than I’m comfortable with, their implementation is questionable, and I wish we had an alternative. But I think the idea of just ripping systemd out is a bit misguided. And it doesn’t seem like there is a reason to patch this out yet.

I think a better usage of effort would be along the lines of:

  • Joining forces with other devs on a fork of systemd, keeping in mind this is likely a monumental task.
  • Making nixpkgs/nixos more “pid 1 agnostic”, so other systems could easily be interchanged with a common interface. This would also likely be a lot of work, but would be a significant improvement, that would guard us as a distribution against things like this in the future.

Seems that those options would actually be realistic paths forward. Just ripping out systemd without a migration path and an alternative would probably not happen (simply because it would be extremely hard to get consensus for this), and with an actual abstracted way to handle services and other systemd responsibilities, it would be much easier to change the default, rather than replacing one tighly coupled dependency to another one that isn’t an industry standard yet.

5 Likes
85

No, systemd just gives verification services a way to centraly store the DoB.

If they wanted to be central for verification they’d make that value tamperproof from the beginning by cryptographically signing it.

86

Exactly, I think this is n1 priority

3 Likes
87

FWIW I’ve been pushing for this… But just like those legislators who wrote that law, we’re also pretty slow at policy ourselves - unfortunately. When I know where we actually stand legally I was hoping to discuss this in the SC and contact the nixpkgs team, but without knowing where we stand legally, it feels too early.

I’ll keep this thread updated with what I learn, but I’m expecting it will take a while until I hear anything.

EDIT:

I should clarify that I agree this seems to have become the de facto stance. I am a member of the steering committee. I’ve made this exact same point to the board and SC. And things are moving, but slowly.

4 Likes
88

Systemd was always a heat discussion topic.
And they are known for centralizing many stuff, like booting, cgroups.
They were trying to centralize containers.

And now they are a bit centralizing age-verification.
I never liked this trend, if they implement cryptographical age-verification someday, it will be catastrophical…

I don’t want to see anyone even attempting to make a centralized age verification method, either its xdg or systemd. I don’t care and I stand against anyone attempting to implement it on a large scale.

1 Like
89

And I do not like to see linux to be catapulted back into the 1990s where one had to install different supporting tools depending on the software you want to use.

Things are still bad enough with wayland vs X and alsa/pipewire/pulseaudio and GTK vs Qt (the latter especially if you try to get consistent theming).

If we really have to obey, then I want a single source of truth, and not be forced to do age verification every other day, just because I install a new game that uses a different age provider mechanism.

90

And I do not like to see linux to be catapulted back into the 1990s where one had to install different supporting tools depending on the software you want to use.

It’s more than just user comfort today.
The governments want the software to integrate something we don’t need.
The community should agree: this is not a part of linux, is not a part of software by design.
This - is a result of bureaucracy, not a need.

So, whenever anyone asks about “why my proprietary/corpslop program does not start“, the only answer should be: “this program uses components, the most users and devs are against, tho we implemented it(or we did not), here is the guide“…

It may sound cruel to gatekeep comfort, but making age-verifiction a norm is opening a space for politic→software abuse.

–

Tho funny, how wayland bugs are not being fixed for years.
I still have broken UI interaction in SC and nearly-working xdg portals.
But when it comes to compliance, flatpak rushes to make a xdg portal for age verification.

3 Likes
91

Looking at Android, patching out fake-security checks when building from source takes much less effort than a proper fork…

Well, it’s exactly the fragmentation that gave an option basically to sit out the entire PulseAudio by running most things on ALSA until PipeWire appeared…

«Age checks became so annoying that the users use cracks to wipe them, and then pirate the game while they are at it given they already downloading shady cracks to remove checks» is a problem I would like the larger vendors to have…

2 Likes
92

Systemd is modular. You don’t need to use systemd boot, most distros still use grub. Systemd has containers which use cgroups, a linux feature. They’re not “centralizing” shit just by offering an implementation of it. (edit: learned only one process can manage cgroups as of v2) You can mix and match whatever systemd components you please, including userdbd.

The slippery slope argument has a different name when it’s used to extrapolate end conditions that aren’t actually likely, it’s called the slippery slope fallacy. When talking about a government implementing age verification as a way of pushing mass surveilance and censorship, the slippery slope aregument is very strong because governments are motivated to do this and many groups have been very open about how they plan to use these “think about the children” laws to censor speech they don’t like. When talking about Systemd, it seems more like a slippery slope fallacy to me. The only crime systemd has committed is daring to provide a unified linux system experience without attributing it to GNU. Nothing the systemd folks have done suggests they want to capture linux users, own a monolopy, or help the government with their tracking. There’s no motivation, no history, and no stated intentions from pro systemd people that this feature will be abused.

There also seems to be a misconception about TPM. TPM is orthoganol to the situation you outline. Your concern about age verification certificates is warranted but it can happen with or without TPM via standard PKI infrastructure.

2 Likes
93

It’s really disappointing to see so many bad takes here, like or “not my jurisdiction, not my problem” or “leave it up to the lawyers” or “let RHEL deal with it” or “let the system do its work and we’ll all be fine” or “it will never be enforced” or “just b/c we ship with systemd as default or there’s a birthDate field doesn’t mean anyone has to use it.” I dunno where folks here like to get their news, so maybe you haven’t heard, but there’s a pretty vicious rise of authoritarianism going on in the world, and it’s not limited to just one or two isolated countries. These “age assurance” laws (in CA, TX, UK, BR with more coming soon to the EU and Canada, I believe) have nothing to do with guaranteeing junior doesn’t see a nipple til he’s the age of consent. I mean, what percentage of the politicians sponsoring these bills would you be willing to bet flew on the Epstein jet at least once? The policy is intended to require everyone carry papers with them every time they click a link, open an app, or make an API request. And no, they don’t have to enforce it everywhere; the whole point is that they can enforce it anywhere, selectively – say, for instance, someone doesn’t like your politics or your complexion or your haircut on a given day.

Glad at least there’s a few ppl here talking sense, like @TLATER and @hashelq and others I’m sure I missed, more power to ya, but gadzooks, rest of y’all need to take a look around! :sweat_smile:

5 Likes
94

I’ll probably get my post squelched… but, in the 30,000 ft view.

It seems like Meta pushed this legislation.

Linux has been public enemy no 1 for quite a while (I would suggest that a lot of the in fighting across various distributions in the last two or three years has a classic hallmark - work that out for yourselves)

If they were so worried about children, how come no-one was prosecuted in the Epstein case for a gazillion years? If they really wanted to protect children they would not disempower parents,whilst empowering institutions to teach the children a load of crap. (I’m probably now going to get a lifetime ban)

Read the runes.

A very dystopic future is here. AI has been selecting who to murder for some time now…the bottom line is that they want to track everybody all of the time. This is not Sci-Fi, it is fact. They’ve said so.

4 Likes
95

For the paranoiacs:

  • Do you agree that the state of the software right now, ignoring future developments, doesn’t pose a threat to anyone’s freedom? (Or at least, no greater threat than patching systemd or reverting it to two months ago would pose?)
  • If so, in any possible future, there are two possibilities: either some component of age verification is introduced that is not under the computer owner’s control (an online service, a hardware module, etc.), or there is no such thing.
    • If there is, what do you expect patching/removing systemd will do? If they don’t get the right magic token from that service or module, applications that use libageverif.so will, at best, fail gracefully and treat you like you are in the youngest age bracket. At worst, they’ll fail to function at all. NixOS would need to patch libageverif.so out of applications to restore functionality — and that’d be worth doing! But there’s no libageverif.so to patch out yet. Systemd isn’t that (and if it someday includes a component to do that, we can exclude it or, if they make that difficult, remove systemd then). And if for some reason the lawyers tell us we can’t support circumvention of age verification schemes, then we’re in hot water no matter what symbolic gestures we make with respect to systemd today, because if there’s no birth date field, or no userdb, or no systemd at all: too bad, still no token, still no use of that libageverif.so-dependent functionality.
    • If there is not, guess what: you’re still in control of your machine! You can lie. There are all sorts of things we could do to make it easier to lie. But again: none of those things need to be done yet, because right now it is trivial to lie, or even better, simply not to bother with submitting any birth date information.

So, either way, there’s nothing to do right now except maybe get some preliminary opinions from lawyers. We patch problems once there are problems to patch.

7 Likes
96

I fully support Nix choosing willfull noncompliance or “leaving” the states and countries that require such authoritarian laws. I do not believe we should let others make choices for us, and I think that offering parental controls (good) and enforcing age restrictions at the service povider level (bad) are worlds apart. It is important that all operating systems (which are able) to say “no, we won’t comply with fascism”.

But I’ll die on this systemd hill. If and when systemd chooses to enforce usage of birthDate with some external verifier, then I will protest and patch it out. That is my red line. As it stands right now, this is not what systemd is doing, and I think systemd is catching a lot of unnecessary flak that should be directed at lawmakers, lobbyists, and the companies they work for.

3 Likes
97

The third compromise option might be to work on adding features to e.g. rustysd while removing our dependency on the more obscure systemd features?

1 Like
98

What do you have in mind (assuming you meant systemd)? I don’t think we have many.

In particular, services.homed.enable and services.userdbd.enable both default to false on NixOS. Even if you wanted to run homectl update srd424 --birth-date=1970-01-01, on a default NixOS installation, all that would happen is:

Failed to acquire user home record: Unit dbus-org.freedesktop.home1.service not found.
99

Personally I’d love to see more types of init systems in general, and if rustyd can be improved to work with nix, or vice versa, it would be cool to see.

100

(thoughts are my own, not representing the broader SC)

Here is a sequence of thought that I go through for this:

  • we are an open source distribution
  • one of NixOS’s great strengths is its flexibility
  • if anyone wants to add age verification to NixOS, it isn’t hard to do
  • manufacturers in the relevant jurisdictions can relatively easily implement the referenced “accessible interfaces”
  • if those people would like to also maintain such interfaces in Nixpkgs, they are welcome to implement them
  • we are not under an obligation to make such an implementation the default, but location-specific users are free to do what they wish
  • We don’t distribute an operating system, but operating system installation images and a framework for people to build their own operating system.

We also have some values that might shed light on this:

  • Free software and choice over lock-in: yep, we can provide choice. Our users can decide what variant of systemd or libageverify, or whatever to implement or to maintain.
  • Distribute decisionmaking widely: there is no requirement to make a single central decision, if a lot of people think it is worth maintining age-verifiacation features - go for it. If people decide they don’t want it, then don’t. Neither should need to block the other.
  • Stable evolution over stagnation or chaos: we can just roll with events as they unfold. We’ll see what other OS’s do, what library and application developers do, and adjust accordingly.

It does not seem there is a need for urgency on our part; anyone using NixOS for whom this is a problem can solve it without our help. On the other hand, I can see all sorts of outcomes here that we can’t predict - to think through a few random hypotheticals:

  • it becomes common practice to just lie and claim you are older, as is fairly common in any age-request forms already out there
  • it becomes common practice to just lie and claim you are younger, so that the extended privacy protections apply to you
  • it turns out that by providing so much flexibility in NixOS, the burden to apply such an interface is the responsibility of the person doing the original installation, to opt-in to age-verification, remember to read all documentation. RTFM
  • it turns out “developers” don’t request such signals in practice and those whole system is moot
  • the feature is implemented in systemd… and just sits there
  • this becomes similar to the tags on mattresses or the California laws mandating extra safety notices, a piece of legalese, but ignored by 99%
  • The law is challenged in court and subsequent case law clarifies things
  • Other jurisdiction come up with other complicated schemes and everyone ends up more confused
  • People start to insert clauses that usage of that software is not guaranteed to comply with local regulations
  • We end up with an extra dialog box during installation asking for a birthday and call that compliance.
  • Browsers and webpages either do or do not adopt this broadly, and https://nixos.org ends up on centralized lists as appropriate/inappropriate for various age brackets.
  • GPL has “If the work has interactive user interfaces, each must display Appropriate Legal Notices” and “If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program…”

It’s hard to predict what will happen. If someone has access to the proper venue or knows who we should tell that the law is poorly written and misguided, then we can provide our thoughts and advice. There are organizations like the Linux Foundation, FSF, OSI, etc who are the ones who have a better chance of impacting things, engage through them.

My plan is to get some legal advice - because very few of us are lawyers - and monitor the situation for now. If we get an indication that something else is needed, then we revisit the issue.

7 Likes