EU-app voor leeftijdscontrole sluit bepaalde besturingssystemen mogelijk uit
De oplossing die de Europese Unie maakt voor online leeftijdsverificatie krijgt kritiek van ontwikkelaars. Door technische vereisten werkt de app straks mogelijk alleen op een klein aantal goedgekeurde apparaten en besturingssystemen.
De ontwikkelaars zijn kritisch op de Age Verification-app. Daarmee kunnen gebruikers aantonen dat ze ouder zijn dan een bepaalde leeftijd, zonder dat ze hun naam, exacte geboortedatum of legitimatiebewijs hoeven te delen. De oplossing moet bruikbaar worden via verschillende digitale wallets die de Europese Commissie heeft goedgekeurd.
Het probleem is dat hardware-attestation een vereiste is voor de app, zo stelt een beheerder van het project op de GitHub-pagina, schrijft Linuxiac. Hardware-attestation is een proces dat de integriteit en authenticiteit van een apparaat verifieert. Daarvoor moeten besturingssystemen en apparaten wel ondersteuning bieden en dat is niet altijd het geval. Critici stellen dat de app daarom straks afhankelijk is van een klein aantal goedgekeurde apparaten, besturingssystemen en providers.
Nog veel onduidelijk
Hoever de beperkingen daadwerkelijk gaan, is nog maar de vraag. De technische specificaties vereisen dat apps de native cryptografische hardware gebruiken wanneer deze beschikbaar is. Maar strengere controles, zoals rootdetectie, Google Play Integrity en Apple App Attest, zijn niet universeel verplicht gesteld. Of dat een verplichting wordt, hangt af van de individuele partijen die het systeem uitrollen.
Juist dat kan extra gevolgen hebben voor alternatieve besturingssystemen. Een voorbeeld: een privacyvriendelijk alternatief als GrapheneOS ondersteunt wél hardware-attestation, maar komt niet door Google Play Integrity heen. Als dat laatste een strikte eis wordt om de Age Verification-app te gebruiken, werkt hij dus niet op GrapheneOS.
De beheerder van de Age Verification-app zegt op GitHub dat suggesties voor verbeteringen aan de architectuur welkom zijn. Verder benadrukt hij dat het onderwerp binnenkort verder wordt behandeld en dat er nog een beveiligingsbeoordeling wordt gedeeld. Het is niet duidelijk wanneer dat precies gebeurt.
Lees meer
Reacties (178)
“An Age Verification App SHALL rely on the device's native cryptographic hardware. capabilities, such as the Secure Enclave on iOS, or the Trusted Execution Environment (TEE) and Strongbox on Android, when they are available.”
Dit is dus well belangrijk, want hier gaat het om een interpretatie van intentie. Volgens de contributor van de repository(manecke), betekent dit dat het moet, echter wordt het door andere users en ik kan het zeker ook zien bedoelt dat het alleen de eis stelt als het beschikbaar is, maar zo niet dan maakt het niet uit. Hier wordt later in de thread ook nog op gezegd dat er blijkbaar (?) een discussie komt om de eisen verder te definiëren, dit wordt ook in het artikel genoteerd
Hiernaast is het probleem niet zozeer hardware attestation, maar hoe het wordt gedaan. De tegen druk is namelijk dat het op dit moment Google Play Integrity gebruikt, dit is een Google API die wordt gebruikt, en dus checkt het google’s lijst van approved sources wanneer het checkt, dit is ook wat veel banking apps bijvoorbeeld gebruiken.
Echter is het niet de enige manier, Android heeft namelijk Hardware Attestation API(1) het probleem wat daarmee komt is dat er een lijst moet zijn van approved keys, en wat ook well correct naar wordt gewezen is ja je kan hier GrapheneOS aan toevoegen, maar dan is het Android en graphene, is het niet open. Dus dan moet je gaan kijken naar hoe je die lijst onderhoudt als we er van uit gaan dat dit een concrete eis is.
Fundementeel is het eigenlijk de vraag “Welke keys vertrouwen we”, en hoe meer keys je hebt hoe meer plekken het fout kan gaan, dit zien we bijvoorbeeld met Widevine L1 waar het soms voorkomt dat bepaalde boxen een TEE vulnerability hebben waardoor de keys leaked kunnen worden, en deze boxen worden dan vaak van de trusted lijst gehaald waardoor hij niet meer voor L1 kan worden gebruikt
En natuurlijk is het de vraag van keuze vrijheid, want zoiezo werken deze attestation methodes niet wanneer een device rooted is. Maar die discussie zal ik hier niet in gaan. Maar ik denk dat het dus well belangrijk te noteren is dat het niet zozeer gaat om hardware attestation, maar hoe het wordt gedaan
[Reactie gewijzigd door Stetsed op 3 augustus 2026 15:44]
Ik heb nooit begrepen waarom die lijst zo lastig is.Echter is het niet de enige manier, Android heeft namelijk Hardware Attestation API(1) het probleem wat daarmee komt is dat er een lijst moet zijn van approved keys, en wat ook well correct naar wordt gewezen is ja je kan hier GrapheneOS aan toevoegen, maar dan is het Android en graphene, is het niet open. Dus dan moet je gaan kijken naar hoe je die lijst onderhoudt als we er van uit gaan dat dit een concrete eis is.
SSL/TLS is uiteindelijk ook gewoon een handmatige lijst certifcaat(boeren) die we vertrouwen.
Maar ik vind eigenlijk ook dat Google geforceerd moet worden dat API proces open te breken en dat partijen als Graphene zich daar ook gewoon moeten kunnen aanmelden en dat je daar zoals nu het geval dus niet alleen maar tussen komt als je telefoons maakt.
Ik snap eigenlijk niet dat de EU daar nog niet over is gestruikeld.
[Reactie gewijzigd door Polderviking op 3 augustus 2026 16:41]
Voor SSL bestaan deze certificaten niet om vertrouwen te garanderen vanuit de user kant(mTLS even buiten de discussie, die voegt dus ook heel wat dingen toe om dit te verbeteren), daar zijn ze eigenlijk redelijk slecht voor in design, maar om te garanderen dat de server toegang heeft tot een bepaald stuk infrastructuur die tot een hoog genoeg niveau her vertrouwen geeft dat zij de echte zijn. Maar als die certificate leaks is het alleen hun probleem, het heeft geen impact op andere websites.
Het probleem met TEE/Play Integrity en zo voort is dat als een device compromised wordt, het overal kan worden gebruikt om fake checks door te laten gaan, dat is bijvoorbeeld wat Widevine TEE L1 keys direct voor worden gebruikt. Kort opgesomd als een user side certificate toegankelijk wordt, kan het overal worden gebruikt, als een server side certificate compromised wordt, is dat alleen op die website.
Nou laat me duidelijk zijn dat dit bij vere van niet een onoplosbaar probleem is, en ik denk ook niet dat de suggestie “Forceer Google om het open te maken” een goede keuze is omdat ik helemaal niet denk dat Google deze macht moet hebben, ik will helemaal niet dat dit een lijst van Google is. Net zoals dat de global trust root voor SSL niet van een enkel bedrijf moet zijn.
[Reactie gewijzigd door Stetsed op 3 augustus 2026 16:46]
Ik zeg dat ook meer vanuit het idee dat het me makkelijker lijkt om dat proces open te maken dan Google helemaal te van iets van attestation buiten te sluiten.
Het is ook anders aangezien er meer aanbieders zijn van https root certificaten dan 1 En tls heeft ook simpelere ambities . Tls probeert alleen te bewijzen wie het is, niet iets over de inhoud van de webpagina
[Reactie gewijzigd door Niema op 3 augustus 2026 21:10]
Niet eens perse. Je eigen CA werkt ook. Of self-signed. Er is niet inherent onveiliger aan een 'niet vertrouwd' certificaat gebruiken. Wat veel en veel belangrijker is zijn de ciphers en lengtes.SSL/TLS is uiteindelijk ook gewoon een handmatige lijst certifcaat(boeren) die we vertrouwen.
die vertrouwde lijst was wat Certificaat boeren lang een verdienmodel gaf.
SHALL (Should have) is een requirement die niet op dit moment hoeft voor de huidige oplevering en er kan ook een andere manier zijn waarop er aan de vereiste voldaan kan worden, in dat geval mag het worden doorgeschoven naar een toekomstige release.
Dus het is vrij duidelijk dat het niet een harde vereiste is dat de requirement specifiek op die manier wordt geïmplementeerd. Het kan namelijk anders en beter.
De S in moscow staat voor should.SHALL (Should have) is een requirement die niet op dit moment hoeft voor de huidige oplevering en er kan ook een andere manier zijn waarop er aan de vereiste voldaan kan worden, in dat geval mag het worden doorgeschoven naar een toekomstige release.
Must, should, could, would.
Shall is geen standaard, maar een synoniem voor must.
In het Nederlands is dit het verschil tussen zou moeten en zal moeten. Die laatste is gewoon “dit moet”.
Ik ben ervan overtuigd dat deze huidige implementatie in strijd is met de vereiste om alternatieve App stores een kans te geven. En tegelijk onderdrukt het de concurrentie op OS vlak.
Des te gekker dus als de EC die leeftijdsverificatie op deze manier toe zou staan.
1. Website vraagt om bepaalde gegevens
2. Hiervoor wordt via een een tussen verbinding een token request gegeven
3. Jij logt in op jouw portaal, en geeft toestemming voor de opgevraagde gegevens
4. Er wordt een token teruggegeven
5. De website ontvangt de token met de benodigde gegevens.
Het is prima mogelijk om gegevens door te geven zonder dat de overheid weet door wie en waarom de gegevens gebruikt worden.
Leeftijds verificatie en privacy kunnen niet gecombineerd worden, wat je ook verzint. Het is theoretisch onmogelijk.Om je leeftijd te bewijzen moet je identiteit bekend zijn, dus kan van privacy geen sprake zijn. Ja, je kan allerlei ingewikkelde constructies bedenken waardoor je het privacy probleem van de overheid naar tussenpersonen (portalen) verplaatst. Of dat de data van meerdere partijen nodig is om achter je identiteit te komen. Maar de basis blijft hetzelfde, leeftijdsverificatie betekent privacy opgeven.
Het enige wat de overheid weet is dat jij een certificaat hebt gevraagd waarop staat dat je 18+ bent en het enige wat de server van website X weet, is dat als de wiskunde klopt de overheid garandeert dat jij 18+ bent.
De technologie is op zich geen probleem, wel hoe we kunnen verifiëren dat die effectief correct geïmplementeerd wordt.
Dan weet het portaal helemaal niets. En dat moet ook de insteek zijn van zoiets.
Stel, je wilt inloggen, de site geeft jou een nonce/token, dan doe jij een request bij de overheid om deze nonce als geaccepteerd te publiceren (leeftijd ok, zeg 16+ categorie of 18+) vervolgens broadcast de overheid een continue lijst van geaccepteerde nonces per categorie, de site waar je inlogt luistert naar deze continue stroom en zoekt een match met de nonce die het jou stuurde binnen bepaald tijdsframe. Er is dan geen 1 op 1 communicatie met de site en de overheid, die weten nooit welke nonce bij welke site hoort...
Maar... is dit ergens kwetsbaar? Kan je met die publieke lijst logins kapen? Ik denk het niet want het is alleen een extra vereiste bij login. Kan de client dit scammen? Nee volgens mij niet. De site kan het negeren maar dat kan sowieso.
Werkt dit niet gewoon goed zonder enige privacyschending of benodigde trusted platform?
Ja ok een zwakte is wel als het stil is, en jij en de site zijn de enige... maar realistisch komt dat niet voor bij grote platformen.
Side note, waarom de overheid moet broadcast publiceren is omdat ze anders metadata intern aan jouw token kunnen toevoegen, en zodra een site dat token opvraagt linken ze die info. Je mag dus nooit weten welke sites welke tokens opvragen. Dus iedereen vraagt alles op.
[Reactie gewijzigd door Zoijar op 3 augustus 2026 17:33]
Iets wat er niet is kun je niet loggen, maar ga er maar vanuit dat als het te loggen is, dat ook gebeurt (met een T, ga daar maar over nadenken)
Zit hard te denken, maar kan niet zo bedenken welke.maar allerlei derde organisaties die als dekmantel dienen voor de overheid wel…
Ja, die zullen het vast wel interessant vinden, maar die hebben nog steeds een zoekbevel van de rechter nodig, en die worden in NL iig nog steeds niet uitgedeeld als snoepjes.of de AIVD…
Zeker, maar zie voorlopig nog steeds geen extreemrechtse partij zomaar een 50%+ meerderheid in NL krijgenregimes kunnen veranderen, daar hebben we dagelijks updates over in de krant.
Ja de VS is op het moment echt f..ed-up.Mijn collega in de VS is geboren uit Mexicaanse ouders die geboren zijn in de VS. Toch vreest ze elke dag weer een zeker eng clubje, ook al heeft ze de goede papieren.
Vooral in de VS (maar zeker ook de rest van de wereld) heeft Edward Bernays, letterlijk de vader van Dark Patterns, de ondergrond gelegd voor hoe de bevolking van de VS te manipuleren door de overheid en het bedrijfsleven, hier is kort stukje, en belangrijkste les, uit de 2002 BBC documentaire "The Century of the Self", om te herkennen of iemand je wil manipuleren, een les die mij altijd is bijgebleven.
Het is letterlijk de grondbasis waar MEGA op gebouwd is, de angst creëren voor het wegnemen van vrijheden en welvaart, zo perfect gemanipuleerd door de oligarchen van de VS, en rechtse politici.
Zeker waar, maar het anoniem zijn op het web heeft naast zeker zijn positieve kanten, heeft het zeker ook zo zijn negatieve kanten.Iets wat er niet is kun je niet loggen,
Zeker, maar dat is ook afhankelijk van de wetgeving waarin het wordt ingegoten, het grootste probleem is dat mensen/massa niet de tijd erin steken om op wie te (voorkeur)stemmen, terwijl dat een van de belangrijkste dingen is om de richting van een land te beïnvloeden, en wat bv de AVID wel en niet mag doen met die data.maar ga er maar vanuit dat als het te loggen is, dat ook gebeurt (met een T, ga daar maar over nadenken)
https://nos.nl/artikel/2432715-inlichtingendiensten-moeten-grote-bak-data-burgers-verwijderen
Dus wat is je punt met die link? Ongestraft blijft het niet wanneer het uit komt, dat is letterlijk wat er staat. Bits of Freedom doet gewoon hun burgertaak in een democratie, en het werkt.
De laatste overheid toko waar ik rondliep hadden ze daar echt bijzonder knappe koppen op zitten. Die konden je precies uitleggen hoe/wat/waarom. (en dat deden ze ook met veel passie)
Ja ik weet het. Er zijn apparaten via 4 of 5 g met een vast ip. Maar dat zijn de uitzonderingen. En die gebruik je niet als je de rest van de gegevens gaat spoofen.
Verschil is dat ik geen portaal heb maar ik als broker dien voor een FHE blob die leeftijd kan attesteren. De enige plek waar je leeftijd/paspoort data tijdelijk opgeslagen is is je telefoon.
Ik heb nog geen GrapheneOS telefoon liggen, maar daar wil ik ook nog een apk voor bouwen en testen.
[Reactie gewijzigd door Keyb op 3 augustus 2026 17:37]
Uit het verleden is namelijk al vaker gebleken dat anoniem en geanonimiseerde data toch niet anoniem bleken.
En eenmaal de geest uit de fles dan is het onmogelijk om deze er weer in te krijgen. Met andere woorden als de data op straat ligt en er komt een minder vriendelijke mogendheid aan de macht is er geen houden meer aan. Met als voorbeeld WO2 en de joden vervolging. Prachtig geregistreerd toen er nog niets aan de hand was. Maar later misbruikt voor het opsporen van niet gewenste personen.
De European Data Protection Board omschrijft sociale media voor de AVG als "onlineplatforms waarop netwerken en gemeenschappen van gebruikers ontstaan en waar gebruikers informatie en content met elkaar delen". Daar voldoet een forum gewoon aan.
Ik vond ook een Brits onderzoeksrapport die het zelfs letterlijk zegt:
Het ECDC hanteert eveneens een functionele definitie: online omgevingen waar interactie een hoofddoel is. Ik weet niet of je wel eens op GoT bent geweest, maar... ;-)"social media such as social network sites, blogs, wikis, and online discussion forums."
Je kunt dus prima zeggen dat een forum geen modern social-networking platform zoals Facebook is. Maar zeggen dat een forum daarom geen sociale media is, vind ik vooral een te beperkte definitie achteraf.
Het ging toch over het beschermen van kinderen. Volgens mij weten we echt wel welke sites we bedoelen met social media. Voor Tweakers hoeven we echt geen id check in te voeren.
De vraag is alleen of de wetgever dat ook zo ziet, of dat die doorschiet en bang is dat hier op het forum kinderen gepest of gegroomed worden. De term 'social media' zegt niks over algoritmes of moderatie, het gaat over 'social'. Onder 'sociaal gedrag' kun je veel schuiven, inclusief flinke stukken van Tweakers.Volgens mij weten we echt wel welke sites we bedoelen met social media.
Ik ben het op zich met je eens, maar zo zal het wettelijk nooit gedefinieerd worden.Tweakers is geen sociale media, dat is een nieuwssite. Ik hoop dat je het verschil kan zien tussen een platform wat gemaakt is om zoveel mogelijk gebruikersreacties/interacties uit te lokken ...
Ik maak me zorgen dat dit soort regels gaan gelden voor alle sites waar je berichten of andere "user generated content" kan achterlaten. Op al die plekken zouden immers enge mensen kunnen komen om kinderen te lokken of terroristen te recruteren of zo iets. Dan blijft er niet veel van het open internet over.
Het gaat volgens mij niet om de bank-app zelf.Waarom? De bank weet toch alles al.
Het gaat er om dat die bank-app mogelijk weigert te starten als je app installeert op een ander OS, zoals een custom ROM, of wanneer je apps installeert uit een andere bron dan de Google/Apple appstore. Dat betekent dus ook dat je niks meer kan doen om jezelf te beschermen als Google wil meekijken. Als je zelf de ongewenste software van Google verwijdert dan kom je niet meer door de "integrity"-check heen en kun je dus niet bankieren.
website a vraagt aan broker b (die jou kent, bijvoorbeeld je bank) of je 18 jaar of ouder bent. Daarom komt alleen een true of false terug. De website zal dat loggen. De broker hoeft dat niet eens te doen. Je privacy is dan expliciet geborgd. (zolang je 't via een betrouwbare broker doet, en niet facebook oid)
Vrijelijk gebruiken, aanpassen en distribueren. Hoe definieer jij eigenaarschap?
Daaronder valt het recht van een eigenaar om code te verspreiden onder een licentie met meer restricties. Dat recht hebben licentiehouders op code onder de GPL bijvoorbeeld niet. Dit verschilt enorm tussen verschillende FOSS licenties.This legal entitlement generally enables its holder to exercise exclusive rights of use in relation to the subject matter of the IP.
Het vervelende is dat die wetten in theorie niet conflicteren, alleen in praktijk wel.Je mag wel verwachten dat de EU-commissarissen met elkaar praten en geen tegenstrijdige wetgeving pushen. We hebben maar één EU-commissie en één EU-parlement.
In de wet staat dan bv dat software moet voldoen aan ISO123456. In praktijk zijn er twee bedrijven die een applicatie heben die voldoet aan ISO123456, namelijk Google en MS, want de eisen zijn zo streng dat niemand er aan kan voldoen als je geen miljard over hebt om een leger juristen te onderhouden om al het papierwerk in te vullen.
Ik hoop toch niet dat er straks in dit hele plan geen ruimte is voor open source alternatieven.
Ik snap niet dat dit +2 krijgt, want het raakt kant noch wal.
Het gaat om het verschil tussen het voor jou beschermen en het tegen jou beschermen, ondanks dat je in beide gevallen de rechtmatige gebruiker bent.
[Reactie gewijzigd door AnonymousGerbil op 3 augustus 2026 18:30]
Succes ook om je ouders overstag te laten gaan en de huiselijke hardware van nieuwe OS’en te laten voorzien.
Of anders gezegd, is dit niet een beetje het zoeken van een probleem bij een eventueel bij elkaar gelobbyde oplossing?
Het begint steeds meer een trojaans paard te lijken om vrije software/hardware vrijheid de das om te doen.
Dat is het verkeerde perspectief.Integriteit en authenticiteit van mijn hardware is nogal een dingetje. Ik maak toch zeker zelf wel uit of mijn hardware authentiek is? Hoezo heeft een of andere softwareleverancier uit een ver buitenland waar ik helemaal niets mee te maken wens te hebben daar een stem in?
Het gaat Google er niet om of ik mijn hardware vertrouw, maar dat Google en haar klanten er op kunnen vertrouwen dat ik niks heb veranderd. Dat maakt het makkelijker om adblockers en andere ongewenste software te blokkeren.
Het is ook vrij aan Google (of andere organisatie/bedrijven), om bepaalde features van hun software niet te leveren op die hardware. De meeste bankapplicaties doen ook een root/hardware check zodat ze niet draaien op geroote of gemodificeerde telefoons.
Hetzelfde zie je bijv. terug in de game wereld: Het modden van consoles is in principe legaal, maar de gamebedrijven staan bij een gemodificeerd apparaat ook in hun recht om je van hun (online) diensten te weren, omdat ze dan niet meer kunnen voorspellen wat de hardware doet. Ze mogen je apparaat alleen niet "remote bricken" o.i.d.
Het interessante is wel dat de reden voor de check dit keer andersom is dan bij bijv. bank apps.
Bank apps doen de check om de gebruiker data te beschermen. In geval van de leeftijdscheck wordt de check gedaan om het systeem te beschermen tegen gebruikers die de boel willen omzeilen.
[Reactie gewijzigd door gamefreakin op 3 augustus 2026 16:27]
Wikipedia: Zero-knowledge proof
[Reactie gewijzigd door ZpAz op 3 augustus 2026 15:42]
Wikipedia: Homomorphic encryption
[Reactie gewijzigd door Keyb op 3 augustus 2026 16:14]
Om te kunnen reageren moet je ingelogd zijn
:strip_icc():strip_exif()/u/1434986/crop649350276f23c_cropped.jpg?f=community)
/u/459815/crop5e17a83fc69b7.png?f=community)
:strip_icc():strip_exif()/u/35767/images.jpg?f=community)
/u/388658/crop68b98a9751c48_cropped.png?f=community)
:strip_exif()/u/54579/Static.gif?f=community)
/u/233472/crop5f09644438e2f_cropped.png?f=community)
:strip_icc():strip_exif()/u/436366/crop6984d346ca1a5_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/225583/crop5db1b1fd1ec4a_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/784933/crop5e25fe421af5a_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/411101/crop636bd3ebad62b_cropped.jpg?f=community)
/u/228830/crop5f12f640b47c9_cropped.png?f=community)
:strip_icc():strip_exif()/u/189143/crop5db4a293bb467_cropped.jpeg?f=community)
/u/1741088/crop636b6e3488036_cropped.png?f=community)
/u/53893/impAvat.png?f=community)
:strip_icc():strip_exif()/u/489983/crop5db33928bbeea_cropped.jpeg?f=community)
/u/152942/crop687206d7bca78.png?f=community)
/u/954149/crop5984ccfcadb91.png?f=community)
:strip_icc():strip_exif()/u/79614/Family-Guy-Victory-is-Ours.jpg?f=community)
:strip_icc():strip_exif()/u/90301/crop57d02ccab5f24.jpeg?f=community)
:strip_icc():strip_exif()/u/20623/crop5df25c1e02352_cropped.jpeg?f=community)
/u/506811/Freebsd_logo_60.png?f=community)
/u/2762/crop6086aefd668e4.png?f=community)
:strip_icc():strip_exif()/u/621125/crop65cd0fde312bc_cropped.jpg?f=community)
:strip_exif()/u/295799/cryava.gif?f=community)
/u/1906/crop5dfd46928e003.png?f=community)
/u/94596/crop643fb12fd4e6d.png?f=community)
:strip_icc():strip_exif()/u/1325/crop574b219f4ba94_cropped.jpeg?f=community)
/u/155722/Looneytunes.png?f=community)