Google, Apple en Cloudflare luiden einde captcha's in met Private Access Tokens

Met de komst van Private Access Tokens in de bèta's van iOS 16 en macOS Ventura is het einde van captcha's in zicht. Websites gaan de tool om je te verifiëren door op plaatjes te klikken vervangen door een systeem van tokens.

Een checkbox met de tekst 'I'm not a robot' en een verzoek om op alle plaatjes te klikken met bussen erop: captcha's gaan uit van wantrouwen. Je bent een robot totdat je bewijst dat het niet zo is. Gebruiksvriendelijk zijn ze ook al niet. Captcha's invullen kost bovendien onnodig tijd. Er zijn dus genoeg redenen om er vanaf te willen.

Sites willen echter nog steeds weten of hun bezoekers wel mensen zijn. Immers, een site alleen serveren aan bots is lang niet zo waardevol. Verifiëren dat bezoekers mensen zijn, vermindert de aanwezigheid van spambots en houdt aanvallen van bots tegen. Captcha's bestaan dus niet voor niets, maar met het nieuwe systeem van tokens is dat wellicht verleden tijd.

Tokens voor verificatie

Het systeem heet Private Access Tokens. De basis daarvoor is een standaard van de Internet Engineering Task Force met de naam Privacy Pass. Dat is een systeem voor het maken en verifiëren van tokens op een manier die niet herleidbaar is naar apparaten of persoonsgegevens. Dat laatste is een belangrijk detail, omdat het anders een tool kan zijn voor fingerprinting, het online volgen van apparaten op basis van allerlei data.

Het systeem van Private Access Tokens werkt met verschillende partijen. Het apparaat natuurlijk, maar ook de 'Attester', die checkt of een apparaat echt is, de 'Issuer', die het token verstrekt, en de 'Origin', de server die om het token vraagt.

Cloudflare

Als een apparaat op een site komt die vraagt om een verificatie, bijvoorbeeld bij het inloggen, stuurt de server van die site een verzoek naar het apparaat. Dat neemt contact op met de Attester, die gegevens checkt. Dat kan bijvoorbeeld het IMEI-nummer van een telefoon zijn. Vaak zal die Attester de maker van het besturingssysteem zijn.

De Attester is de partij die wordt vertrouwd door beide partijen: het apparaat en de Issuer. Als de Attester het verzoek goedkeurt, stuurt hij het verzoek door naar de Issuer. Die kan het token vervolgens genereren en naar het apparaat sturen. Vervolgens stuurt het apparaat het token door naar de server.

Daarmee kan de server van de site dus alleen zien dat het een goed gegenereerd token is, maar weet het niets over het apparaat of de gebruiker. Dat is ook de bedoeling. Zoals in elk systeem zijn er wel wat zwakkere schakels. Zo zijn er dus drie of vier partijen nodig om het systeem mogelijk te maken en die moeten elkaar vertrouwen. Als een van de servers platligt, werkt het niet meer. Is iCloud onbereikbaar? Dan zul je dus op een iPhone ineens weer captcha's moeten invullen.

Hoe het in de praktijk werkt

Fastly: Private Access Tokens

De eerste golf van apparaten die werken met Private Access Token-ondersteuning komt dit najaar. Apple zet de techniek in iOS 16, iPadOS 16 en macOS Ventura, bleek op WWDC eerder deze maand. Daarmee zijn er in een klap naar schatting honderden miljoenen apparaten wereldwijd voor het einde van het jaar. In de bèta is het een functie die standaard aan staat, vermoedelijk staat het ook standaard aan bij de release dit najaar.

Daarmee is er dus al een aantal apparaten dat ermee gaat werken, maar ook heel veel sites kunnen het toepassen. Cloudflare gaat het ondersteunen en ook Fastly gaat ermee aan de slag. Daarmee kunnen veel websitebeheerders in een klap captcha's voor een deel van de gebruikers uitfaseren.

Niet iedereen heeft echter een Apple-apparaat. Cloudflare noemt specifiek dat Google ook betrokken is geweest bij de ontwikkeling, dus een snelle ondersteuning van Android lijkt ook voor de hand te liggen. Er is nog geen aanwijzing dat het in Android 13 zit, de eerstvolgende versie, die deze zomer uitkomt. Alle functies en api's zitten er al in vanwege de naderende release, dus die ondersteuning lijkt niet alsnog te komen. Google heeft met Chrome OS ook een desktopbesturingssysteem waar Private Access Tokens in kunnen komen. De grote vraag is of Microsoft ook aan boord springt met Windows. Daar is vooralsnog niets over bekend.

Tot slot

Private Access Tokens lijken er, door de ondersteuning van Apple en Cloudflare, al redelijk snel te komen. Bij de meeste technologieën zitten er jaren tussen de aankondiging en de implementatie. Ook nu kan het weer even duren voordat captcha's tot het verleden behoren. Er is nog niets bekend over ondersteuning voor Windows, Chrome OS en Android.

