Identität, Sichtbarkeit, Ausschluss

Welche Minimalgarantien ein freiheitsschonendes ATProto-Overlay braucht

Übersicht

Prolog

Offene Protokolle geniessen einen Ruf, der ihnen in dieser Schlichtheit nicht zusteht. Sie gelten als Dezentralitätsversprechen, als technische Absage an monopolistische Kontrolle, bisweilen sogar als bereits halb vollzogene Freiheitsordnung. Ein Protokoll kann offen sein und doch in eine Architektur eingebettet werden, die Sichtbarkeit, Zugang und Wiederkehr an Stellen konzentriert, an denen die Spezifikation selbst keine unmittelbare Antwort mehr gibt. Gerade dort beginnt der eigentliche Gegenstand. Nicht die Frage, ob ein bestimmtes Projekt bereits die denkbar schlimmste Variante vollzogen hat, sondern die viel präzisere Frage, welche Minimalgarantien ein identitätsgestütztes, ATProto-kompatibles soziales System überhaupt erfüllen müsste, damit es nicht strukturell in personengebundene Exklusion umschlägt.1 2 3

Der Anlass

W Social ist für diese Frage ein geeigneter Anlassfall, weil dort zwei legitime Ziele in offener Spannung zueinander stehen. Auf der einen Seite steht die Absicht, automatisierte Manipulation, Sybil-Angriffe und massenhafte Ausweichkonten durch eine verifizierte menschliche Identität zu begrenzen. Auf der anderen Seite stehen jene Eigenschaften, die offene soziale Protokolle überhaupt interessant machen: Pseudonymität, Portabilität, begrenzte Moderation, die Möglichkeit zur Migration und die Chance, eine beschädigte oder missbrauchte Diskursidentität nicht auf Lebenszeit mit sich herumzutragen. Die Datenschutzerklärung von W Social sagt ausdrücklich, dass jedes Konto mit einer verifizierten menschlichen Identität verbunden sein müsse, zugleich aber W Social selbst keine Informationen verarbeite oder speichere, die ausreichen würden, die tatsächliche Identität der Nutzer festzustellen; die Identitätsprüfung werde durch W Identity als separate Verantwortliche vorgenommen. Beim Signup empfängt W Social nach eigener Auskunft aus der W Identity App eine W Identity UUID, das Passland und das Geburtsjahr.

Schon diese Konstellation reicht aus, um den eigentlichen Risikokern sichtbar zu machen. Denn das Hauptproblem ist nicht die blosse Existenz einer Human Verification. Das Hauptproblem entsteht dort, wo eine verifizierte Person und eine öffentliche Diskursidentität durch einen stabilen, operatorseitig verfügbaren Korrelationsanker zusammengezogen werden. Ab diesem Punkt verändert sich die innere Logik des Systems. Moderation ist dann nicht mehr bloss eine Reaktion auf das Verhalten eines bestimmten Kontos. Sie kann in Re-Registration-Denial, kontenübergreifende Sanktionierung, AppView-seitige Unsichtbarmachung, Discovery-Drosselung und langfristige Stigmatisierung derselben physischen Person umschlagen. Wer diesen Punkt übersieht, verwechselt einen offenen Sockel mit einer freien Ordnung. Das Protokoll mag unverändert bleiben, doch die Betreiber-Overlay-Schicht verwandelt seinen Gebrauchswert. Genau dort liegt die Gefahr.4 5 6

ATProto

ATProto selbst ist dafür ein lehrreiches Beispiel. Die Spezifikation arbeitet mit DIDs als persistenten, langfristigen Kontenidentifikatoren. Handles sind demgegenüber menschenlesbare, veränderliche Namen. Die Account-Spezifikation beschreibt Konten auf einem Personal Data Server, Migrationsmöglichkeiten zwischen Hosting-Anbietern und verschiedene Lifecycle-Zustände wie Deaktivierung, Takedown oder Löschung. Downstream-Dienste, einschliesslich Relays und AppViews, entscheiden ihrerseits unabhängig, welche Accounts und Inhalte sie redistribuieren und unter welchen Regeln sie dies tun. Auf der Moderationsseite unterscheidet Bluesky mehrere Schichten: Network Takedowns, Labels von Moderationsdiensten sowie User Controls wie Mutes und Blocks. Labeler veröffentlichen ihre Labels separat und können Konten oder Records adressieren. In der Föderationsarchitektur treten PDS, Relay und AppView als unterschiedliche Dienste auf; der Relay sammelt Netzwerkinhalte und gibt einen grossen Datenstrom für andere Dienste aus. Nichts davon erzwingt von sich aus eine reale Identität. Alles davon kann aber in ein Betreiber-Overlay eingebettet werden, das reale Identität, Sichtbarkeit und Moderation auf neue Weise zusammenzieht.7 8 9 10

