Apple hat Web-Geräte-Attestation bereits ausgerollt, und wir haben es kaum bemerkt
(httptoolkit.com)- Während Googles Vorschlag Web Environment Integrity kontrovers diskutiert wird, hat Apple mit Private Access Tokens bereits ein ähnliches System zur Web-Geräte-Attestation in macOS 13, iOS 16 und Safari ausgerollt
- Private Access Tokens funktionieren so: Wenn ein Server HTTP 401 und eine
PrivateToken-Challenge sendet, lassen Browser und OS den Gerätezustand von einem Attester prüfen und senden die Anfrage anschließend mit einem signierten Token erneut - Cloudflare und Fastly haben dies integriert, um CAPTCHAs zu reduzieren; dieselbe Struktur bildet jedoch die Grundlage dafür, dass Webserver verlangen können, das Gerät eines Nutzers als legitimen Client nachzuweisen
- Safaris Marktanteil liegt bei etwa 20 %, daher ist die Wirkung begrenzt; Chromium-basierte Browser kommen jedoch auf über 70 %, sodass zusammen mit Googles Vorschlag rund 90 % der Web-Clients für Attestation infrage kommen könnten
- Attestation kann neue Browser, Betriebssysteme, Open Source und von Nutzern modifizierte Geräte ausschließen; zudem besteht das Risiko, dass Regeln anhand von Kriterien wie offiziellem Supportzeitraum oder installierten Adblocker-Erweiterungen verschärft werden
Einführung und Zweck von Apple Private Access Tokens
- Die Sorge über den Vorschlag Web Environment Integrity, der offenbar von Google-Autoren entwickelt wird und in Chromium prototypisch umgesetzt wird, wächst
- Dieser Vorschlag entspricht Attestation im Web: Je nachdem, ob ein Client von einem vertrauenswürdigen Aussteller freigegeben wurde, können Funktionen oder der Zugriff auf ganze Websites eingeschränkt werden
- Als tatsächliche Vertrauensaussteller kommen wahrscheinlich Apple, Microsoft und Google infrage
- Apple hat bereits vor einem Jahr ein sehr ähnliches System namens Private Access Tokens entwickelt und ausgerollt; es ist heute in macOS 13, iOS 16 und Safari integriert
- Apple beschreibt Private Access Tokens als „leistungsfähiges Werkzeug, um nachzuweisen, dass HTTP-Anfragen von legitimen Geräten stammen, ohne die Identität offenzulegen“
- Hauptzweck dieser Funktion ist die Abschaffung von CAPTCHAs; Cloudflare und Fastly haben sie als Mechanismus integriert, um echte Clients zu erkennen
- Erklärung von Cloudflare: Eliminating CAPTCHAs on iPhones and Macs using new standard
- Erklärung von Fastly: Private Access Tokens: Stepping into the privacy-respecting CAPTCHA-less
Funktionsweise von Private Access Tokens
- Private Access Tokens sind ein vergleichsweise einfacher Austausch über HTTP, der von einer eingebauten Browser-API abgewickelt wird und mit OS-Komponenten zusammenarbeitet, um zu prüfen, ob Browser und OS legitim sind
- Was hier als „legitim“ gilt, entscheidet der Attester, also etwa Apple
- Der grundlegende Ablauf ist wie folgt
- Der Browser sendet eine HTTP-Anfrage an den Webserver
- Der Webserver weist die Anfrage zurück und gibt eine HTTP-401-Antwort mit einer
PrivateToken-Challenge zurück - Der Browser sendet Teile der Challenge sowie vom OS bereitgestellte, verifizierte Geräteinformationen an den Attester
- Der Attester prüft, ob das Gerät echt und unverändert ist, und gibt anschließend zusammen mit einem Token-Aussteller, dem die Origin vertraut und der dem Attester vertraut, ein signiertes Token zurück
- Der Browser sendet die Anfrage erneut und setzt das signierte Token in den
Authorization-Header - Der Server kann den Client anders behandeln, basierend auf der Tatsache, dass der Client von einem Vertrauensanbieter verifiziert wurde
- Dieser Ablauf findet auf Apple-Geräten mit Safari bereits statt, wenn Dienste wie Fastly oder Cloudflare, die diese Funktion nutzen, die Legitimität einer Anfrage anzweifeln
- Private Access Tokens trennen den Flow von Origin, Issuer und Attester und zielen damit auf Datenschutz ab; zugleich hängt die Behandlung im Web davon ab, ob Apple die Geräte-, OS- und Browser-Konfiguration für akzeptabel hält
Unterschiedliche Reichweite von Safari und Chromium
- Schon Private Access Tokens allein belasten das Web und die Branche insgesamt, doch wegen Safaris Marktanteil ist eine so schnelle Verbreitung wie bei Googles Vorschlag unwahrscheinlich
- Safaris Browser-Marktanteil liegt derzeit bei etwa 20 %
- Mobil bei etwa 25 %
- Auf dem Desktop bei etwa 15 %
- Chrome liegt in allen Bereichen über 60 %, und Chromium insgesamt – einschließlich Brave, Edge, Opera, Samsung Internet und weiterer Browser – liegt noch rund 10 Prozentpunkte darüber
- Solange nur Safari diese Funktion anbietet, können einige Anbieter sie zwar nutzen, aber es ist schwierig, Clients ohne Attestation zu blockieren oder anders zu behandeln
- Selbst wenn Safari ältere OS-Versionen oder Browser nicht attestiert, dürfte das die Nutzer kaum stark treffen; statistisch gesehen sehen sie eher mehr CAPTCHAs
- Wenn Web Environment Integrity in einer Lage eingeführt wird, in der über 70 % der Web-Clients Chromium nutzen, könnte es sich rasch in zentralen Teilen des Webs ausbreiten
- Wenn Web Environment Integrity und Private Access Tokens zusammen existieren, wären potenziell rund 90 % der Web-Clients von Attestation betroffen, und der Druck könnte steigen, Clients „ohne Attestation als verdächtig zu behandeln“
Wie Attestation die Offenheit des Webs erschüttert
- Attestation erlaubt nur zugelassene Clients und ist daher nachteilig für Wettbewerb und Innovation
- Neue Browser oder Betriebssysteme zu entwickeln wird schwieriger
- Open-Source-, Community- und kleine Indie-Projekte könnten von solchen Mechanismen dauerhaft ausgeschlossen werden
- Es wird der Vergleich gezogen, dass Attestation zu Zeiten von IE6 ein großes Hindernis für den Aufstieg von Firefox und Chrome gewesen wäre
- Diese Struktur erschwert es Nutzern schon vom Design her, die Kontrolle über ihre eigenen Geräte zu behalten
- Dass Nutzer mit modifizierter Software nicht als legitime Clients attestiert werden, ist eines der zentralen Ziele
- Der Anwendungsfall, mit einem gerooteten Android-Smartphone im Web zu surfen, könnte ausgeschlossen werden
- Vollständig durch Nutzer modifizierbare Betriebssysteme oder Hardware lassen sich schwer auf die von solchen Vorschlägen beabsichtigte Weise attestieren
- Zulassungsanbieter können die Regeln später verschärfen
- „Nur Geräte innerhalb eines offiziellen Supportzeitraums von zwei Jahren attestieren“
- „Browser mit installierten Adblocker-Erweiterungen nicht attestieren“
- Befürworter von Web Environment Integrity glauben, dass Holdbacks, bei denen Attestation für einige Anfragen verweigert wird, Attestation-basierte Sperren verhindern können
- Es gibt jedoch Bedenken, dass Holdbacks wegen geschäftlichen Drucks in der Praxis kaum funktionieren; Googles bestehende Android-Play-Integrity-Attestation nutzt diesen Ansatz nicht
- Der Erfolg des Webs beruhte stark darauf, dass verschiedenste Clients und Server frei genutzt werden konnten; Attestation bricht diese Voraussetzung schon im Design
Auf Android bereits sichtbare Risiken
- Auf Android ist es technisch möglich, ein eigenes OS zu erstellen und auszuführen, und auch Android-Distributionen wie LineageOS funktionieren normal
- Durch Attestation besteht jedoch weiterhin das Risiko, dass zentrale Apps wie Banking-Apps Nutzer als verdächtig einstufen und blockieren
- Schon die Behinderung des Wettbewerbs zwischen Android-Versionen ist problematisch, doch die Behinderung des Wettbewerbs sowohl zwischen Browsern als auch zwischen Betriebssystemen im Web kann noch weit gravierendere Folgen haben
- In der Anti-Fraud Community Group gibt es auch weitere Vorschläge, die potenzielle Web-Funktionen derselben Kategorie diskutieren
- Betrug und Bots im Web sind reale Probleme, und die Diskussion über Verteidigungsmethoden ist wertvoll; doch das Blockieren von Wettbewerb, die Schwächung von Open Source und des offenen Webs sowie der Entzug der Kontrolle der Nutzer über ihre Geräte sind kein vernünftiger Tausch
1 Kommentare
Hacker-News-Kommentare
Auf Googles ursprünglichen Vorschlag gab es gestern viele Reaktionen wie „eine Aufspaltung des Unternehmens ergibt langsam ziemlich viel Sinn“, „verpiss dich, Google“, „ich bin wütend und traurig“ oder „der Ruf der Beteiligten ist endgültig ruiniert“.
Heute kam heraus, dass Apple dieselbe Funktion nicht nur im vergangenen Jahr vorgeschlagen, sondern tatsächlich implementiert und ausgerollt hat — und der Ton klingt eher nach „das könnte eine spannende Gelegenheit sein, längst verschwundene Träume neu zu starten“, „ich kann beide Seiten ein Stück weit verstehen“ oder „ich lasse es in Safari erst einmal 1–2 Jahre eingeschaltet und beobachte es“.
Insgesamt ist die Stimmung zwar weiterhin negativ, aber der Unterschied im Ton gegenüber Apple und Google ist so deutlich, dass das Reality Distortion Field noch immer intakt zu sein scheint.
Einer von ihnen hat sogar direkt auf Hacker News gepostet, was wiederum dazu führt, dass Gegner glauben, die Beteiligten würden aufgeben, wenn man sie nur genug drangsaliert — und solches Verhalten befeuert.
Apple verbringt mit so etwas keine Zeit, sondern prüft, plant und setzt um. Man weiß nicht, wer beteiligt ist, üblicherweise wird auch nicht um Feedback gebeten, und selbst Begründungen für die Pläne werden selten geliefert. Sich in Webforen über Apple aufzuregen ist ungefähr so nützlich, wie eine Ziegelmauer anzuschreien.
Das Klischee vom gesichtslosen Unternehmen gibt es nicht ohne Grund; es ist eine bewusste Politik zum Schutz der Mitarbeiter.
Bei Apple ist es jedoch umgekehrt. Die Freiheit, Drittanbieter-Apps zu installieren, gelte als gefährlich; die Freiheit, iMessage im Browser zu verwenden, sei absurd; und an der Freiheit, unter iOS Drittanbieter-Browser zu nutzen, scheint die Mehrheit kaum Interesse zu haben.
Bemerkenswert ist, dass der Lock-in-Effekt anderer Unternehmen schlecht ist, Apples Lock-in-Effekt aber von der Nutzerschaft aktiv missionarisch verteidigt wird.
Apples Ansatz ist eher ein Mittel, um auf Apple-Geräten menschliche Nutzer von nichtmenschlichen Nutzern zu unterscheiden, und erlaubt es Diensten nicht, willkürlich Browser oder Betriebssysteme zu blockieren, wie es der Google-Vorschlag tun würde.
Wenn man ohnehin ein Apple-Gerät nutzt, erspart es einem im Grunde nur „Bist du ein Mensch?“-CAPTCHAs.
Siehe: https://developer.apple.com/wwdc22/10077
Google hingegen lässt zu, dass eine kleine, laute Schicht von Google-Hassern den Ruf immer weiter beschädigt, und betreibt kaum PR, um das Narrativ zu kontrollieren.
Offenbar glaubt man immer noch, das Echo eines einzigen „don’t be evil“ werde auch 20 Jahre später noch nachhallen.
Als Microsoft den IE in Windows bündelte, war das entsetzlich; wenn Apple Safari bündelt und konkurrierende Browser blockiert, heißt es dagegen, das sei das Beste für die Kunden.
Das könnte wirklich der Punkt sein, an dem sich das Internet aufspaltet. Seit den 90ern wird das immer wieder vorhergesagt.
Auf der einen Seite könnte ein „sauberes“, autoritär abgesegnetes Corporate Web entstehen, in dem alle übermäßig stark identifiziert werden; auf der anderen Seite eine lockerere Graynet-Galaxie aus Pornografie und dezentralen Communities.
Wenn alle Tüftler aus den Unternehmensnetzen gedrängt werden, könnte das eine spannende Gelegenheit sein, längst verschwundene Träume neu zu starten.
Ich habe mir vorgestellt, dass über dem Internet eine blasenartige soziale Oberstruktur entstanden ist, die „die Gesellschaft“ repräsentiert. Kleine Versionen davon gab es seit den 90ern, aber mit dem Aufstieg sozialer Medien wie Myspace, Facebook und Twitter wurde es ernst.
Dass kurz darauf die „Cancel Culture“ auftauchte, halte ich nicht für Zufall. Wenn ein virtualisierter öffentlicher Raum entsteht, geht es nämlich als Nächstes darum, wer entscheidet, was und wer dazugehört.
So nach dem Motto: „Endlich kann ich die Fähigkeiten erproben, für die mich die Leute so lange ausgelacht haben.“
In beiden Fällen besteht das Problem darin, dass die große Mehrheit der Menschen ignoriert wird, die unter der neuen Ordnung leiden würde. Nur eine winzige Minderheit wird den ummauerten Garten der Unternehmen verlassen und auf die freie Datenautobahn wechseln.
Nur schwache Echos des Corporate Webs bleiben über das Graynet erhalten, und digitale Archäologen versuchen, die „Geheimnisse“ verlorenen Wissens aufzudecken, das im Corporate Web verborgen war.
Das hat bestimmt schon jemand geschrieben, aber es scheint gut zu passen.
In Heimumgebungen, in denen Public Cloud und private Nutzung aufeinandertreffen — etwa bei einem privat genutzten Cloudflare-Access-Tunnel und einem MS365-Business-Tenant — will man es in gewissem Maße ebenfalls.
Aber ich möchte auf keinen Fall, dass es jemals die persönliche Web-Browsing-Erfahrung oder die private Browser-Umgebung erreicht.
Im Moment stehen diese Wünsche praktisch im Konflikt miteinander, und die Katze ist bei dieser Technik bereits aus dem Sack.
Der Cyberpunk-Traum der 90er ist cool, aber er scheint die physische Realität zu ignorieren, dass man immer durch den Flaschenhals eines Internetproviders muss, um sich mit dem „Netz“ zu verbinden.
Letztlich gibt es eine unüberwindbare Grenze dafür, wie systemfeindlich das Internet sein kann.
Ich kann mich irren, aber Web Attestation könnte für Linux-Geräte, die das Web gleichberechtigt als Client nutzen, das Todesurteil sein – nicht für Android oder Chrome OS.
Linux ist eine zu vielfältige und zu leicht hackbare Plattform, als dass Remote Attestation zuverlässig funktionieren könnte; am Ende würde es wohl vollständig ausgeschlossen.
Ein paar „gesegnete“ Distributionen wären die Ausnahme, aber solche Distributionen würden von der Branche kontrolliert und hätten dann mit dem Geist von Linux kaum noch etwas zu tun.
Man landet bei fast jeder Website in den Spam-Abwehr-Klassifikatoren und muss drei- bis fünfmal Captchas lösen, um auf geschützte Bereiche zuzugreifen.
Auch Wikipedia verhindert Bearbeitungen: https://meta.wikimedia.org/wiki/Talk:Apple_iCloud_Private_Re...
Da mir offenbar die Willenskraft fehlt, solche Sites aufzugeben, ist es vielleicht sogar nötig, dass die andere Seite das Laden der Inhalte blockiert.
Jetzt, wo ich es hier gesagt habe, ist es kein Geheimnis mehr.
https://github.com/jwise/28c3-doctorow/blob/master/transcrip...
Auch sie sind vielfältige und hackbare Plattformen, die in einer Zukunft, in der man den Besitz bestimmter Hardware nachweisen muss, wohl als unzureichend gelten werden.
Man hört oft, dass einige „gesegnete“ Distributionen unter Branchenkontrolle geraten und dadurch der Geist von Linux verschwindet, aber selten, wie genau das konkret passieren soll.
Linux entstand wegen des von der Branche kontrollierten UNIX, und wenn man Linux diesen Geist nimmt, wird es in ein anderes Community-Projekt geforkt.
Solange man ihm nicht die GPL-Lizenz entzieht, wird Linux seinen „Linux-Geist“ behalten, bis es gar nicht mehr genutzt wird.
Der Behauptung, Safari sei nicht so gefährlich wie Googles Vorschlag, weil es nicht der dominante Browser ist, stimme ich nicht zu.
In Wirklichkeit ist es genauso schlecht, ob Apple oder Google es tut, und Apple hat eine komplett enttäuschende Entscheidung getroffen.
Selbst wenn Google darauf gedrängt hätte: Hätte Apple abgelehnt, wäre es praktisch schwer durchzusetzen gewesen. Die Zahlen sind zwar nicht so hoch wie bei Chrome, aber groß genug, dass man nicht alle iDevices abschneiden kann.
Wirklich wichtig sind nur drei Unternehmen: Apple, Google und Microsoft.
Schade, dass es diesmal eine weitere Katastrophe nicht verhindern konnte.
Deshalb machen mir auch Gesetze Sorgen, die Apple zur Öffnung für Sideloading zwingen wollen. Mir gefällt die Idee, dass Menschen ihre eigenen Systeme kontrollieren, aber ich fürchte, dass es in der Praxis der letzte Nagel sein könnte, der Googles vollständige Kontrolle über das Web bis hin zum Client-Endpunkt zementiert.
Jedes Mal, wenn ich darauf hinweise, dass eine von ihnen implementierte Funktion nicht mit mehreren Browsern kompatibel ist, sagen sie mir einhellig, ich solle von Firefox zu Chrome wechseln.
Noch nie hat mir jemand gesagt, ich solle zu Safari wechseln, damit etwas funktioniert. Das sagt für sich genommen schon viel aus.
Unter iOS scheint man diese Funktion ausschalten zu können.
In die Einstellungen gehen, ganz oben das Benutzerkonto auswählen, dann zu „Password & Security“, nach unten bis „Advanced“ scrollen und „Automatic Verification“ deaktivieren.
https://blog.cloudflare.com/how-to-enable-private-access-tok...
https://support.apple.com/en-us/HT213449
System Settings -> iCloud Settings(Benutzername) -> Password & Security -> Automatic Verification
Wenn Chrome WEI ausrollt, werden es auch diverse Chromium-Forks abschaltbar machen, selbst wenn Chrome das nicht tut, und man kann Firefox verwenden.
Das Problem beginnt, wenn Banken, Steuerbehörden und der bevorzugte Streamingdienst anfangen, diese Funktion zu verlangen.
Der Kernpunkt ist, dass ein erheblicher Teil der normalen Nutzer diese Funktion überhaupt haben wird.
Ich habe das tatsächlich bemerkt und sogar überlegt, darüber zu bloggen; der einzige Grund, warum es mir nicht wie ein Problem vorkam, war aber, dass es nur auf Apple-Plattformen implementiert war und Dienste damit keine echte Möglichkeit hatten, Nutzer einzuschränken.
Es war einfach ein zusätzlicher Faktor, den Leute als ein weiteres Signal verwenden konnten.
Googles Vorschlag hingegen zielt ausdrücklich darauf ab, daraus eine immer eingeschaltete Funktion zu machen.
Die Beschreibung von Anwendungsfällen wie „deterministischer Nachweis der Plattformintegrität“, die derzeit auf Client-Fingerprinting angewiesen sind, läuft letztlich auf das Argument hinaus, dass ein deterministischer Nachweis mit begrenzter Entropie invasives Fingerprinting ersetzen und langfristig datenschutzfreundlichere Praktiken ermöglichen könne.
Dass Apple es zuerst implementiert hat, beweist nur, dass naiv ist, wer erwartet, Apple werde uns retten.
Dieser Bereich ist wirklich interessant und dürfte stark polarisieren.
Es gibt enorm viele Use Cases, in denen man im Web wissen möchte, ob man mit einem „vertrauenswürdigen“ Hardware- und Software-Stack kommuniziert.
Über viele Jahre hinweg haben wir Systeme in der Annahme entworfen und gebaut, dass es im Stack kaum Vertrauen gibt. Das erhöht Komplexität und Kosten enorm, schränkt Funktionen ein und macht alles viel schwieriger, als es wäre, wenn man einen vertrauenswürdigen Stack voraussetzen könnte.
Gleichzeitig wird der Begriff Vertrauen, wie derzeit vielfach angemerkt wird, sehr schwierig, sobald große Tech-Monopole im Spiel sind.
Einerseits gibt es weltweit nur wenige Unternehmen, die große Sicherheitsteams betreiben können, um gegen dauerhafte Bedrohungsakteure vorzugehen; daher wäre es wünschenswert, ihren Sicherheitsversprechen vertrauen zu können. Wenn diese Versprechen vertrauenswürdig sind, sind sie besser als alles, was Einzelne für ihre eigene Software und Plattform zusichern können.
Andererseits bedeutet „vertrauenswürdig“ im platonischen Sinne eines Hackers schnell „von einem Monopol garantiert“ und „wahrscheinlich mit Backdoor der lokalen Regierungsbehörden“; es ist ein weiterer Schritt hinab in eine von Kontrolle, mangelnder Innovation und letztlich wenigen Akteuren dominierte faschistoide Tech-Zukunft.
Eine erfolgversprechende Lösung muss meiner Ansicht nach am Ende eine vertrauenswürdige offene Hardware-Attestierungstechnologie enthalten, die nicht auf einem Register basiert. Man muss starke lokale Attestierungen erstellen und unabhängig verifizieren können.
Ich kenne einige Tech-Unternehmen, die dieses Problem auf der Siliziumseite angehen, aber es ist ein sehr schwieriges Problem, und ich bin nicht sicher, ob es derzeit genug Nachfrage gibt, damit sie überleben.
Persönlich lasse ich das in Safari vorerst eingeschaltet und beobachte die nächsten ein bis zwei Jahre.
Auch DRM-Technik wird in solchen Begriffen diskutiert, aber ihr Ziel ist nicht, den Nutzern Vertrauen zu geben, sondern Entwicklern oder Rechteinhabern.
Man sieht deutlich, dass es hier vielleicht gar nicht wirklich um Vertrauen geht.
Man muss wählen, ob man die Vorteile des staatlichen Systems nutzen will und ob dessen Kosten es wert sind.
Das Problem der meisten solcher Systeme ist, dass sie Ausnahmen überhaupt nicht behandeln können.
Für 99 % der Bevölkerung funktionieren sie gut, aber das restliche 1 % hat eben Pech.
Es ist, als wolle man nach Feierabend ins Büro, nur um den vergessenen Autoschlüssel zu holen, und der Roboter verweigert den Zutritt.
Das System ist sicher konstruiert, daher kann man den Roboter nicht verbal überzeugen. Bei einem Menschen wäre es normalerweise viel einfacher, ihn im Gespräch zu überzeugen und eine funktionierende Lösung zu finden.
Techniker versuchen am Ende doch, alles mit Technik zu lösen: „Wenn es ein Problem gibt, löse ich es; schau dir meine Technik an, während der DJ auflegt.“
So kommt es dazu, dass Bankkonten gehackt werden, nur weil jemand gut reden und sich eine plausible Geschichte ausdenken kann, um einen menschlichen Gatekeeper zu überzeugen.
Wenn es ein Mittel wäre, um zu sagen: „Ja, diese Person ist ein echter Mensch“, könnte das nützlich sein. Aber hier handelt es sich nur um eine Systemattestierung, und es gibt keine Möglichkeit zu wissen, ob sie böswillige Akteure aufhalten kann oder ob sie wie andere Systeme, etwa CORS, missverstanden und missbraucht wird.
Die logische Konsequenz dieses Systems lautet: „Wenn du ein normales System hast, bist du ein normaler Nutzer; wenn nicht, dann nicht.“
Ich kann beide Seiten bis zu einem gewissen Grad verstehen
Wenn man die Absichten der anderen wohlwollend auslegt, ist ein Web, das von identifizierten Menschen und ihren autorisierten Stellvertretern bevölkert ist, möglicherweise der „sauberste“ ideale Web-Raum, den wir uns vorstellen können
Ein Web voller Fake-Accounts und Link-Farmen ist nicht ideal
Der klarste Endpunkt dieser Entwicklung ist eine staatlich ausgestellte digitale Identität, die die eigene Identität nachweist und zugleich als Login dient
Wenn man die Augen etwas zusammenkneift, kann das wie ein Trittstein auf dem Weg dorthin wirken
Ist das die Verwirklichung des Idealismus der 70er-Jahre? Nein. Aber ich halte es bis zu einem gewissen Grad für einen vernünftigen Kompromiss
Wenn man der Regierung nicht trauen kann? Das ist wahrscheinlich etwas, das kein Internet lösen kann. Es ist ein Problem der realen Welt
Für mich klingt das eher nach einem sterilisierten Web
Selbst wenn man kurz ignoriert, dass Menschen am Ende auch dieses System umgehen werden, und annimmt, dass es zum „saubersten“ Web-Raum wird, setzt man damit voraus, dass Verbraucher das wollen
In der Welt nativer Apps gibt es bereits den App Store, Lockdown-Kontrollen und App-Identität, und trotzdem dominiert das Web weiterhin den Handel; durch Beispiele wie Figma scheint es sogar stärker zu werden
Wo also ist der Ruf nach diesem „gereinigten“ Web? Zumindest auf Verbraucherseite sieht die Nachfrage überhaupt nicht danach aus
Warum ist eine derart absurd starke Identitätsprüfung nötig? Wenn sie wirklich nötig wäre, wie hat das Internet dann bisher funktioniert?
Tatsächlich schlägt derzeit aber niemand so etwas vor. Weder Apples noch Googles Ansatz kommt dem auch nur nahe. Was sie zusichern wollen, ist die „Integrität“ der Plattform
Welche Integrität genau? In dem Beispiel heißt es, dass gezeigt wird, dass der Nutzer einen Web-Client auf einem sicheren Android-Gerät ausführt
Das sagt also weder, ob der Nutzer eine einzigartige Person ist, noch liefert es einen brauchbaren Identifier zu einer Person. In diesem Beispiel und bei Apple erfährt man nur, dass das Gerät nicht gerootet oder gejailbreakt ist
In der Praxis ist dieses Konzept nur als Teil eines größeren Katz-und-Maus-Spiels nützlich. Wie beim Urheberrechtsschutz wird auch Remote Attestation durch das begrenzt, was sie tatsächlich nachweist
So wie es schwierig ist, Camcorder-Aufnahmen im Kino zu verhindern, und es am Ende viele Zwischenschritte gibt, die ausnutzen, dass ein Film eine Abfolge von Bildern und PCM-Sample-Frames ist, kann man nicht verhindern, dass jemand, trotz teurer Geräte, mehrere davon beschafft und damit arbeitet
Es gibt bereits viele Menschen mit ganzen Stapeln von Android-Geräten, um Systeme zu täuschen, und wenn man sie je nach Fall für 50 Dollar pro Stück kaufen kann, ist das keine nennenswerte Hürde
Am Ende erhöht es nur die Kosten und die Komplexität für Bot-Betreiber, und theoretisch hätte man gewonnen, wenn man den Break-even-Punkt hoch genug ansetzt. Aber weil die Gewinne aus Spam und Betrug so groß sind, wird das nicht passieren
Nach Jahren der Gegenmaßnahmen sind wir noch nicht einmal in der Nähe, und das Geld, das in die Industrie zum Täuschen solcher Systeme fließt, reicht mehr als aus, um diese Kosten zu tragen
Auch eine Beimischung staatlicher Ausweise ändert daran nichts. Hinter fast jeder Spam-Operation stehen echte Menschen; selbst wenn jemand einen Blindnachweis erhält, dass jemand Staatsbürger ist, weiß man über diese Person fast nichts
Um zu helfen, müsste es nicht ein Nachweis sein, dass jemand berechtigt ist, sondern man müsste tatsächlich die eindeutige ID jeder Person erhalten
Und wenn das der Endpunkt des Internets ist, dann war dieses ganze Experiment ehrlich gesagt nichts wert
Man könnte auch eine gefälschte Maus oder Tastatur anschließen und die Eingaben direkt einspeisen
Sicherheits-Hardware scheint keinen Vorteil zu bringen. Für Leute, die in gewissem Umfang Desinformation verbreiten, ist sie nicht einmal ein Speedbump
Sie macht es nur sehr unerfahrenen oder leichten böswilligen Akteuren ein wenig unbequemer und schränkt Menschen, die Browser bauen können, sowie Nutzer nicht vertrauenswürdiger Geräte stark ein, etwa Linux-Nutzer oder Personen, die Trusted Boot deaktivieren
Ich weiß nicht, ob ihr euch an AllAdvantage erinnert
Das war um die Jahrtausendwende ein Dienst, der auf dem Desktop Werbung anzeigte und dafür Geld zahlte, allerdings nur, wenn der PC tatsächlich genutzt wurde
Die Leute täuschten ihn mit Mausbewegungsgeräten aus, und es entstand ein kleines Wettrüsten
Für sie wäre diese Technik ein Traum. Man könnte erkennen, ob eine Anfrage aus einem echten Browser oder aus einem Skript kommt, und die Attestation deaktivieren, wenn Eingaben über nicht vertrauenswürdige Treiber simuliert werden oder der Browser automatisiert wird
Eine wirklich unangenehme Technik
Das kommt einer engen Integration einer sehr beliebten Kategorie von Sicherheitsprodukten direkt in den Browser selbst nahe
Heute kann man eine philosophische Haltung einnehmen und jede Website ablehnen, die reCAPTCHA/hCAPTCHA verwendet, und morgen kann man jede Website ablehnen, die PAT verwendet