Bovendien is het de vraag of dit als open oplossing kan dienen voor bijvoorbeeld Linux-distro's. Het introduceert een vertrouwde tussenpartij in de vorm van de Attester die het apparaat moet verifiëren. Het is onbekend hoe en onder welke voorwaarden partijen Attesters kunnen worden. Dat maakt dit in potentie een gesloten systeem, waarmee grote partijen captcha's kunnen omzeilen en kleine partijen het nakijken hebben. Daardoor is het de vraag hoe dit op termijn zal uitpakken.

Reacties (55)

[CAPSLOCK2000]

Het is onbekend hoe en onder welke voorwaarden partijen Attesters kunnen worden. Dat maakt dit in potentie een gesloten systeem, waarmee grote partijen captcha's kunnen omzeilen en kleine partijen het nakijken hebben.

Dat is wat mij betreft de doodsteek voor deze techniek tot hier een goed antwoord op is en volgens mij is dat er niet.

Het systeem vereist dat de deelnemende partijen elkaar vertrouwen. Dan kom je automatisch op het terrein van de grote bedrijven en overheden. Ik vrees dat het een grote pesterij wordt voor mensen die niet braaf hun geld & gegevens afstaan aan de grote bedrijven. Je wordt nu al gepest met extra captcha's als je probeert je privacy te beschermen door javascript en trackers te blokkeren.

de Attester, die gegevens checkt. Dat kan bijvoorbeeld het IMEI-nummer van een telefoon zijn.

Hoe zie je aan een imei-nummer of de telefoon door een mens wordt gebruikt of niet? Of gaan ze die imei-nummers gebruiken om 'overtreders' te herkennen of te koppelen aan gebruikers? Dan wordt er dus een database met imei-nummers aangelegd. Dat lijkt mijn nogal een grote privacyschending, ook als het de bedoeling is om alleen "overtreders" bij te houden. Wettelijk gezien doe je niks verkeerd en ook al was dat wel zo dan is het nog niet aan de websites (of attesters) om zelf dit soort lijsten bij te gaan houden.

Ik heb nog wel een beetje hoop dat ze bij IETF weten waar ze mee bezig zijn maar ik zie het niet.

[Reactie gewijzigd door CAPSLOCK2000 op 25 juli 2024 17:54]

[GekkePrutser]

Het systeem vereist dat de deelnemende partijen elkaar vertrouwen. Dan kom je automatisch op het terrein van de grote bedrijven en overheden. Ik vrees dat het een grote pesterij wordt voor mensen die niet braaf hun geld & gegevens afstaan aan de grote bedrijven. Je wordt nu al gepest met extra captcha's als je probeert je privacy te beschermen door javascript en trackers te blokkeren.

Yup... Een dergelijk fenomeen is ook het "Sign in with Google/Facebook/Apple/Microsoft" enz. En ook diensten als iDIN of IRMA. En ja, IRMA is daarvan veruit de meest privacybewuste, maar het verlaagt niettemin de drempel voor een website om ID te vragen van gebruikers. Het opsturen van kopie ID is een enorme ingreep en zal veel mensen doen afhaken. Hoe makkelijker en privacyvriendelijker het kan gebeuren, hoe vaker het zal gebeuren. Met als gevolg een minder anoniem internet.

Ik heb een tijd geleden nog een hele discussie gehad met de makers van de app PushBullet omdat die Google en Facebook als enige inlogmethode bieden. Gewoon een account aanmaken is er gewoon niet bij. Ongetwijfeld zullen ze hier ook qua datamining op vooruit gaan. Hun reactie was dat ik me daar niet druk over moest maken want ik had toch een Google account nodig voor Android.

Echter is dit absoluut niet waar. Pushberichten op Android werken ook als je niet ingelogd bent op een google play account, en je hebt ook alternatieven als MicroG. Niet perfect voor de privacy maar je onthoudt Google een heleboel data die ze anders wel hadden gehad.

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 17:54]

[CAPSLOCK2000]

Echter is dit absoluut niet waar. Pushberichten op Android werken ook als je niet ingelogd bent op een google play account, en je hebt ook alternatieven als MicroG. Niet perfect voor de privacy maar je onthoudt Google een heleboel data die ze anders wel hadden gehad.

En push berichten zijn ook geen eerste levensbehoefte.

Ik heb 2 telefoons met LineageOS en eentje met "gewoon" Google maar ik heb er toch echt nooit een google account voor hoeven aanmaken. Mensen veroordelen zichzelf door te geloven dat Google/Microsoft/Apple/Facebook onvermijdelijk zijn waardoor ze het niet eens proberen en al hun data overhandigen.

[GekkePrutser]

Nouja, pushberichten zijn wel de achilleshiel van de mobiele ervaring tegenwoordig. En een centrale push dienst is belangrijk voor de accu efficientie. Als elke app constant loopt te pollen kost dat echt veel accu.

Een deel hiervan is trouwens dat Google het zo vanzelfsprekend maakt om een account aan te maken. Je moet echt moeite doen om het niet te doen. Veel mensen die ik ken maken ook een samsung account aan omdat ze denken dat dat ook moet.

