90 Prozent meiner Karriere habe ich eher nur technische Lösungen konzipiert, so langsam verstehe ich, dass das Entscheidende nicht die technische Lösung ist, sondern die Folgen der Nutzung. Das heißt nicht, dass ich jetzt alle Probleme nur soziologisch lösen werde, es heißt eher, dass die Technik die soziolgischen Folgen mit antizipieren sollte.

@stefan an sich ja, aber die Aussage ist verifiziert durch eine staatliche Stelle. Und es ist zumindest im Kontext an genau den Account bindbar

@christopherkunz @publictorsten danke SPD (oder Menschen aus der SPD, die das als SPD Vorschlag geframt haben)

@publictorsten ach, wegen mir, genauer gesagt dem Hinweis, dass unbedarftes Handeln im Digitalen reelle Folgen hat, sind schon Menschen “gestorben”. Vorwürfe besorgter Eltern werden ähnlich hart werden

@publictorsten es geht doch nicht um Sicherheit, es geht um Sicherheitstheater ️

Ergänzend auch meine Einschätzung zu den Anmerkungen von @publictorsten

Auch wenn es einfacher umgesetzt wird, gibt es eine Adhärenz, dass das die Eltern machen. Und das Botproblem wird einfach nur teurer.

https://mastodon.social/@publictorsten/116085285283963859

@publictorsten "echte" verifizierte Bots sind dann wieder mehr wert, also ist es auch wieder möglich, mehr Geld dafür zu bezahlen, usw. Keine unüberwindbare Hürde, eher nur eine Frage, was der Markt an Desinformation dafür zahlen will.

@publictorsten Im Nutzungsverhalten wird aber ein Großteil der Bevölkerung "brav" das mit den Erziehungsberechtigten machen. Also hast du zu einem größeren Prozentsatz einen wahrscheinlich verfizierten sozialen Graph. Es erhöht zumindest die Wahrscheinlichkeit, dass der Graph so ist.

Bei den Bots ist die Frage eher, wie viel Geld so eine Botarmee kosten darf. Im Prinzip wird dann jeder Identity Theft halt eine Chance, "echte" Bots onzuboarden.

Dazu hat eIDAS noch weitere die Privatsphäre und die Anonymität der betroffenen Personen aufbrechenden Eigenschaften:
- Ein Unique Identifier ist nicht ausgeschlossen und könnte hier beim Wechsel von verschiedenen EU-Varianten genutzt werden (dafür wurde er eingeführt eigentlich)
- Datenleaks sind wegen signierter Daten schädlicher als in anderen Lösungsansätzen.
etc.

Eine in diesen Aspekten halbgare Wallet auch noch staatlich gefördert durchzusetzen, ist schwierig.

In der "ab 16" Fassung haben wir dann mindestens die Ableitung staatlich verifizierter Metadaten (Alter über X) und je nach Ausgestaltung mehr staatlich verifizierte Daten. Social Media Plattformen werden hier alle Daten einfordern, die sie kriegen können, weil sie von sich das Risiko wegdrücken müssen, weil die Plattformen ja sonst haften würden.

Datensparsamkeit funktioniert hier also nicht.

- Das Konstrukt "Eltern verifizieren für ihre Kinder von 14 bis 16" bedeutet, dass Eltern sich ja auch als Eltern eines Kindes ausweisen müssten. Es wird also ein sozialer Graph notwendig: "Das ist mein Kind". Für Social Media Plattformen bedeutet das staatlich verifizierte Social Graphs, die möglicherweise dann weiter monetarisiert werden können.
Diese Beziehung nicht zu verifizieren, würde Social Media Plattformen eher wegen der Gefahr von Sanktionen selbst in Gefahr bringen.

Ich nehme Bezug auf dieses Paper (https://www.spdfraktion.de/system/files/documents/impulspapier-sichere-soziale-medien.pdf).

Wichtig zu wissen zur EUDI Wallet, die hier ja als zentrales Mittel zur Verifikation genutzt werden soll:
- Es gibt nicht eine Wallet, es gibt einen Markt von Wallets, weil eIDAS2 explizit den Markt schafft, mehrere Wallets haben zu können. Es gibt die staatliche deutsche Implementierung, aber auch wirtschaftliche Akteure in DE, aber auch in der gesamten EU werden welche anbieten. Datenschutzniveau individuell unterschiedlich.

Das SPD-Impulspapier "Sichere Soziale Medien" versucht ja, #Altersverifikation als die technische Vorraussetzung für den sicheren Umgang mit Social Media Plattformen darzustellen.

Gleichzeitig wird auch versucht, die Maßnahmen als datenschutzkonform zu framen. Es gibt hier aber einen Widerspruch, wenn wir uns mal anschauen, wie sowas im Rahmen eIDAS2 umgesetzt werden könnte.

Dazu mal kurz: Wie würde eine solche Umsetzung denn eigentlich aussehen? 🧵

@tante sounds like worth burning the planet

@me_ die Frage auf der Ebene ist halt, ob das auch auf anderen Großrechnern gelaufen wäre

Das war damals noch auf anderer Ebene schwierig mit der Interoperability

Aus https://www.golem.de/news/digitale-souveraenitaet-in-bayern-noch-mehr-geld-fuer-microsoft-2602-205215.html

Bayerische Finanzminister verwirren mich, wenn sie über Computer sprechen. Vielleicht sollten sie das lassen …

@neonglitzer @sequundi Es lässt sich beides nutzen: Kein zweiter Faktor oder ein erzwungener zweiter Faktor. Da im Anmeldevorgang aber immer der zweite Faktor auf dem Device, dass die Anmeldung auslöst, bearbeitet wird, wird an die jeweilige Anmeldeseite nie ein Passwort etc. übermittelt, sondern immer eine neue Antwort auf eine individuelle Anfrage (also ein Challenge-Response-Verfahren). Es geht also nie ein persistentes Passwort übers Kabel

@utrenkner Es gibt aber auch device bound Passkeys. die sich nicht synchronisieren lassen. Das lässt sich im Standard auch erzwingen, wenn das wer will. Dann müsste dir schon wer genau das Gerät klauen, auf dem du den Passkey registriert hast.

Die kannst du nicht abfangen, weil kein Sync stattfindet.

Es geht also auch noch sehr viel sicherer, wenn das wer mit Passkeys bauen will

@utrenkner Es ist zweierlei:
Ein Passkey ist für eine bestimmte Seite / eine Host Origin registriert. Also zum Beispiel ist der Passkey, den du auf securesite.com anlegst, nur auf securesite.com nutzbar. Das ist das Host Binding, was ich meinte.

Das andere ist, wo der Passkey gespeichert wird. Die speicherst du irgendwo, und je nachdem, ob der Passkey synchronisierbar ist, könnte das Szenario mit abfangen funktionieren (kann aber auch bei nem Cloud Passwortmanager passieren … (1/2)