I’m intrigued how KDE will involved with implantation of age assurance laws like California’s AB-1043 Age verification signals: software applications and online services.
From my understanding (I’m not a lawyer):
There needs to be some sort of age management package that allows root to enter or modify the date of birth or age of end-users and provide an API that returns the age range.
There could also be a gui package to implement that as well.
I’d guess major toolkits like QT will need to be modified to read the age range.
So far it looks like this will be fairly simple from a DE/OS vendor point of view: require that new user accounts provide their age, and provide hooks for 3rd-party software to read this age to tailor their content appropriately.
This effectively shifts liability onto the person providing their age to not lie about it, and for software or websites offering content potentially not appropriate for younger ages to read the age value and automatically offer an age appropriate UX.
The exact specifics seem flawed if depending on a regular user.
I was mentioning root specifically because a regular user could much more easily lie about their age than a user with root privileges entering the details. A root user is much more likely to be an adult and make sure the correct age is entered.
Regardless of how well-conceived these laws are or aren’t, we have to comply with them or else our software can’t be shipped on software sold in those jurisdictions — and by extension most others. Why? Because in practice, California’s product standard laws become worldwide or global in scope due to manufacturers not wanting to sell slightly different products in different U.S. states or countries.
Would it be possible for the age assurance/verification part to be implemented as an optional extra package, rather than part of an existing KDE Plasma package? Prevents the need to verify age if you aren’t in affected regions. Would be unnecessary data collection.
I don’t like it either, but I think this is only required for devices for sale with a preinstalled operating system. So like if someone where to order a computer with an operating system preinstalled. You’re correct that this is a slippery slope, but I don’t think its productive to jump to nihilistic conclusions right off rip.
I think that if it is required, then putting it in an optional package is probably the best way to go about it, so it can be selectively applied to meet regulations where required and not everywhere else.
I wasn’t actually requesting for or against the feature. Some distros are geo-blocking.
If it’s extremely invasive like submission of documents, rather than just age or DOB, I’m definitely going to find alternative ways around. I’d likely remove plasma-desktop, systemsettings, etc. I already use a trimmed down version of Plasma.
I am an adult, therefore I shouldn’t have to submit. It’s been proven to have serious security flaws and commonly not done in a privacy respecting manner.
It’s probably feasible to allow the feature to be turned on or off via a CMake option that distros can opt into or out of.
I don’t foresee it being feasible to offer this feature in a standalone git repo that distros can put in its own optional package. Slicing up a UI like this is awkward at best if it’s even possible at all, and it usually isn’t because this requires building a whole plugin system to allow parts of the UI to be added and removed at runtime.
I would suggest that this law is a hastily drafted work intended to target the corporations that have integrated systems and software centres - so Windows, Mac, Google, iOS will be the targets… as you must create an account with them in order to use their operating system (note the emphasis on ‘Theirs’ which means THEY are responsible).
There are too many issues for KDE to take this very seriously at this point - if I set up a computer for my toddler to play with (offline or otherwise), then would my toddler be banned for not verifying their age?
Then perhaps some folks avoid using accounts and simply boot up the live USB to do their daily dose of salacious content…
The law was worded very broadly, so it can be interpreted as a real threat - but I’m very confident that nobody cares about us.
The implementation may not difficult but figuring out what to implement how is. The challenge is not on the technical side.
Points to consider:
asking for the age is problematic since it means someone may need to update it regular, ie once a year.
asking for the birthday is problematic since this is personal data and dealing with personal data, and providing it to external sources like untrusted flatpak apps, will put tons of additional requirements like e.g. those defined in the DSGVO.
a solution for that could be to e.g. only ask “ adult or child” on account creation and if “ child” is picked ask for the year of birth what should be unspecific enough to not make it personal data.
the Cali law asks for age ranges and defines them as API. Other similar laws in other countries define different ranges.
taken the situation of conflicting laws and requirements in different countries, users being able to travel between countries and hence not fixed laws and requirements since local laws will apply, the problems of potential high fines and the need to do this good enough makes it a hard problem.
Ideally we would have a cross desktop proposal for a solution that went through lawyers before implementation and rollout. The timeline is a problem.
I think MidnightBSD did the most sane thing. First protect yourself then take the time it needs to come up with a solution.
Following up on a possible (temporary) middleway between “doing it like MidnightBSD” and “let’s ignore till we are hit”:
In the userinfo kcm add one additional textedit that asks for Year of Birth. Save the value in KConfig and have a DBus Service with a method that turns the KConfig value into a CaliLaw2027AgeRange enum with 18+ when not set (the default). Leave it up to apps if/how they make use of that.
Goal is to check all checkboxes and not to be the most useful feature out there.
Once a proper cross desktop, cross distro solution is there (or if the law is revoked/adjusted) replace/remove it again.
If we ever had to implement such things (and I hope we won’t) I think it needs to be specified at the FreeDesktop.org level so the behavior will be consistent between DE
I feel like this doesn’t need anything more than an added environment variable.
But at most, we can add a DBus endpoint.
For KDE, it can just be another KCM. Wait, I feel like it might needed to be added to the user accounts tab in System Settings, so maybe not a separate KCM.
I say, under the user age line, just add a “I am not in California” checkbox. So whenever the given user account logs in, the DBus endpoint is not created, saving some clock cycles.
How any polititian can think this could apply to random open source developers and community maintained software all over the world sounds like complete insanity to me