Dit is ook wel iets dat misschien juridisch aangepakt kan worden net zoals de cookies maar ik zie het niet zo 1-2-3 gebeuren. Er wordt lichte druk uitgeoefend op Apple om het platform te openen voor andere app stores (wat ze zelfs dan maar op hetzelfde niveau als Android brengt) maar ook dat zie ik er niet gauw doorheen komen.

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 17:54]

[Werelds]

Ongetwijfeld zullen ze hier ook qua datamining op vooruit gaan.

Ik weet niet om welke gegevens Pushbullet vraagt, maar dit dus juist niet. Met minimale rechten krijg je (als ontwikkelaar) niet eens een email adres, enkel een ID. Zelfs met de rechten voor een basis profiel (openid, email, profile) is het niet meer dan jij zelf in zou vullen in enig registratie formulier (dat je daar wellicht valse informatie in zou vullen is een ander verhaal). Je contacten (Google) of vrienden (Facebook) lijst is dan nog steeds niet toegankelijk, laat staan enige activiteit. Dat is juist het punt van OAuth2: de consumerende partij (de website waarbij je in logt) krijgt enkel toegang tot de informatie waar jij ze ook toegang voor verleent.

Anderzijds weten Google en Facebook uiteraard wél dat jij in elk geval op de "sign-in" knop op die website hebt geklikt.

Dat sites met die knoppen op hun sites ineens al jouw data zouden kunnen zien is voor mij een bijzonder irritante misconceptie die ik constant herhaald zie worden. Het is simpelweg niet waar, zolang je tenminste geen toegang verleend tot de uitgebreide gegevens. En verreweg de meeste sites vragen daar ook niet naar; op het moment dat jij een site ziet die om toegang tot je contacten of vrienden vraagt moet je inderdaad meteen vraagtekens zetten bij hetgeen ze willen doen.

[Reactie gewijzigd door Werelds op 25 juli 2024 17:54]

[GekkePrutser]

Aha, ik gebruik dit soort diensten natuurlijk bij voorbaat niet. Juist vanwege de tracking die vanwege Google e.d. zelf uitgaat. Maar ik heb bij andere mensen die dergelijke diensten wel gebruiken wel gezien dat er om meer gevraagd werd dan alleen een ID. Dan kwam er zo'n toestemmingsscherm waar mensen gewoon rakeloos op klikken. En als je het niet doet dan kom je er meestal gewoon niet in.

Qua email geef ik meestal een alias op zodat ik kan achterhalen welke site mijn adres lekt aan spammers. En dat kan op die manier natuurlijk ook niet.

Maar zoals ik zei wist ik dat dus niet. Zou Google ze wel een kickback geven als ze zo'n inlogmethode aanbieden? Bijvoorbeeld korting op google analytics of ads ofzo.

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 17:54]

[Werelds]

Even vooraf: mijn reactie was niet specifiek op jou bedoeld

Het is gewoon iets wat ik heel vaak zie en als ontwikkelaar aan de non-Google/FB/etc kant begrijp ik de zorgen wel, maar ze zijn volledig ongegrond, mits je als gebruiker een klein beetje op let.

Maar ik heb bij andere mensen die dergelijke diensten wel gebruiken wel gezien dat er om meer gevraagd werd dan alleen een ID.

Het basis profiel (bij Google) bestaat uit ID, email en "info", waarbij dat laatste tegenwoordig staat voor je naam, maar toen Google+ nog bestond was dat de publieke informatie op je profiel (dus dat was toch al zichtbaar). Als ontwikkelaar krijg je met die scopes ook niet meer dan dat te zien. Je krijgt gewoon een foutmelding als je andere API's aan roept met het token voor die gebruiker.

Sites die meteen bij login om meer vragen zijn inderdaad twijfelachtig (en ik heb even gekeken, Pushbullet vraagt niet om meer dan het basis profiel). Zelfs als ze dat doen, kun je dat altijd achteraf gewoon intrekken en dan blijft de login werken.

Wat Google zelf overigens aan raadt, is dat je als ontwikkelaar pas om verdere rechten vraagt op het moment dat je ze nodig hebt. Dan geef je de gebruiker gewoon een prompt op het moment dat ze bijvoorbeeld op een "importeer mijn contacten" of iets dergelijks klikken en moeten ze dan toestemming geven. Ze zijn er intern mee bezig om vrijwel alles buiten het profiel ook niet meer toe te staan bij de initiële sign-in, hopelijk zetten ze dat door.

Overigens moet ik eerlijk toegeven dat ik zelf nog geen site tegen ben gekomen die om meer vraagt dan logisch is.

Dan kwam er zo'n toestemmingsscherm waar mensen gewoon rakeloos op klikken. En als je het niet doet dan kom je er meestal gewoon niet in.

Klopt, de meeste mensen klikken gewoon "ja". Vandaar dat ze dat wellicht niet meer mogelijk maken. Dat je er niet in komt heeft verder helaas niet zo heel veel met de site of met Google te maken, dat is een principe van OAuth. Je vraagt toestemming om al die dingen en OAuth is ontworpen als alles-of-niets.