Damit ist die methodische Arbeit erst eröffnet. Ein Bauchgefühl, und sei es noch so nachvollziehbar, ersetzt kein Threat Model. Wer über Identität, Bannpersistenz, Ausschluss und die angeblichen Heilsversprechen der Kryptographie reden will, muss zuerst sagen, was überhaupt geschützt werden soll, vor wem, an welcher Schicht und gegen welche Missbrauchspfade. Geschützt werden müssen in diesem Zusammenhang nicht bloss personenbezogene Daten im üblichen datenschutzrechtlichen Sinn. Geschützt werden müssen auch Portabilität, die Möglichkeit eines glaubhaften Exits, die Nicht-Vererbung eines alten Enforcement-Zustands in jede künftige Diskursidentität, die Begrenzung von Sichtbarkeitsmacht sowie die Trennlinie zwischen verifizierter Person und öffentlichem Diskurskörper. Die Bedrohungsakteure liegen ebenfalls nicht nur dort, wo klassische Datenschutzreflexe sie vermuten. Sie umfassen den Plattformbetreiber, den Identity Provider, das Moderationsbackend, den AppView-Betreiber, koordinierte Nutzergruppen, Scraper und Archivare sowie feindselige Regulatoren oder staatliche Akteure. Erst wenn diese Topographie steht, wird aus diffusem Misstrauen eine architektonisch prüfbare Fragestellung.11 12 13 14

Die entscheidende Trust Boundary liegt zwischen verifizierter menschlicher Identität und öffentlicher Diskursidentität. Fällt sie, werden nachgelagerte Schutzmechanismen brüchig, selbst wenn das zugrunde liegende Protokoll formal offen und föderiert bleibt. Der Plattformbetreiber kann dann retained correlation Material aufbewahren und Re-Entry blockieren. Der Identity Provider kann, selbst ohne selbst Moderator zu sein, zur Quelle eines stabilen menschengebundenen Tokens werden. Das Moderationsbackend kann accountbezogene Eingriffe in personengebundene Eskalationen verwandeln. Der AppView-Betreiber kann einen Nutzer nicht sperren, ihn aber faktisch aus der relevanten Öffentlichkeit herausindexieren. Koordinierte Nutzergruppen können über importierte Listen lange soziale Schatten produzieren. Scraper können öffentliche Moderationsartefakte dauerhaft archivieren und dadurch Schäden verstetigen, sobald die Grenze zwischen Person und DID irgendwo kollabiert. Regulatoren und staatliche Akteure können an genau diesen Stellen ansetzen, weil dort Macht und Nachweisbarkeit zusammenfallen. Ein Threat Model, das diese Akteure nicht mitdenkt, bleibt Dekoration.15 16 17 18

Missbrauchsszenarien

Ein erstes Missbrauchsszenario ergibt sich aus dem Onboarding selbst. Wer eine Identitätsprüfung vorschaltet, braucht irgendeine Form der Assertion, dass ein konkreter Mensch für diesen Kontext als verifiziert gilt. Harmlos bleibt das nur, solange diese Assertion nicht in einen routinemässig wiederverwendbaren Personenanker überführt wird. Bleibt im Backend ein stabiler Operator Identifier verfügbar, dann entsteht aus einer alten Sanktion ohne weitere Magie ein Re-Registration-Denial-Loop: Ein neues Konto wird nicht wegen seines eigenen Verhaltens abgewiesen, sondern weil das System denselben Menschen wiedererkennt und einen früheren Enforcement-Zustand fortschreibt. Genau hier muss man auf hoher Ebene sagen, was gemeint ist, wenn von „no reusable onboarding token“ die Rede ist. Gemeint sind kontextgebundene, kurzlebige, nicht routinemässig wiederverwendbare Assertions statt statischer backend-seitig korrelierbarer Personenanker. Ob das später mittels kurzlebiger, bereichsgebundener Credentials, selektiver Offenlegung oder Privacy-Pass-ähnlicher Konstruktionen operationalisiert wird, ist für den High-Level-Punkt sekundär. Primär ist die Negativgrenze: keine Routine-Wiederverwendbarkeit desselben Menschenankers über mehrere Account-Lebenszyklen hinweg.19

