Portálunkon korábban már részletes cikkben foglalkoztunk azzal, hogy Colorado állam után több amerikai államban is megjelentek az operációs rendszer szintű életkor-ellenőrzést célzó törvényjavaslatok, Brazíliában pedig egy hasonló szabályozás 2026. március 17-én hatályba is lépett. Reagálva a törvénytervezetekre, a systemd fejlesztői két héttel ezelőtt beküldtek egy pull requestet, amely a userdb formátumot egy birthDate mezővel egészíti ki, így a felhasználó születési dátuma rendszeroldali adatként tárolható. A fejlesztés azért érdemel figyelmet, mert a jogalkotási viták egyik központi kérdése éppen az, milyen módon kaphatnak az alkalmazások életkorhoz kötött információt magától az operációs rendszertől. A mostani módosítás önmagában még nem jelent közvetlen korhatár-ellenőrzést, de jól látható belőle, hogy a Linuxos rendszerek fejlesztésében már számolnak az ebből adódó technikai követelményekkel.
Tartalomjegyzék
A systemd módosítás az Amerikai és Brazil jogszabályokhoz igazodik
A benyújtott pull request hátterében a kaliforniai AB 1043 számú törvény áll, amely 2027. január 1-től előírja, hogy az operációs rendszer szolgáltatója a fiók létrehozásakor életkorra vagy születési dátumra vonatkozó adatot kérjen be, az alkalmazások felé pedig ebből csak a szükséges korcsoportos jelzést továbbítsa valós idejű API-n keresztül. A Colorado államban benyújtott SB26-051 számú törvény hasonló irányt követ, mert ott is az operációs rendszerből lekérhető életkori jelzés és a lehető legszűkebb adattovábbítás áll a javaslat középpontjában.
Brazília Digital ECA törvénye 2026. március 17-én már hatályba lépett, mely a digitális szolgáltatók mellett az alkalmazásboltok és az operációs rendszerek számára is előír életkorhoz kapcsolódó adatszolgáltatási kötelezettségeket. Emiatt a brazil szabályozás nem áll távol a kaliforniai és coloradói iránytól, csak szélesebb keretben ír elő adatszolgáltatási kötelezettséget.
A vita még nincs lezárva
A magasabb szintű megoldás a jelek szerint nem közvetlen alkalmazás-hozzáférésre, hanem portalos közvetítésre épülhet. Az xdg-desktop-portal dokumentációja szerint a portálok eleve arra szolgálnak, hogy a sandboxolt alkalmazások szűrt, felügyelt D-Bus interfészen keresztül érjék el a rendszer bizonyos képességeit, az Account portal pedig ma is úgy működik, hogy a felhasználói adatok lekérését egy köztes réteg kezeli. Ezzel párhuzamosan az xdg-desktop-portal fejlesztői oldalán már nyitva van egy „Add parental controls to the Accounts portal” című tervezet, ami arra utal, hogy a születési dátum tárolása és az alkalmazások felé továbbított eredmény szétválhat egymástól, és a felsőbb réteg már csak korcsoportos vagy engedélyező-elutasító választ adhat vissza.
A fejlesztői vita ettől még messze nem lezárt. A systemd hibakövetőjében már megjelent egy külön felvetés is arról, hogy a teljes születési dátum helyett elég lehetne korcsoportot tárolni, mert ez kisebb adatvédelmi terhet jelentene. Közben a levelezőlistás egyeztetésekben az is felmerült, hogy nem minden disztribúció fogja ezt systemd-alapon megoldani: az AccountsService kibővítése és egy külön D-Bus interfész ötlete is előkerült, éppen azért, mert a systemd nélküli rendszereknek más adatforrásra lesz szükségük.
Erős kritikák és nyitott jogi kérdések kísérték a javaslatot
A birthDate mezőt bevezető systemd-pull request nemcsak fejlesztői vitát, hanem kifejezetten kedvezőtlen közösségi fogadtatást is kiváltott. A pull request egy időre reviewed/needs-rework cimkét kapott, vagyis a karbantartók részéről is felmerült, hogy a megoldás átdolgozásra szorul. A technikai kifogások egyik fő témája az volt, hogy a születési dátumot milyen módon kellene érzékeny adatként kezelni: a hozzászólásokban felmerült, hogy elegendő lenne a dumpokból és naplókból kiszűrni, mások viszont ennél szigorúbb kezelést tartottak indokoltnak.
Jeremy Soller, a System76 vezetője az ubuntu-devel levelezőlistán arra hívta fel a figyelmet, hogy a különböző joghatóságok előírásai még módosulhatnak, és ezek akár egymásnak ellentmondó elvárásokat is megfogalmazhatnak, ezért szerinte korai lenne már most egyetlen technikai megoldás mellett elköteleződni. Úgy látja, hogy egy elhamarkodottan kialakított megoldás adatvédelmi aggályokat vethet fel, ráadásul olyan irányba viheti a fejlesztést, amely kizárólag egy adott régió szabályozásához igazodik. A nyitóbejegyzésre érkezett reakciók is ezt mutatják: a poszt 1 pozitív, 37 negatív és 12 értetlenkedő reakciót kapott.