Qua email geef ik meestal een alias op zodat ik kan achterhalen welke site mijn adres lekt aan spammers. En dat kan op die manier natuurlijk ook niet.

Dat ligt een beetje aan de site, maar standaard inderdaad niet. Het zou Google niet misstaan om daar zoiets als Apple voor aan te bieden, waarbij dat automatisch gebeurt. [e-mail] of iets dergelijks

Maar zoals ik zei wist ik dat dus niet. Zou Google ze wel een kickback geven als ze zo'n inlogmethode aanbieden? Bijvoorbeeld korting op google analytics of ads ofzo.

Nee, geheel niet

Er is nauwelijks cross-over tussen de Google diensten. Gebruik van GA en/of DFP (de ads) hebben 0,0 invloed op alle andere diensten. Enige cross-over die er is, is dat je sommige diensten eenvoudig kunt integreren met GA, zodat je daar statistieken van ziet.

[Reactie gewijzigd door Werelds op 25 juli 2024 17:54]

[Notlupus]

Eerder de doorsteek voor die kleine partijen die zich toch al moeilijk kunnen beschermen tegen bots ed. Nu gaan mensen weer sneller naar diensten van die grote jongens "want daar heb ik geen last van die irritante CAPTCHA". The rich get richer...

[TheVivaldi]

Ook bij de "grote jongens" krijg ik regelmatig captcha's...

[Notlupus]

Binnenkort blijkbaar niet meer en bij de kleine jongens nog wel want die krijgen niet zomaar die "trusted" status.

[Krystalize]

SSL certificates waren precies hetzelfde. Je moest ze kopen voor een hoop geld van een klein aantal vertrouwde partijen. Alleen dan kreeg je een vertrouwde status van de browser. Met een self-signed versie bleef het toch een niet vertrouwde website.

Echter kwam toen LetsEncrypt met een gratis service voor certificates. Certificates die vertrouwd waren, vanwege de noodzaak hiervoor, maar voornamelijk door de acties van een groep met security researchers die hiervoor pushten.

Als kleine bedrijven hier last van gaan krijgen, is het aan die bedrijven om samen te spannen en een dergelijke service op te zetten. Het issue met security en trust, is het "trust" gedeelte. Dit kost moeite om te vergaren, maar het is duidelijk niet onmogelijk.

PS. Hoe ze de Attester iets gaan laten checken weet ik niet. Maar zo'n IMEI database lijkt me idd onverstandig 😅

[Reactie gewijzigd door Krystalize op 25 juli 2024 17:54]

[CAPSLOCK2000]

SSL certificates waren precies hetzelfde.

Echter kwam toen LetsEncrypt met een gratis service voor certificates. Certificates die vertrouwd waren, vanwege de noodzaak hiervoor, maar voornamelijk door de acties van een groep met security researchers die hiervoor pushten.

Als kleine bedrijven hier last van gaan krijgen, is het aan die bedrijven om samen te spannen en een dergelijke service op te zetten.

Ik vind het geen goed voorbeeld. Weet je door wie LetsEncrypt betaald wordt? OVH, Cisco Systems, Facebook, Google Chrome, Amazon, Bill and Melinda Gates Foundation en nog vele anderen, niet alleen maar grote bedrijven hoor. Maar LetsEncrypt heeft in ieder geval de steun van de gebruikelijke techreuzen.

LetsEncrypt is geen ding van kleine bedrijven die zichzelf hebben verlost. Ik heb niks tegen LetsEncrypt en ben er zelfs fan van maar het is niet geschikt als voorbeeld van waar de grote reuzen het verliezen van een kleine upstart of dat kleine bedrijven een keer niet de speelbal zijn van de grote. Je zou het zelfs om kunnen draaien en zeggen dat het weer een geval is waar de grote techreuzen hun eigen macht versterken ten opzichte van de (veel kleinere) Certificate Authorities en iedereen die een certificaat nodig heeft. Die CA's zijn nog steeds belangrijk maar ze hebben een stuk minder invloed dan een paar jaar geleden.

Als je echt onafhankelijk wil zijn moet je DANE/TLSA gebruiken voor je certificaten. Dan kun je echt een self-signed certificaat gebruiken. In plaats van (het root cert van) een CA gebruik je DNS om het SSL-cert te controleren.

[Krystalize]

Het is toch juist mooi dat een initiatief als LetsEncrypt wordt ondersteund door de techreuzen? Het is nog steeds gratis, en dus voor iedereen beschikbaar.

Over DANE/TLSA, thanks voor de tip gelijk even opgezocht. Maar voor zover ik dat begrijp is het certificaat niets veranderd. Er is enkel nog een extra methode bijgekomen om te verifieeren dat niemand heeft gehannest met het cert. Daarnaast vereist DANE DNSSEC, wat weer leunt op standaard TLS certificaten van dezelfde CAs als voorheen.

[CAPSLOCK2000]