Ein zweites Missbrauchsszenario betrifft die Sichtbarkeit. In identitätsgestützten Umgebungen ist AppView-Macht häufig folgenreicher als der formale Kontostatus. Das Accounts-Dokument hält ausdrücklich fest, dass jede redistribuierende Komponente selbst entscheidet, welche Accounts und Inhalte sie hostet oder weitergibt. Die Föderationsarchitektur macht deutlich, dass AppViews auf dem Datenstrom anderer Dienste aufsetzen und daraus die sichtbare Diskursoberfläche konstruieren. Ein Nutzer kann also auf PDS-Ebene technisch weiter existieren, posten, migrieren und doch für die relevante Öffentlichkeit praktisch ausgelöscht werden, weil ein dominanter AppView ihn deindexiert, schwer labelt oder systematisch aus Discovery und Feed inclusion fernhält. Der technische Status „Konto existiert“ ist dann politisch fast bedeutungslos. Wer Freiheit ernst nimmt, darf diese Schicht nicht als blosses Präsentationsdetail behandeln. Schwere Visibility-Entscheide müssen dokumentiert, erklärbar, prüfbar und anfechtbar werden. Sonst ist der AppView der stille Souverän des Systems.20

Ein drittes Missbrauchsszenario liegt in der Datenhaltung selbst. Retention ist nicht nur eine lästige juristische Fussnote, sondern der Ort, an dem sich entscheidet, ob begrenzte Sanktionen in dauerhafte Ausschlussinfrastruktur umfallen. W Social nennt in seiner Privacy Notice als Rechtsgrundlagen unter anderem Vertragserfüllung, berechtigtes Interesse und rechtliche Verpflichtungen. Heikel wird es dort, wo identitätsbezogene Enforcement-Artefakte unter Begriffen wie Betrugsprävention, Sicherheit oder „restricted processing“ weiterexistieren und dadurch zwar nicht mehr im engeren Sinne frei verfügbar, aber immer noch produktionswirksam bleiben. Eine solche Konstruktion verwandelt die Aufbewahrung in ein Dauersubstrat künftiger personengebundener Sanktionierung. Darum genügt es nicht, bloss zu versprechen, Korrelationen seien „policy-seitig“ geschützt. Sie müssen technisch separiert, zeitlich hart begrenzt und dem Routinebetrieb entzogen werden.21 22

Minimalgarantien

Daraus ergeben sich die Minimalgarantien, die ein identitätsgestütztes ATProto-Overlay erfüllen müsste, um nicht strukturell freiheitsfeindlich zu werden.

  1. Darf im Betreiber-Backend keine routinemässig verfügbare stabile Personen-Korrelation vorliegen.
  2. Muss Moderation standardmässig accountbezogen bleiben und darf nicht über stille Rückkanäle auf menschliche Identität eskalieren.
  3. Darf Cross Account Enforcement, wo es für schweren Missbrauch oder gesetzlich relevante Konstellationen überhaupt erwogen wird, kein normaler Komfortmechanismus der Routine-Moderation sein. Es muss ein ausnahmsweiser, eng begrenzter, hochschwelliger, protokollierter und auditierbarer Vorgang sein. „Higher institutional thresholds“ dürfen dabei keine wohlklingende Leerstelle bleiben. Gemeint ist ein Eskalationspfad, der sich von normalem Plattformmanagement trennt, etwa über gerichtliche Anordnung, eine formell konstituierte Eskalationsinstanz mit unveränderlichem Audit Trail oder eine ähnlich eng abgegrenzte ausserordentliche Prozedur.
  4. Müssen identitätsbezogene Enforcement-Artefakte hart zeitlich begrenzt, technisch separiert und für gewöhnliche Onboarding- und Moderationspfade unbrauchbar gemacht werden.
  5. Brraucht die AppView-Schicht dokumentierte Indexing Policies, verifizierbare Audit-Logs und interoperable Offenlegung schwerer Sichtbarkeitsentscheidungen.
  6. Braucht das System sinnvolle Exit-, Reset-, Appeal- und Recovery-Pfade, damit ein Nutzer nicht auf Dauer in einem alten Diskurskörper festgeschraubt bleibt.
  7. Muss personengebundene Exklusion strukturell schwierig, ausserordentlich, auditierbar, zeitgebunden und anfechtbar werden statt routinemässig, still, persistent und leicht replizierbar.

