The law says an OS needs to have a way of entering a birth date. Not the correct birth date, it doesn’t need to allow checking it. Just any date.
Two problems:
Well, It depends on where.
If the birthdate field is just a random number, then I don’t see why anyone cares - it would have less personally identifying information than the MAC address.
True.
I thought the whole reason people are up in arms about this is the proposal/hypothetical where the OS is required to validate that field against government ID databases, thus giving a third party - the OS vendor or whatever contractor performs the validation - a link to real world identity of any computer user.
I agree, but in the end it is nothing new in a professional environment.
For example in Italy (but I suppose in EU as well), my employer already know my birth date since I am required by law to undergo a medical examination at regular intervals (with the interval depending on the work and age), so this information is already stored in some way and it need to be correct, my company get fined if I am not checked when required. Having it in systemd or in active directory or any other user management system make no difference.
The problem would arise if there will not be any option to avoid the check, but again, in some countries you cannot ask anything you don’t need to offer the service, and I am pretty sure that the birth date is not necessary to setup an user account on my personal home pc.
The point there is that complying with the whims of every town on the planet gets to be unmanageable. A town with <1000 people deciding what fields are present for the other 8 billion is insane.
Nah, if the problem is the whim of small town I don’t think someone would go to the trouble to implement it. The problem is if the law is from a country, and even in this case it would not be obvious that someone would do something.
Then there we could start a discussion about how this was handled in Systemd, but it out of scope.
I picked color as an example for something dumb that wouldn’t matter. I hoped that was obvious.
I know it was just an example.
And if you can just lie about it, then why even bother including the field at all?
Because who write the law do not understand anything about it and they are naive enough to think that everyone will answer sincerely.
Exactly. How does systemd decide which set of laws to follow? The ones that say you need to report the data or the ones that say you can’t?
That should be asked to the guy who implemented the feature and to the maintainer of Systemd. But the real problem here is that they think that what US laws say are valid everywere in the world. (Not that I have any confidence that Pottering and the other guy would answer in some intelligent way…)
On the other hand also the Russian aircraft and drones are only 500 km away, it work both ways.
It is not, EU already told Slovakia the plan is illegal.
So, I can see where commercial OSes, like Windows and MacOS, but maybe including Chrome, Red Hat, and similar, would welcome the requirement to collect user ages. Another piece of user data for telemetry, ad serving, etc, with the cover of ‘government made me do it.’
Except that maybe they are smart enough to understand that there is no way to be sure that the date is accurate and so you have an high possibility to profile the user in the wrong category.
What if Hemmingford, NE passes the same law but wants your favorite color instead of dob?
You simply input a random color. How they can check if it is true ? Same for any other field.
What if India says the OS needs to verify your caste, or any number of oppressive countries want your religion as a field? Hell, the US is like one step away from saying your gender assigned at birth needs to be tracked.
In some countries it would be illegal to ask for such data. (EU for example)
Then I totally agree that this law is beyond stupid.
Yeah, because it so much more smart to just buy another car if someone in your family need a breathalyzer to drive just because of a beer.
It make sense only if there you keep in mind that there is no way to be sure that it will be always connected, which does not seems to be the case…
And then you can input a random date from before 1940 and forget about it…
Building on US tech means the US generally has control over whether you can deploy your military assets, and gives a foreign, militaristic/fascist trending power, deep insights into your military operations. Pretending like these risks are not greater than, or at the very least on par with, “its hard to integrate systems/build our own” is silly.
I know, but it is not what I said.
I only pointed out that simple saying “its hard to integrate systems/build our own” did not automagically means that it is said by some US influence campaign or disinformation. It can be the result of an assessment done by someone with some knowledge of the reality.
The fact is that such thing is hard and if we want to break free from US tech (as much as possible) we should be aware of the fact, which obviously did not mean that we should give up.
The USA is a threat. They are actively attacking anyone they feel like. They are actively antagonistic towards their “allies” and neutral nations.
Yep, and if Canada and EU had the balls, they simply would send a message like “man, we own your debt, keep quiet or we could just sell it” and then just sell about 10% to just show how it would feel.
So any news story about how hard it is, is likely a US influence campaign.
Not necessarily. To build such systems is hard, they are not simple systems you can put togheter in a couple of weeks.
What is true is that it is difficult to distinguish between a true warning about the difficult to build such systems and a US influence campaign.
Or maybe people finally understand that it is useless to swap the phone every year.
It was, back at the time.
Now maybe it is time to have some more complex system where some decision need unanimity, some a qualified majority (2/3 for example) and some just a simple majority with clearly written rules about what need what majority.
Real time SEPA transfer are active in every EU state from the end of 2025, every EU bank offer it.
The only problem is sharing the IBAN: last time I tried, the bank’s app could not read the IBAN generated by itself on the phone of the receiver.
Is there any reason to pay subsidies for products produced outside the EU at all?
It depends on the objective: if you just want to force a switch from ICE cars to EV cars you simply subsidies EV cars, whereever they are built, it make sense. But it has its quirks
Stop going to these centralized services. The centralization of ownership is the problem, not any specific website or owner.
True, we need the Fediverse, but the Fediverse is only a little harder to knock down, not impossible.
Expecially in the US where fighting in court could simply (and often) bankrupt you. All it is needed to take down and instance is asking the provider the owner of the IP and then sue him for something. A company could fight, a private owner no.
Elections are run by the individual states (unless something egregiously unconstitutional is going on) which allows the governor and even local election officials to make decisions that affect how hard it is to vote almost down to a street level basis.
Same here, it does not seems to be a problem.
If you don’t want people from blue areas to vote, you just put in fewer polling stations, and make them in less convenient places for areas that skew blue on the map.
That assumes that you already know how people would vote. Yes, historical data could give a hint but not a certainty. It is some times that polls are spectacularly wrong.
So adding 30 seconds to the voting time doesn’t really matter for a rural station that might need to service 100 people in a day, but for an inner city location that might need to service 100 people a minute those 30 seconds per person really add up.
True, but think about who could spare more time when voting (hint, probably not the people you want to vote) and you will realize that it is a stupid idea.
+1 for the wayback machine ;-)