Het is toch juist mooi dat een initiatief als LetsEncrypt wordt ondersteund door de techreuzen? Het is nog steeds gratis, en dus voor iedereen beschikbaar.

Het is zeker mooi maar het is dus geen voorbeeld van kleine bedrijven die samen spannen om hun problemen op te lossen.

Over DANE/TLSA, thanks voor de tip gelijk even opgezocht. Maar voor zover ik dat begrijp is het certificaat niets veranderd. Er is enkel nog een extra methode bijgekomen om te verifieeren dat niemand heeft gehannest met het cert.

Ja en dat is juist, waarom de "maar?". Dat is precies hetzelfde wat LetsEncrypt doet maar dan zonder centrale partij maar juist decentraal. Een self-signed certificaat is niet anders dan eentje van LetsEncrypt of een traditionele CA, het enige verschil zit in de manier waarop je het controleert. Dat is precies het stuk dat DANE vervangt, aan het certificaat zelf veranderd het niks. Je kan ieder certificaat gebruiken, zowel "normale" certificaten als self-signed, voor DANE maakt het niks uit.

Daarnaast vereist DANE DNSSEC, wat weer leunt op standaard TLS certificaten van dezelfde CAs als voorheen.

Dat klopt niet, DNSSEC is onafhankelijk van de TLS CA's.

[Krystalize]

Gaaf! Toch eens dieper gaan kijken naar DANE 🙂

Over LetsEncrypt ben ik het toch niet eens, en misschien overtuigen we elkaar niet, en dat geeft niet. Maar LetsEncrypt is opgezet door een klein groepje security onderzoekers, waaronder collega's van mij. Dat ze gefinancierd worden door de grote bedrijven is iets waar ze hard voor hebben gevochten, en ze uiteindelijk is gelukt.

[CAPSLOCK2000]

Gaaf! Toch eens dieper gaan kijken naar DANE 🙂

Over LetsEncrypt ben ik het toch niet eens, en misschien overtuigen we elkaar niet, en dat geeft niet. Maar LetsEncrypt is opgezet door een klein groepje security onderzoekers, waaronder collega's van mij. Dat ze gefinancierd worden door de grote bedrijven is iets waar ze hard voor hebben gevochten, en ze uiteindelijk is gelukt.

Voor de duidelijheid, ik probeert LetsEncrypt niet aan te vallen. Mjin punt is dat ze succesvol zijn met de steun van de grote techbedrijven. Als die bedrijven zelf een (commerciele) CA hadden gehad of een andere reden om niet mee te willen werken dan was het niet gelukt. Niet alleen vanwege het geld dat ze sponsoren maar vooral vanwege de controle over OS en browsers en daarmee welke SSL-root-certificaten mensen hebben.

Het grote verschil tussen ssl-certs en attestation is dat die grote techbedrijven er nu belang bij hebben om kleine spelers van het veld te houden. Kleine bedrijven kunnen wel zo'n service op zetten, net zoals kleine bedrijven hun eigen CA kunnen opzetten, maar de rest van de wereld deze laten erkennen zal erg lastig zijn als de gebruikelijke grote bedrijven dat niet willen.

[Krystalize]

Helemaal met je eens. Mijn hoop is dan ook dat de kleine bedrijven met of zonder hulp van de groten een gratis attestation service opzetten waar iedereen van gebruik kan maken.

[GekkePrutser]

De vraag is: hoe gaat dit werken met mijn FreeBSD desktop (die mijn dagelijkse machine is)? Als je die tokens helemaal met open source software aan kan maken, dan werkt het niet meer om robots te voorkomen want die kunnen het dan ook gewoon doen. En mijn computer heeft geen imei nummer. Sowieso hebben tablets dat natuurlijk ook niet en zelfs computers met andere OS'en niet.

Ook zal FreeBSD niet zomaar een attester kunnen worden want het hele idee is dat je je systeem compleet kan aanpassen zoals je wil. Geen enkel gesloten stukje of iets dat alleen door de 'leverancier' wordt beheerd. Dat is juist de reden dat ik FreeBSD gebruik. Ik denk niet dat deze werkgroep dat gaat accepteren. Want nogmaals, dan kunnen makers van 'robot' software het ook gebruiken in hun code en dan is het hele concept omzeild.

Op iets als Ubuntu Linux krijg je dat nog wel verkocht aan de gebruikers want die zijn niet zo principieel maar bij FreeBSD staat dat echt haaks op de filosofie, ondanks dat het met een 'goed doel' is gedaan dit keer. Sommige andere Linux distro's ook wel. Zelfs DRM zit er niet op om deze reden waardoor ik geen Netflix enzo kan kijken (maargoed andere bronnen zijn geduldig, fuck DRM...)

Dus de vraag is: krijg ik dan fallback naar een CAPTCHA of kan ik zo'n site helemaal niet meer in? Er moet altijd een manier blijven om het te kunnen gebruiken. Zoals gezegd wordt blijft dat voorlopig wel mogelijk maar het klinkt als een overgangsfase (zoiets krijg je immers ook niet in 1x op alle endpoints geimplementeerd). Ik zou graag zien dat dat vanaf het begin wordt vastgelegd omdat je anders het probleem krijgt van "95% van de gebruikers gebruikt dit nu dus we schaffen de fallback af".

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 17:54]