An dieser Stelle verläuft die harte Grenze zwischen dem, was Kryptographie leisten kann, und dem, was ihr strikt entzogen ist. Kryptographie kann Unlinkability unterstützen, die Wiederverwendbarkeit bestimmter Onboarding-Artefakte begrenzen, lokale Schlüsselhoheit stärken und expired oder deleted correlation artifacts technisch unbrauchbar machen. Sie kann also einen Teil der Freiheitsverluste erschweren, manchmal sogar aus der Routine herausoperieren. Sie kann aber keine faire Moderation erzwingen. Sie kann keinen böswilligen Betreiber zur Zurückhaltung verpflichten. Sie kann AppView-Willkür nicht automatisch neutralisieren. Sie kann keinen Fork davon abhalten, dieselbe offene Basis zu übernehmen und anschliessend jede freihaltende Regel bewusst zu ignorieren. Und sie kann politische Macht, institutionellen Zugriff und opportunistische Betreiberlogik nicht auflösen. Wer so tut, als lasse sich die Frage allein durch elegantere Kryptographie erschöpfen, verwechselt Werkzeuge mit Verfassungsersatz.

Forks

Gerade die Fork-Frage zeigt die Grenze aller Technikromantik. Ein gutes Minimalmodell ist wertvoll, aber kein weltgeschichtliches Sakrament. Ein späterer Betreiber oder ein nachgelagerter Fork kann dieselbe offene Basis übernehmen und die Garantien bewusst unterlaufen. Dann endet die Reichweite der Protokollmoral, und der schwierigere Teil beginnt: Architekturtransparenz, Auditierbarkeit, dokumentierte Interoperabilitätsregeln, institutionelle Trennung, vertragliche Bindung und, wo anders nicht mehr zu helfen ist, wenige harte regulatorische Schranken. Entscheidend ist dabei die Masshaltung. Nicht zehntausend Detailpflichten bis auf API- oder Record-Ebene sind gefragt. Solche Regime ersticken Systeme regelmässig eher, als dass sie Macht begrenzen. Gefragt sind einige wenige Invarianten, die den gefährlichsten Freiheitsverlust strukturell erschweren: keine routinemässige menschliche Korrelation in der Moderation, keine stillen dauerhaften Re-Registration-Sperren, keine unprüfbare AppView-Souveränität, keine retention-seitige Dauerverfügbarkeit personengebundener Sanktionssubstrate.

Föderation

Diese Einsicht verschärft sich noch einmal im föderierten Mehrbetreiberraum. Es genügt nicht, dass einzelne kleinere PDS oder lokale Betreiber die Freiheitsgarantien respektieren. Ein dominanter AppView, ein zentraler Relay oder eine grosse Discovery-Schicht kann sie praktisch neutralisieren. Wer Konten formal weiterexistieren lässt, aber die relevanteste Sichtbarkeit kontrolliert, hält die eigentliche Zensurmaschine nicht im Protokoll, sondern in der Indexierung. Die Machtfrage liegt also nicht nur in der Provisionierung von Konten, sondern in der Konstruktion von Öffentlichkeit selbst. Multi Operator Federation ist daher kein netter Randaspekt, sondern eine Nagelprobe des gesamten Modells. Freiheitsgarantien müssen nicht nur lokale Betreiberpflichten sein, sondern interoperable Beschränkungen auf der Ebene von Sichtbarkeitsgovernance, Disclosure und Review. Ein möglicher späterer technischer Weg bestünde in standardisierten, verifizierbaren Visibility Action Records oder funktional äquivalenten auditierbaren Formaten.

W Social und Schlussbemerkungen

W Social zeigt damit weniger einen exotischen Sonderfall als ein Muster. Das offene oder offene-nahe soziale Protokoll wird nicht erst dann politisch heikel, wenn im Code offen „Lebenslang-Sperre“ hineingeschrieben stünde. Heikel wird es dort, wo Identität, Moderation, Sichtbarkeit, Retention und institutioneller Zugriff in demselben Betreiberraum oder in leicht koppelbaren Räumen zusammenlaufen. Genau an dieser Stelle berührt die Frage den grösseren Themenkomplex, der in meinen früheren Texten zum harten Kern der Freiheit,23 zur engeren Fassung der Freiheit24 und zum Rand des Verfassungsminimums25 bereits angelegt war: Freiheit kippt selten zuerst spektakulär. Sie kippt strukturell, administrativ, indexierend, archivierend. Nicht der grosse offene Ausnahmezustand ist der Normalfall, sondern die stille Bündelung von Hebeln, mit denen dieselbe Person gleichzeitig identifiziert, bewertet, sichtbar gemacht, unsichtbar gemacht, aufbewahrt und wiedererkannt werden kann.