[blorf]

Ik maak me zorgen om online vrijheid in het algemeen. In het geval van FreeBSD zou ik zeggen, maak een eigen browser(-mod) die doet wat de gebruikers willen zien.
Alleen, als meerdere besturingssystemen dat gaan doen krijgen we straks waarscijnlijk TPM 3.0 die alles gewoon hardwarematig afdwingt waardoor ze alsnog niet meer meedoen.
Bij UEFI/secure boot was dit volgens mij eigenlijk ook de bedoeling, maar dat is gesloopt door de OSS-communities.

[GekkePrutser]

Ik maak me zorgen om online vrijheid in het algemeen.

100% eens. We geven als gemeenschap veel te veel op onder het mom van gemak en 'gratis'.

In het geval van FreeBSD zou ik zeggen, maak een eigen browser(-mod) die doet wat de gebruikers willen zien.

Het probleem is, met dit soort attestation kan dat gewoon niet. Je moet een private sleutel krijgen van ze en die mag je natuurlijk niet open en bloot in je code verwerken. En sowieso ga je die niet krijgen als je niet in de Gartner top 200 staat.

Alleen, als meerdere besturingssystemen dat gaan doen krijgen we straks waarscijnlijk TPM 3.0 die alles gewoon hardwarematig afdwingt waardoor ze alsnog niet meer meedoen.
Bij UEFI/secure boot was dit volgens mij eigenlijk ook de bedoeling, maar dat is gesloopt door de OSS-communities.

Gesloopt ook niet eens echt. Microsoft begon toen net tot inkeer te komen dat ze Linux toch niet zo vreselijk haatten en hebben wat bootloaders ondertekend. Bovendien kan je zelf je eigen sleutels toevoegen.

In dit geval kan dat echter niet. Omdat die niet door je eigen systeem geverifieerd worden maar door de webserver.

[blorf]

"Gesloopt" in de zin van dat het geen effect meer heeft en de industrie er geen brood meer in ziet. Op een nieuw moederbord kun je gewoon weer alles booten wat je wil, als het maar hardware-compatible is. Dat is een korte tijd anders geweest, vlak naar de overstap van BIOS naar UEFI.
Nu verwacht ik eenzelfde poging. Vrij toegankelijke hardware is een doorn in het oog van zowel industrie als politiek. Ik denk dat dit is waar het volledig om draait.

[Reactie gewijzigd door blorf op 25 juli 2024 17:54]

[GekkePrutser]

Is dat zo? Ik heb echt altijd secure boot gewoon uit kunnen zetten. Ook op zakelijke laptops.

De enige uitzonderingen hierin waren ARM spullen (windows RT e.d.) maar dat was sowieso een ander bootproces.

[blorf]

Het kan niet meer door bepaalde commerciele systemen misbruikt worden om concurrentie te dwarsbomen door dinen onmogelijk te maken. Zo ver als een Windows-melding als "Zet secure boot aan voor deze onersteuning" is het gelukkig nooit gekomen, maar het heeft niet veel gescheeld.

[InsomniaC81]

Dus de vraag is: krijg ik dan fallback naar een CAPTCHA of kan ik zo'n site helemaal niet meer in? Er moet altijd een manier blijven om het te kunnen gebruiken

In het artikel staat beschreven dat wanneer 1 van de 3 of 4 schakels niet werkt/bereikbaar is, terug gevallen zal worden op een CAPTCHA. Dit zal dus (naar ik aanneem) ook gelden voor OS-en zoals bijvoorbeeld FreeBSD.

[GekkePrutser]

De rest van die alinea geeft mijn reactie daar al op

Zoals gezegd wordt blijft dat voorlopig wel mogelijk maar het klinkt als een overgangsfase (zoiets krijg je immers ook niet in 1x op alle endpoints geimplementeerd). Ik zou graag zien dat dat vanaf het begin wordt vastgelegd omdat je anders het probleem krijgt van "95% van de gebruikers gebruikt dit nu dus we schaffen de fallback af".

[Blokker_1999]

Dit gaat ongetwijfeld hetzelfde worden als SSL, een keten van vertrouwen waarbij enkele bedrijven gaan bepalen wie te vertrouwen is. En dat is ergens spijtig. Natuurlijk hoeft dit niet te betekenen dat niet vertrouwde systemen niet kunnen aanmelden, het zal hopelijk betekenen dat zij via een andere manier alsnog kunnen bewijzen dat ze mensen zijn, al zal dan wel interactie van de gebruiker noodzakelijk zijn.

[laptopleon]

Er staat nergens dat je een imei moet hebben. Dat kan vaak ook niet. Het belangrijkste principe is dat er een derde partij gevraagd wordt om akkoord.

Dus ja, dat kan – zoals ik het lees – net zo goed een relatief kleine, onbekende partij zijn, als die maar aan de voorwaarden voldoet. Waarom zou dat niet net zoals dat nu bij https met een certificaat kunnen, bijvoorbeeld.

Dus de vraag is: krijg ik dan fallback naar een CAPTCHA of kan ik zo'n site helemaal niet meer in?

Dat wil een dienstverlener, webwinkel etc natuurlijk net zo goed als jij niet. Dat hoeft ook niet want er zijn andere opties. De laatste tijd zie je bijvoorbeeld de variant van inloggen waarbij je geen wachtwoord invult, maar alleen je mailadres (of nickname waarvan het systeem het bijbehorende mailadres al heeft). Vervolgens krijg je een mailtje met een wegwerp-inlog.

OK, nu moet je dat nog knippen/plakken of een link aanklikken, maar ook dat zou je kunnen automatiseren door middel van een standaard protocol.

[biteMark]

Tsja, ik ben bang dat FreeBSD relatief lage prioriteit heeft - het heeft op desktopgebied behoorlijk weinig gebruikers. Maar ik denk dat het antwoord vooral afhangt van Linux: als het daar naartoe komt dan is er vást een ontwikkelaar die de boel port naar FreeBSD

[Weicool]

En wat houdt men tegen om
Oneindig veel van die nieuwe private access tokens te gebruiken?

[Reactie gewijzigd door Weicool op 25 juli 2024 17:54]

[Bouwer21000]

Zo'n token moet op aanvraag gegenereerd en geverifieerd worden en zal voor andere aanmeldingen niet geldig zijn, neem ik aan.

[Weicool]

“ Zover ik kan begrijpen zou het redelijk triviaal moeten zijn voor een bot om een dergelijk token te generen, want het is compleet client side?”

[Krystalize]

Een token is meestal een deel informatie en een deel signature; de hash van de informatie versleuteld met een prive sleutel. Cloudflare (in het voorbeeld) kan de hash alleen ontsleutelen met de juiste publieke sleutel, een van de sleutels die hij vertrouwd.
Dit zorgt ervoor dat, ookal zou het client-side zijn, enkel het programma met toegang tot de prive sleutel een geldig token kan maken. Door gebruik te maken van een TPM/HSM/SecureEnclave kan de prive sleutel beschermd worden.

Ik weet niet of het Private Access Token ook zo werkt, maar er zal een soortgelijk systeem in zitten.

[Weicool]

Niks weerhoudt iemand ervan om een botnet van meerdere attesters in te zetten.

[Krystalize]

De tokens van dat botnet zullen niet worden geaccepteerd omdat ze niet met vertrouwde sleutels zijn ondertekend.

Wat zou zo'n botnet moeten uithalen?

[Weicool]

Hoe dom kun je zijn om niet te zien dat het hele technische ontwerp helemaal geen onderscheid meer maakt tussen mens of bot: dit haalt het hele doel van een captcha eronder uit.

[Krystalize]

Woah rustig. Ik vroeg enkel wat je bedoelde met zo'n botnet.

Ik claim niet dat het nog steeds onderscheid meer maakt tussen mens en bot, dat is wat ze opzij moesten zetten om de captcha eruit te halen. Het doel is nog steeds wel om brede inzetbaarheid tegen te gaan. Op attester niveau kan je hier een stokje voor steken. Daarnaast was blijkbaar een legitiem gekochte telefoon bijvoorbeeld wel genoeg.

[etiennebruines]

Hier is het aan de "Attester" om misbruik (veel meer tokens genereren dan gebruikelijk) te herkennen en dan de tokens niet meer te verifiëren.

De "Origin" vertrouwt de "Attester" dus ermee, dat deze misbruik herkent en tegenhoudt.

[Weicool]

Achilleshiel: een bot kan nu gewoon een botnet van meerdere attesters inzetten in plaats van een groep mensen die de captchas oplossen

[Reactie gewijzigd door Weicool op 25 juli 2024 17:54]

[TheVivaldi]

Dus als je geen iOS of Android gebruikt ben je de sjaak, tenzij jouw systeem toevallig gaat samenwerken met zo'n tussenpersoon? Vind dat wel wat vrijheidsberovend, eerlijk gezegd.

[Gubbel]

Van wat ik begrijp, val je dan gewoon terug op de Captcha en verandert er voor jou niets. Heeft niets te maken met vrijheidsberoving.

[TheVivaldi]

Voor nu ja, maar hoelang blijven captcha's nog ondersteund als dit nieuwe systeem eenmaal functioneert?

[Gubbel]

Tja dat is de vraag. Tot hoe lang kun je een benzine-auto blijven gebruiken terwijl je wellicht geen geld hebt een elektrische te kopen?

We hebben alleen info voor nu, dus we kunnen ook alleen praten over nu en voor nu werkt het gewoon. Er wordt mijns inziens veel te veel gespeculeerd over de toekomst.

Ik zeg altijd: Maak je niet druk over wat misschien nooit zal komen.

[GekkePrutser]