Darum ist die Antwort auf identitätsgestützte soziale Systeme weder naive Entwarnung noch regulatorische Totalmobilmachung. Gebraucht wird ein Architekturdenken, das den Gegenstand nüchtern sortiert. Das offene Protokoll ist nicht der Feind, aber auch kein Freiheitsgarant aus eigener Kraft. Die Identitätsprüfung ist nicht an sich bereits tyrannisch, kann aber in Verbindung mit einer stabilen Backend-Korrelation genau jene dauerhaften Ausschlussmechanismen hervorbringen, vor denen sie sich zugleich rhetorisch zu schützen behauptet. Moderation ist unvermeidlich, wird aber freiheitsfeindlich, sobald sie vom Konto auf die Person übergreift. Sichtbarkeit ist technisch vermittelbar, wird aber politisch entscheidend, sobald dominante AppViews sie als stillen Sanktionsraum bewirtschaften. Datenhaltung ist betriebliche Notwendigkeit, wird aber zur Exklusionsinfrastruktur, sobald retained correlation material produktionsnah erhalten bleibt.

Am Ende bleibt deshalb ein vergleichsweise einfacher Satz, der freilich härter ist, als er klingt. Ein freiheitsschonendes identity gated Overlay braucht keine Erlösungsmetaphysik, sondern Minimalgarantien. Es braucht ein Threat Model statt Schlagwortkaskaden. Es braucht eine strikte Grenzziehung zwischen verifizierter Person und öffentlicher Diskursidentität. Es braucht Moderation, die standardmässig am Konto endet. Es braucht Retention, die nicht zum heimlichen Dauerarchiv personengebundener Sanktionen wird. Es braucht Sichtbarkeitsmacht, die begründet, protokolliert und angefochten werden kann. Und es braucht die Einsicht, dass Kryptographie Werkzeuge bereitstellt, aber weder Tugend noch Freiheit garantiert. Wo zuvor viel über Identität, Bannpersistenz und Krypto gesprochen wurde, liegt damit wenigstens ein minimales Architekturmodell vor, das den Gegenstand schärfer fasst.

In eigener Sache

Analysen dieser Art entstehen nicht aus Luft, nicht aus institutionell finanzierter Gelassenheit und auch nicht aus jener akademischen Gemütlichkeit, in der man nach Belieben zwischen Modellzugang, Rechenzeit und Infrastruktur wechseln kann, ohne jemals die Rechnung zu sehen. Sie kosten reales Geld. Sie kosten Zeit. Sie kosten Konzentration. Sie kosten Server. Sie kosten Modellzugänge. Sie kosten die gesamte technische Umgebung, in der diese Arbeit überhaupt möglich bleibt.

Meine gesamte Infrastruktur läuft unter ausschliesslich meiner Hoheit und nach meinen eigenen CISS-Standards. Das betrifft Nameserver, DNS-Resolver, Gitea, GitLab, Blog, E-Mail, Videokonferenz und weitere Dienste. Diese Souveränität ist kein Hobby. Sie ist Bedingung meiner Unabhängigkeit. Gleichzeitig werde ich von Unternehmen ebenso wie von alternativen Medien gemieden, obwohl diese Arbeit erkennbar nicht dem Lager, sondern dem besseren Argument verpflichtet ist. Persönlich halte ich dieses Verhalten für unerträglich.

Hinzu kommt mein eigener Rechtsstreit, der seit drei Jahren stillsteht. Auch dieser Fall bindet Ressourcen, Zeit und Geld, die längst erschöpft sind, weil Untätigkeit, Verschleppung und institutionelle Gleichgültigkeit sich zuverlässig zu Lasten des Einzelnen organisieren. Wer möchte, dass solche Analysen weiter entstehen, sollte sich keiner Illusion hingeben: Ohne Unterstützung werde ich diese Arbeit nicht weiter fortsetzen können, denn es ist bereits viertel nach zwölf für meine persönliche Situation.

Unterstützungsmöglichkeiten

https://www.gofundme.com/f/rechtsverteidigung-existenzsicherung-arbeitsgericht-lisbon

Oder direkt hier:

Spenden

Mille fois an alle Spender.