Vind ik niet, je moet dit soort dingen vroeg in de kiem smoren, anders sta je straks gewoon geconfonteerd met de status quo die al helemaal vastgelegd is.

[Daoka]

Wat ik me vooral afvraag is hoe herkennen ze valse informatie? Van wat ik lees kan IMEI ook vervalst worden.

[corset]

mja.. dat is een beetje als roepen "Maar 3D printers zijn evil want je kan er ook wapens mee maken".

Een IMEI vervalsen is niet zo even gedaan, natuurlijk gaan er allemaal sprookjes rond van de notoire toetsenbord ridders die zeggen dat ze het allemaal wel even kunnen doen en dat het allemaal het makkelijkste ooit is. IMEI spoofing is bijvoorbeeld mogelijk op een rooted Android telefoon. Echter is dit steeds vaker te traceren en tegen te gaan.

Maar laten we vooral even realistisch kijken, hoeveel consumenten (dus niet bovengenoemde toetsenbord ridders, en niet de mensen van Tweakers) rooten hun telefoon? Die gaan dat niet doen, mensen vergeten verdomd snel dat 95+% van de gebruikers at Henk, Greta, Tina en Anniek bestaat die allemaal gewoon hun telefoon normaal gebruiken.

Dat er misschien een klein groepje misbruik van gaat maken is kut, maar als je dit niet doet vinden ze wel een andere manier.

[GekkePrutser]

IMEIs staan niet wereldwijd getraceerd dus zodra je die spooft, kan je er gewoon een bedenken, het hoeft niet eens echt ooit op een apparaat gebruikt te zijn.

En vergeet niet, dit is een techniek om spelers tegen te gaan die veel geld hebben. Webscraping is big business. Hoe moeilijk ook is, het wordt wel gedaan. Ik vind het wel een legitiem argument.

[Daoka]

Ik help zelf genoeg mensen die geen verstand hebben van techniek dus deze mensen vergeet ik zeker niet. die verwacht ik ook niet dat ze het zullen doen. Maar de mensen die bots inzetten zijn ook geen gewone gebruikers. Zulke mensen zie ik zeker wel uitzoeken hoe je een IMEI kan spoofen (of wat voor andere informatie ze gaan controleren). En captcha + dit is natuurlijk bedoelt om zulke mensen tegen te gaan en niet om Henk, Greta, Tina en Anniek alleen maar te pesten.

[corset]

Dat is natuurlijk zeker zo. Maar die mensen zullen altijd wel een manier verzinnen helaas..

@GekkePrutser dat klopt, maar het is niet echt een reliable methode om te faken

[mailis]

Cloudflare noemt specifiek dat Google ook betrokken is geweest bij de ontwikkeling, dus een snelle ondersteuning van Android lijkt ook voor de hand te liggen. Er is nog geen aanwijzing dat het in Android 13 zit, de eerstvolgende versie, die deze zomer uitkomt. Alle functies en api's zitten er al in vanwege de naderende release, dus die ondersteuning lijkt niet alsnog te komen.

Is het persé nodig om dit op OS niveau voor Google te regelen? Met de uitrol van de Exposure Notifications API ging dit bijvoorbeeld via de framework Play Services waardoor tot Android 6.0 direct ondersteuning was ipv. een heel update proces.

[TigerXtrm]

Ik begrijp niet helemaal hoe dit systeem het verschil zou moeten zien tussen een bot en een mens?

[blorf]

Ze gaan uit van een gecentraliseerd systeem onder de autoriteit van partijen die elkaar vertrouwen. Het probleem is dat de politiek theorie over beveiliging selectief overboord gooit. Ze willen zelf wel overal bij kunnen. Dit is bijv. ook waarom SSL zo weinig heeft geholpen...

[GekkePrutser]

Dat doet het niet. Het herkent een apparaat dat verkocht is door een geverifieerde Apple of Google e.d. en daarmee waarschijnlijk zo dichtgetimmerd is dat het niet gebruikt kan worden om er automatische requests mee te versturen. Apple is al behoorlijk dichtgespijkerd (je mag niet eens je eigen browser engine installeren). Google zal hier ook wel aan gaan werken.

Dit is inderdaad iets heel anders dan checken of er een mens achter zit zoals een Captcha (die immens vervelend zijn, dat geef ik toe).

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 17:54]

[Xxana]

Captcha werd ook gebruikt om AI & machine learning te voorzien van datasets. Wil dit zeggen dat deze nu voldoende informatie hebben, of gaan ze op een andere manier de modellen trainen?

[Kapitein187]

]In de bèta is het een functie die standaard uit staat, vermoedelijk staat het standaard aan bij de release dit najaar.

@arnoudwokke net even gekeken bij mij en het staat juist standaard aan in de bèta.

In the first betas of iOS 16 and iPadOS 16, Automatic Verification is enabled by default.
https://www.macrumors.com/2022/06/20/ios-16-bypass-captchas/

[arnoudwokke]

Ja verrek, je hebt gelijk! Ik heb het aangepast, thanks!