Quellen

  1. W Social, Privacy Notice, Stand 20. März 2026. Belegt insbesondere die Pflicht zur verifizierten menschlichen Identität, die Rolle von W Identity als separate Verantwortliche, die Übermittlung von W Identity UUID, Passland und Geburtsjahr sowie die Verarbeitung von Social Graph Data einschliesslich Mute und Block Lists. https://wsocial.eu/public/privacy-notice ↩︎
  2. AT Protocol, DID Specification. Belegt DIDs als persistente, langfristige Kontenidentifikatoren und damit die Protokollebene der Identität jenseits realweltlicher Personenverifikation. https://atproto.com/specs/did ↩︎
  3. AT Protocol, Accounts Specification. Belegt Account Lifecycle, PDS-Hosting, Migrationsmöglichkeit und den Umstand, dass redistribuierende Dienste ihren Scope an Accounts und Inhalten selbst bestimmen.https://atproto.com/specs/account ↩︎
  4. Siehe Fn. 1. ↩︎
  5. Bluesky Documentation, Federation Architecture. Belegt die funktionale Trennung von PDS, Relay und AppView sowie die Rolle des Relay als grossen Datenstrom für weitere Dienste. https://docs.bsky.app/docs/advanced-guides/federation-architecture ↩︎
  6. Minimum Structural Guarantees for Identity Gated ATProto Compatible Social Systems, High Level Architecture Proposal, Public Version 20260508-0000-Final. Eigenes konzeptionelles Arbeitsdokument, dient nicht als Primärquelle über den Ist-Zustand von W Social, sondern als Minimal-Guarantees-Framework für den hier entwickelten Soll-Rahmen. ↩︎
  7. Siehe Fn. 2. ↩︎
  8. Siehe Fn. 3. ↩︎
  9. Bluesky Documentation, Labels and Moderation. Belegt die mehrschichtige Moderationsarchitektur aus Network Takedowns, Labels und User Controls sowie die Rolle von Labelern und die Möglichkeit, Accounts oder Records zu adressieren. https://docs.bsky.app/docs/advanced-guides/moderation ↩︎
  10. Siehe Fn. 5. ↩︎
  11. Siehe Fn. 1. ↩︎
  12. Siehe Fn. 9. ↩︎
  13. Siehe Fn. 5. ↩︎
  14. Siehe Fn. 6. ↩︎
  15. Siehe Fn. 3. ↩︎
  16. Siehe Fn. 9. ↩︎
  17. Siehe Fn. 5. ↩︎
  18. Siehe Fn. 6. ↩︎
  19. Siehe Fn. 6. ↩︎
  20. Siehe Fn. 6. ↩︎
  21. Siehe Fn. 1. ↩︎
  22. Siehe Fn. 6. ↩︎
  23. Marc Weidner, „Die Verfassung. Der harte Kern der Freiheit“, CenturionBlog, 4. Mai 2026. Verwendet als argumentative Anschlussstelle für den Gedanken, dass Freiheitsverluste dort beginnen, wo Informationsasymmetrie, Transparenzdefizite und strukturell konzentrierte Zugriffswerkzeuge zusammenfallen. https://coresecret.eu/2026/05/04/die-verfassung-der-harte-kern-der-freiheit/ ↩︎
  24. Marc Weidner, „Die Verfassung. Freiheit in engerer Fassung“, CenturionBlog, 5. Mai 2026. Verwendet als Anschlussstelle für die Frage, welche begrenzten, präzisen Schranken eine freie Ordnung plausibel ziehen muss, ohne selbst in kontrollierende Überdehnung zu kippen. https://coresecret.eu/2026/05/05/die-verfassung-freiheit-in-engerer-fassung/ ↩︎
  25. Marc Weidner, „Die Verfassung. Am Rand des Verfassungsminimums“, CenturionBlog, 5. Mai 2026. Verwendet als Anschlussstelle für die systemische Einsicht, dass moderne Machtverluste häufig administrativ, institutionell und infrastrukturell erfolgen, nicht erst im offenen Ausnahmezustand. https://coresecret.eu/2026/05/05/die-verfassung-am-rand-des-verfassungsminimums/ ↩︎

Proposal Minimum Structural Guarantees

2026.05.08_W_Social_Proposal_Final_signed

Changelog

08.05.2026Initial Version
Categories: Digitalisierung, EU, EU-Kommission, Gesellschaft, IT, IT-Security, Justiz, Kryptographie, Propaganda, Regulierung, Sicherheitsbehörden, Wissenschaft, Zensur
Tags: , , , , , , ,

You may also like

Search: