florianthepro/buergerabstimmung

Fork 0

Files

T

floriantheproandGitHub 4cfe4f18a2 Create whitepaper.md

2026-08-04 09:32:59 +02:00

45 KiB

Raw Permalink Blame History

Bürgerabstimmung — Whitepaper

Digitale Bürgerbeteiligung mit dem Personalausweis. Themen einbringen, abstimmen, gemeinsam prüfen.


Arbeitstitel / Marke	Bürgerabstimmung
Domain (vorgeschlagen)	buergerabstimmung.de (Alternativen: buergerabstimmung.eu, abstimmungsportal.de)
Status	Konzept & technischer Prototyp (Testbetrieb, keine offizielle Seite einer Behörde)
Sprachen	Deutsch (Standard), Englisch
Version	1.0 · August 2026

Wichtiger Hinweis: Bürgerabstimmung ist ein privates Konzept- und Demonstrationsprojekt. Es ist keine offizielle Seite der Bundesregierung oder einer Behörde und erhebt nicht den Anspruch, staatliche Verfahren rechtlich zu ersetzen. Der Prototyp zeigt, wie eine solche Plattform funktionieren könnte. Solange der Testbetrieb läuft, zeigt die Seite dauerhaft ein entsprechendes Hinweisbanner an (im Code über die Konfigurationsvariable show_test_banner = true gesteuert). Eine frische Installation startet im Testmodus; er wird über die Oberfläche beendet und löscht dabei alle bis dahin entstandenen Testdaten (Kapitel 5.3b).

1. Zusammenfassung

Bürgerabstimmung ist eine Plattform für direkte, fortlaufende Bürgerbeteiligung. Jede Person mit deutschem Personalausweis kann:

Themen einbringen — maximal eines pro Tag, mit Ziel, Begründung, Kategorie und räumlicher Ebene (Landkreis/kreisfreie Stadt, Bundesland, Deutschland; die Gemeindeebene folgt in der Ausbaustufe),
abstimmen — dafür oder dagegen; wer sich enthält, stimmt schlicht nicht ab,
rechtswidrige Inhalte melden — geprüft nicht von einer Redaktion, sondern von einer zufällig ausgelosten Bürger-Jury (1 % aller aktiven Ausweis-Pseudonyme),
seine Gesamtansicht abrufen — durch Auflegen des Ausweises (NFC) erscheinen alle eigenen Themen, Stimmen und Favoriten.

Die Identität wird ausschließlich über die eID-Funktion des Personalausweises nachgewiesen: Der Chip beweist kryptographisch die Echtheit der Karte (privater Schlüssel im Chip). Die Plattform kennt als Identität nur den öffentlichen Schlüssel — keinen Namen, keine Adresse, kein Geburtsdatum, kein abgeleitetes Pseudonym. Eine Karte = ein Konto. Das persönliche Profil wird an diesen öffentlichen Schlüssel verschlüsselt und vom Server signiert (manipulationssicher); die Stimmen werden unverkettbar gespeichert, sodass niemand rückschließen kann, wer wie gestimmt hat.

Die Plattform ist bewusst schlicht und amtlich-neutral gestaltet, funktioniert gleichwertig auf Smartphone und PC, passt sich hellem und dunklem Systemdesign an und ist auch an öffentlichen Geräten (z. B. in Gemeindebüros oder Bibliotheken) nutzbar — für Menschen ohne eigenes Gerät.

2. Marke, Domain, Gestaltung

2.1 Name

Bürgerabstimmung — bewusst kein Kunstwort und keine Marke, sondern die schlichte Sachbezeichnung: Bürgerinnen und Bürger stimmen ab. So würde eine Verwaltung die Sache benennen, und genau das ist der Zweck des Namens — er verspricht nichts, was er nicht ist.

Bewusst nicht gewählt wurden „Wahl…“ und „Bürgerentscheid“: Beides sind rechtlich belegte Begriffe für verbindliche Verfahren nach Wahl- und Gemeinderecht. Diese Plattform ist ein Meinungsbildungs-Kanal ohne Rechtsverbindlichkeit; ein Name aus dem Wahlrecht würde eine Wirkung suggerieren, die sie nicht hat.

Zugleich ist der Name nicht mit staatlichen Kennzeichen verwechselbar: kein Bundesadler, keine Bundesfarben-Imitation, kein „bund.de“-Look. Vor einem echten Betrieb sind Marken- und Domainrecherche erforderlich — die reine Sachbezeichnung ist als Wortmarke voraussichtlich nicht schutzfähig, was für diesen Zweck kein Nachteil ist.

2.2 Domain

Vorschlag: buergerabstimmung.de (Sachbezeichnung, aussprechbar, .de passt zum Zweck). Ausweichoptionen: buergerabstimmung.eu, buerger-abstimmung.de, abstimmungsportal.de. Im Auslieferungszustand ist in der Konfiguration keine Domain eingetragen — sie wird erst beim Aufsetzen gesetzt.

2.3 Gestaltungsprinzipien

Schlicht wie eine App: ruhige graue Fläche, weiße Karten mit weichen Ecken, Haarlinien statt Rahmen, Systemschrift, ein blauer Akzent — die Formensprache verbreiteter Messenger-/Systemoberflächen (iOS, Signal). Keine Verläufe, keine Deko-Effekte, keine „KI-Regenbogen“-Ästhetik; Rot bleibt destruktiven Aktionen (Löschen) vorbehalten, Gelb allein dem Testbetrieb-Banner.
Keine KI-Hinweistexte auf der Seite. Die Seite spricht als Produkt, nüchtern und in Sie-Form. Es steht nur Text da, der eine Entscheidung trägt: Erklärsätze unter selbsterklärenden Überschriften, Wiederholungen von Zahlen und Beschriftungen wie „Eingebracht am“ entfallen.
Hell/Dunkel automatisch: Das Design folgt ausschließlich der Systemeinstellung (prefers-color-scheme) — es wird bewusst nichts im Browser gespeichert, auch keine Design-Präferenz.
Symbolhafter Einstieg: Beim Sitzungsbeginn nur der Schriftzug und die Sprachwahl — Deutsch/English als Knöpfe mit Flagge, ohne Bildmarke; die Anmeldung führt ein Ausweis-Piktogramm mit NFC-Wellen an, Text bleibt minimal. Die Kopfzeile der Seite trägt weder Wortmarke noch Anmeldestatus, sondern nur die nötigen Bedienelemente; die Fußzeile nur Impressum und Datenschutz. Das Impressum trägt im Prototyp bewusst nur einen Platzhalter (ein * als Überschrift und als Text) — es ist vor einem echten Betrieb mit den Pflichtangaben des Betreibers zu füllen, die Datenschutzerklärung ist an den tatsächlichen Betrieb anzupassen.

Bildmarke (Tab-/App-Icon): ein Häkchen im Feld — scharfe Kanten, keine abgerundeten Ecken, keine Farbe. Als SVG folgt es der Systemeinstellung (schwarze Fläche mit weißem Kreuz im Hellmodus, weiße Fläche mit schwarzem Kreuz im Dunkelmodus); PNG und ICO für Safari/iOS liefern dieselbe Marke als geschlossene dunkle Kachel.
Responsiv: eine Codebasis für Smartphone, Tablet, PC und Terminals. Die tragenden Funktionen — anmelden, Thema einbringen, abstimmen, melden, Jury — laufen ohne JavaScript; alle Fenster sind :target-Dialoge, alle Eingaben normale Formulare. JavaScript ergänzt: Countdown, NFC-Auslösung, die stufige Geltungsbereichs-Auswahl, die Live-Zahlen und den Hinweis auf ähnliche Themen. Eine Ausnahme: die profil.yaml wird ausschließlich per fetch geladen — ohne JavaScript gibt es keine Selbstauskunft. Das ist vor einem Echtbetrieb zu ergänzen.
Testbetrieb-Banner: Solange die Konfigurationsvariable show_test_banner auf true steht (Auslieferungszustand), zeigt jede Seite oben ein deutliches Banner: „Testbetrieb — keine offizielle Seite der Bundesregierung oder einer Behörde.“ Der Testmodus selbst ist keine Variable, sondern ein Zustand der Installation (Kapitel 5.3b).
Barrierearmut: semantisches HTML, Tastaturbedienung, ausreichende Kontraste. Die Abstimmungsbalken nutzen Akzentblau gegen Neutralgrau — auf Farbfehlsichtigkeit geprüft (CVD-Abstand ΔE 18,3 hell / 16,6 dunkel) — und tragen immer Beschriftung samt Prozentwert; Bedeutung hängt nie an Farbe allein. Vollständige BITV-Konformität ist Ziel der Ausbaustufe.

3. Leitidee und Einordnung

Bürgerabstimmung versteht sich als ständiger Meinungsbildungs-Kanal: Statt alle vier Jahre ein Kreuz zu machen, können Bürgerinnen und Bürger laufend Anliegen einbringen und gewichten — von der Radweg-Frage in der Gemeinde bis zur bundespolitischen Grundsatzfrage. Die Ergebnisse sind ein präzises, manipulationsarmes Stimmungsbild, das Politik auf allen Ebenen nutzen kann.

Bewusste Abgrenzung:

Bürgerabstimmung ersetzt keine rechtlich bindenden Verfahren (Wahlen, Volksentscheide). Ergebnisse sind Meinungsbilder; eine rechtliche Bindung wäre ein politischer Folgeschritt, kein technischer.
Die Plattform ist strikt neutral: Zum Start existieren ausschließlich Kategorien über das gesamte politische Spektrum, keine vorbefüllten Themen (siehe 6.3); die Moderation erfolgt durch geloste Jurys nach strafrechtlichen — nicht politischen — Kriterien.

4. Zugänge und Zielgruppen

Smartphone: Ausweis per NFC ans Gerät halten, PIN in der eID-App eingeben, fertig. Der Browser selbst berührt die Karte nie.
PC: eID-Client (z. B. AusweisApp) mit USB-Kartenleser oder gekoppeltem Smartphone als Leser.
Öffentliche Geräte: Gemeinden, Bürgerbüros und Bibliotheken können Terminals bereitstellen. Dafür ausgelegt: kurze Sitzungen, automatische Abmeldung nach Inaktivität, keine lokalen Datenspuren, prominenter Abmelden-Knopf.
Fremde Geräte: Da die Anmeldung nur mit physischer Karte + PIN funktioniert und keine Passwörter existieren, kann bedenkenlos das Gerät einer anderen Person genutzt werden.

Sprachen: Deutsch und Englisch. Die Wahl erfolgt beim Sitzungsbeginn, gilt für die Sitzung und wird nirgends gespeichert — weder im Browser noch am Konto. Ohne aufgelegten Ausweis ist die Seite nicht sichtbar (nur Anmeldung und Rechtliches sind offen).

5. Identität: die eID des Personalausweises

5.1 Prinzip

Jeder deutsche Personalausweis (seit 2010) enthält einen Chip mit Online-Ausweisfunktion (eID). Die Echtheit beweist der Chip kryptographisch: Er besitzt private Schlüssel, die das Chipmaterial nie verlassen, und die Gegenseite prüft die zugehörigen Zertifikate gegen die staatliche Zertifikatskette (Country Verifying CA / Document Verifier, BSI-Standards TR-03110, TR-03130). Kopierte oder gefälschte Karten fallen bei dieser Prüfung durch.

Für Bürgerabstimmung entscheidend ist die Funktion „dienstespezifisches Kennzeichen“ (Restricted Identification): Der Chip errechnet pro Dienst ein stabiles Pseudonym.

Dasselbe Pseudonym bei jedem Anhalten derselben Karte bei Bürgerabstimmung → ein Konto pro Karte, Wiedererkennung ohne Klarnamen.
Ein anderes Pseudonym bei jedem anderen Dienst → keine Verkettbarkeit über Dienste hinweg.
Bürgerabstimmung fragt keine Klardaten ab (kein Name, keine Anschrift, kein Geburtsdatum). Es wird auch kein eigenes Pseudonym erzeugt oder zugeordnet: Identität ist unmittelbar der öffentliche Schlüssel („on the go“); Stimmen werden auf dem Server direkt für diesen Schlüssel eingetragen.

5.2 Ablauf (Produktion)

Nutzer wählt „Ausweis auflegen“. Die Plattform startet über den eID-Client (AusweisApp, Schnittstelle nach TR-03124) eine Authentisierung beim zugelassenen eID-Server (TR-03130).
Nutzer hält die Karte an das NFC-Smartphone bzw. den Kartenleser und gibt die sechsstellige Ausweis-PIN ein.
Chip und eID-Server authentisieren sich gegenseitig (PACE, Terminal- und Chip-Authentisierung); der eID-Server prüft Echtheit und Sperrliste und übermittelt Bürgerabstimmung nur das Pseudonym.
Bürgerabstimmung nimmt den geprüften öffentlichen Schlüssel unmittelbar als Kennung und meldet die Sitzung an.

Voraussetzung für den Echtbetrieb ist ein Berechtigungszertifikat der Vergabestelle für Berechtigungszertifikate (Bundesverwaltungsamt) mit dem Berechtigungsumfang „pseudonymer Zugang“ sowie ein zertifizierter eID-Server (eigenbetrieben oder als Dienstleistung).

5.3 Prototyp (dieses Repository)

Der Prototyp bildet das Verfahren originalgetreu nach: Eine simulierte Testkarte im Browser übernimmt die Rolle des Chips und hält ein echtes Ed25519-Schlüsselpaar (libsodium). Beim „Ausweis auflegen“ signiert der private Schlüssel eine Zufallsnachricht; der Server prüft die Signatur gegen den öffentlichen Schlüssel und leitet daraus das Pseudonym ab. Zwei getrennte Vorgänge:

Profil laden (initiales Anhalten): Die statische Challenge ist der öffentliche Schlüssel selbst, zeitgebunden versiegelt. Der Server öffnet den Nachweis mit dem öffentlichen Schlüssel und liefert die profil.yaml (alle eigenen Stimmen, Themen, Favoriten, Jury-Status) in den Browser; der Abmelde-Knopf löscht sie dort wieder. Der Nachweis ist TOTP-artig zeitbegrenzt (5-Minuten-Fenster, Anmeldung gilt höchstens zwei Fenster) — danach ist erneutes Anhalten nötig.
Stimmabgabe und jede andere Änderung (unabhängig davon): Die Karte erstellt je Vorgang einen versiegelten Umschlag (kombinierte Signatur über Aktion + Zeitfenster + Zufallswert); der Server öffnet ihn mit dem öffentlichen Schlüssel und trägt die Stimme für genau diesen Schlüssel ein. Derselbe Vorgang ergibt zu anderer Zeit einen anderen Umschlag; alte Umschläge verfallen.

Zusätzlich trägt jedes Formular ein Einmal-Token (beim Einlösen verbraucht — Wiederholungen laufen ins Leere), und im Browser liegt außer der Sitzungs-ID nur die bewusst geladene profil.yaml. Am Smartphone ist der NFC-Leser auf der Anmeldeseite automatisch scharf: Das Auflegen des (echten) Personalausweises löst die Anmeldung direkt aus (Web NFC; der Knopf bleibt Rückfall und Berechtigungsgeste).

5.3b Testmodus als Zustand, nicht als Variable

Eine frische Installation startet im Testmodus. Er ist kein Schalter in der Konfigurationsdatei, sondern ein Zustand in der Datenbank (schema_info.test_mode), damit eine Vorführung ohne Codeänderung möglich ist und der Übergang in den Echtbetrieb protokolliert wird.

Im Testmodus zeigt die Anmeldeseite genau einen Knopf. Er erzeugt eine zufällige, als gültig behandelte Sitzung; Ausweis-Aufforderungen bei Änderungen entfallen. Das Banner bleibt unabhängig davon sichtbar.
Beendet wird er über die Oberfläche: Der Chip „Testmodus“ in der Kopfzeile führt auf die Seite „Echtbetrieb einrichten“ (Kapitel 5.3c). Dort wird der Zugang für den Echtbetrieb festgelegt, geprüft und umgeschaltet. Das Umschalten löscht alle im Testbetrieb entstandenen Daten — Themen, Stimmen, Merkzettel, Meldungen, Jury-Sitze, Konten und die im Testmodus erzeugten Ausweis-Schlüssel. Kategorien, System-Konto und eine echte Freigabeliste bleiben. Der Schritt ist bewusst nicht umkehrbar.
Danach existiert kein Weg mehr in die Anwendung, der ohne Ausweis auskommt: Die Anmeldeseite bietet nur noch die Ausweis-Apps an, und die Einrichtungsseite ist geschlossen.

5.3c Einrichtung des Echtbetriebs aus der Anwendung heraus

Der Übergang vom Testbetrieb zum Echtbetrieb ist kein Eingriff in den Quelltext, sondern ein geführter Schritt in der Oberfläche. Die Seite „Echtbetrieb einrichten“ leistet dreierlei:

Voraussetzungen prüfen. Sie zeigt, ob das Datenverzeichnis beschreibbar ist, HTTPS anliegt, die Kryptographie-Erweiterung vorhanden ist, der Zugriffsschutz greift und wie viele Ausweis-Schlüssel freigegeben sind.
Zugang festlegen. Zur Wahl stehen der eigene eID-Server (Anmeldung über die Ausweis-App; setzt Berechtigungszertifikat und einen Server nach TR-03130 voraus) und die eigene Trust-Liste (Anmeldung nur mit Schlüsseln aus der Freigabeliste, befüllt über eine Abgleich-Adresse oder issue-card). Erfasst werden SOAP-Adresse, Client-Zertifikat und -Schlüssel, die Aktivierungsadresse der Ausweis-App, die Abgleich-Adresse der Freigabeliste und die Startadresse von Nect. Ein Knopf prüft die Verbindung zum eID-Server, bevor irgendetwas verändert wird.
Umschalten. Erst wenn die Eingaben gültig sind, der eID-Server antwortet und der Einrichtungsschlüssel stimmt, werden die Einstellungen nach data/config.yaml (Rechte 0600, vom Web nicht erreichbar) geschrieben, die Testdaten gelöscht und der Echtbetrieb dauerhaft aktiviert.

Der Einrichtungsschlüssel steht in data/setup.token und ist nur über Dateizugriff oder php index.php setup-token lesbar. Damit kann das Umschalten nur, wer den Server betreibt — nicht jeder, der sich im Testbetrieb per Knopfdruck eine Sitzung erzeugen kann. Nach dem Umschalten wird die Datei gelöscht.

Die Einstellungen aus config.yaml überlagern beim Start die Vorgaben im Quelltext; übernommen wird ausschließlich eine feste Liste erlaubter Schlüssel. php index.php config zeigt den wirksamen Stand.

Der Wechsel auf einen echten eID-Server ersetzt nur den Karten-Block; Regeln und Abläufe bleiben identisch.

5.3d Anbindung der AusweisApp (TR-03124/TR-03130)

Die Anmeldung mit der AusweisApp ist direkt eingebaut und braucht auf der Serverseite nichts als den Webserver und diese Datei:

Der Knopf „Mit AusweisApp anmelden“ leitet den Browser auf die Aktivierungsadresse des eID-Clients nach TR-03124: http://127.0.0.1:24727/eID-Client?tcTokenURL=…. Die AusweisApp — am PC wie am Smartphone — fängt diese Adresse ab.
Die App holt das tcToken unter /eid/tctoken ab. Sie tut das als eigener HTTP-Client ohne Browser-Cookie; deshalb trägt die tcTokenURL einen Einmal-Nonce (10 Minuten gültig), der Browsersitzung und Ausweis-Vorgang verbindet.
Mit hinterlegtem eID-Server (TR-03130, eid_server_url) fordert der Server dort per useID eine Sitzung an und liefert der App ServerAddress, SessionIdentifier und RefreshAddress. Die App liest den Chip PIN-geschützt aus und schickt den Browser zurück auf /eid/callback.
Ohne eID-Server liefert das tcToken bewusst nur eine CommunicationErrorAddress. Die AusweisApp bricht sauber ab, der Browser kehrt zurück — angemeldet wird niemand. Das ist die ehrliche Grenze: Einen eID-Server darf nur betreiben, wer ein Berechtigungszertifikat des BVA besitzt (Kapitel 5.3e).

5.3e Autorisierte Schlüssel (Freigabeliste) und ehrliche Grenzen der eID

Anmelden kann sich ausschließlich, wessen öffentlicher Schlüssel in einer serverseitigen Allowlist steht (data/authorized_keys.yaml) und wer den passenden privaten Schlüssel besitzt (zeitgebundene Signatur-Challenge). Damit ist ausgeschlossen, dass ein Knopfdruck ohne Ausweis oder mit einem fremden/gefälschten Schlüssel Zugang gewährt (fail-closed).

Ehrliche Einordnung zur oft gewünschten „Liste aller Ausweis-Schlüssel“: Eine solche staatliche Liste existiert nicht und wäre auch nicht wünschenswert (sie wäre ein Register der kryptographischen Identität aller Bürgerinnen und Bürger). Der Personalausweis weist sich stattdessen über die BSI-Zertifikatskette (TR-03110: Chip-Authentisierung gegen CVCA/DV) aus, geprüft durch einen zertifizierten eID-Server (TR-03130); das Auslesen des Chips erfolgt PIN-geschützt ausschließlich über die AusweisApp (ein Browser kann den Chip nicht lesen). Im Prototyp ist die Allowlist deshalb der Platzhalter für genau diese Vertrauensprüfung: Der Modus eid übergibt an den eID-Server/die AusweisApp; der Modus demo nutzt per issue-card ausgegebene, autorisierte Test-Ausweise. Die Funktion sync-keys ist der Anschlusspunkt für eine eigene Trust-Liste bzw. eID-Server-Anbindung – kein Zugriff auf ein Behördenregister.

5.4 Grenzen und Missbrauchsszenarien

Karte ≠ Person am Gerät: Wie bei jeder eID-Nutzung kann eine Person freiwillig ihre Karte + PIN einer anderen überlassen. Das ist rechtswidrig, skaliert aber schlecht (physische Karte nötig) — genau dadurch werden Bot-Netze und Massen-Manipulation wirksam verhindert.
Verlorene/gesperrte Ausweise fallen über die Sperrlistenprüfung des eID-Servers heraus.
Alters-/Staatsangehörigkeitsfragen: Die eID steht auch Unionsbürgern (eAT, eID-Karte) offen; ob deren Teilnahme gewünscht ist, ist eine politische Konfigurationsentscheidung (Berechtigungszertifikat kann die Kartentypen einschränken). Der Prototyp behandelt alle Karten gleich.

6. Funktionen im Einzelnen

6.1 Themen einbringen — „1 Thema pro Tag“

Jedes Pseudonym kann ein Thema pro Kalendertag (Zeitzone Europe/Berlin) erstellen; um 00:00 Uhr beginnt der nächste Tag. Die Regel ist zusätzlich zur Anwendungslogik als Datenbank-Constraint verankert (UNIQUE über Autor + Erstelldatum) — sie kann also auch durch Programmierfehler nicht umgangen werden.
Pflichtfelder beim Erstellen:
- Titel (kurz, prägnant),
- Ziel — was soll konkret erreicht werden?
- Begründung — warum?
- Kategorie (siehe 6.3),
- Geltungsbereich — eine hierarchische Auswahl statt Freitext, wie auf Behördenseiten: Deutschland → Bundesland → Landkreis/kreisfreie Stadt (eingebaute Gebietsliste mit allen 16 Ländern und rund 400 Kreisen; die Gemeindeebene folgt in der Ausbaustufe über das amtliche Gemeindeverzeichnis, ARS/Destatis).
Themen sind nach Veröffentlichung unveränderlich. Es gibt keinen Bearbeiten-Weg — weder in der Oberfläche noch als Route. Damit ist die stille Umdeutung einer laufenden Abstimmung ausgeschlossen: Woran abgestimmt wurde, steht fest. Wer sich vertan hat, archiviert das Thema (solange noch keine Stimme abgegeben ist) und bringt es neu ein. Eine spätere Ausbaustufe könnte Korrekturen mit sichtbarer Versionsanzeige erlauben.

6.2 Abstimmen

Pro Thema und Ausweis genau eine Stimme: dafür oder dagegen.
Neutral = nicht abstimmen. Enthaltung wird nicht als eigene Stimmart gezählt.
Die eigene Stimme ist 24 Stunden lang änderbar oder zurückziehbar; danach ist sie fest (auf der Hauptseite als eigene Gruppe „kürzlich abgestimmt, noch änderbar“ sichtbar).
Stimmen sind unverkettbar gespeichert: In der Datenbank steht kein Ausweis-Bezug, sondern nur ein HMAC aus Thema + öffentlichem Schlüssel mit serverseitigem Geheimnis. Doppelstimmen sind ausgeschlossen, doch ohne das Geheimnis lässt sich nicht rückschließen, welcher Ausweis wie gestimmt hat.
Abstimmungsende je Thema — Datum, Zielwert oder beides: Beim Einbringen sind zwei Bedingungen ankreuzbar: ein Enddatum und ein Zielwert (Einheit „X Stimmen“ für eine feste Zahl oder „% Stimmen“ für einen Anteil der registrierten Ausweise). Gesetzt werden darf eine von beiden oder beide zugleich — dann endet die Abstimmung, was zuerst eintritt. Prozentangaben werden beim Anlegen in eine absolute Zahl umgerechnet, damit das Ziel im Verlauf nicht mit der Nutzerzahl wandert. Für jeden Zielwert gilt zusätzlich eine Untergrenze von 10 Stimmen — auch ein ausdrücklich kleinerer Wert wird stillschweigend darauf angehoben. Danach ist das Thema beendet.
Themen werden nie gelöscht. Es gibt keinen Löschweg für Verfasser. Ein Thema, zu dem noch niemand abgestimmt hat, lässt sich archivieren: Es verschwindet aus Listen, Suche und Ähnlichkeitsabgleich, ist nicht mehr wählbar und nicht mehr meldbar, bleibt aber unter seiner Adresse erhalten und trägt dort die Kennzeichnung „Archiviert“.
Abgestimmte Themen bleiben unverändert bestehen. Sobald die erste Stimme abgegeben ist, entfällt auch das Archivieren — der Knopf ist dann schlicht nicht mehr da. Damit bleibt jedes Thema, über das abgestimmt wurde, dauerhaft nachvollziehbar. (Davon unberührt ist die Entfernung durch eine Bürger-Jury nach festgestelltem Gesetzesverstoß, Kapitel 7.)
Gleiche Titel sind erlaubt, aber sichtbar. Beim Einbringen zeigt das Formular schon während des Tippens, ob es bereits ähnliche Themen gibt, und verlinkt sie; einbringen lässt sich das Thema trotzdem. Auf der Themenseite steht dieselbe Liste unter „Ähnliche Themen“. Der Abgleich vergleicht die bedeutungstragenden Wörter des Titels, nicht die Zeichenkette.
Ergebnisse aktualisieren sich ohne Neuladen. Ein schlanker JSON-Endpunkt liefert Stimmenstände; Liste und Themenseite schreiben Balken, Zahlen und Anteile im Hintergrund fort (alle zwölf Sekunden und beim Zurückkehren auf den Tab). Ohne JavaScript bleibt der beim Aufruf gerenderte Stand stehen — die Seite funktioniert weiterhin vollständig.
Die Darstellung ist überall dieselbe und bewusst knapp: ein Balken, darunter „Dafür n / x %“ und „Dagegen n / y %“ — in der Liste als Haarlinie, auf der Themenseite kräftiger.
Drei Symbole oben rechts am Thema, auf einer Höhe mit den Schildern für Kategorie und Gebiet: ein Lesezeichen zum Merken (Thema, Kategorie, Gebiet), eine Archivbox für den Verfasser eines Themas ohne Stimmen und eine rote Flagge zum Melden. Die Flagge fehlt beim eigenen Thema und bei beendeten Abstimmungen; läuft bereits eine Meldung, steht sie unterlegt und ohne Funktion da. Beschriftungen tragen die Symbole nur als title und aria-label.
Auf der Themenseite steht der eigene Stand in den Knöpfen, nicht in einem Satz. Dort gibt es keinen erklärenden Text zur eigenen Stimme; ihr Zustand ist an den beiden Knöpfen ablesbar: beide grau, solange nicht gewählt wurde; die gewählte Seite blau, solange sie sich noch ändern lässt; nach Ablauf der 24 Stunden und bei beendeter Abstimmung die gewählte Seite blass-blau, die andere abgedunkelt, beide nicht mehr bedienbar. Serverseitig wird eine dann noch abgesetzte Stimme unabhängig davon abgewiesen. In der Themenliste und in der Gruppe „kürzlich abgestimmt“ steht die eigene Stimme dagegen weiterhin als Text („Ihre Stimme: Dafür“, dort mit Frist) — Knöpfe, an denen man sie ablesen könnte, gibt es dort nicht.

6.3 Kategorien — Neutralität durch Breite, keine vorbefüllten Themen

Damit die Plattform von Beginn an nicht als politisch gefärbt wahrgenommen wird, gilt das Breitenprinzip auf Kategorien-Ebene: Zum Start existieren ausschließlich die Kategorien — bewusst viele, quer über das gesamte politische Spektrum. Themen werden nicht vorbefüllt; jeder einzelne Inhalt der Plattform stammt aus der Bürgerschaft. So kann keine Startauswahl als redaktionelle oder politische Setzung gelesen werden.

Kategorien (Start-Satz, erweiterbar):

Umwelt & Klima · Energie · Wirtschaft & Mittelstand · Arbeit & Soziales · Rente & Alterssicherung · Gesundheit & Pflege · Bildung & Forschung · Familie & Jugend · Migration & Integration · Innere Sicherheit · Justiz & Bürgerrechte · Digitales & Verwaltung · Verkehr & Infrastruktur · Wohnen & Mieten · Landwirtschaft & Ernährung · Finanzen & Steuern · Europa & Außenpolitik · Verteidigung · Kultur, Medien & Sport · Verbraucherschutz · Kommunales & Ehrenamt · Demokratie & Beteiligung

6.4 Merkzettel und eigener Stand

Einzelne Themen, Kategorien und Gebiete lassen sich merken: Am Thema steht dafür ein Lesezeichen-Symbol, das ein kleines Auswahlfeld mit drei Einträgen öffnet — dieses Thema, seine Kategorie, sein Gebiet. Gemerktes ist im Feld hervorgehoben und wird durch erneutes Antippen wieder entfernt. Gemerkte Themen führen direkt zurück zum Thema, gemerkte Kategorien und Gebiete filtern die Themenliste; alles ist am Schlüssel gespeichert und steht auf jedem Gerät bereit.
Alles auf einer Seite. Es gibt keine getrennte Unterseite „Meine Übersicht“ mehr; /me und /topics führen auf dieselbe Hauptseite. Dort stehen übereinander: Merkzettel-Chips, die Gruppe „kürzlich abgestimmt (noch änderbar)“ mit der eigenen Stimme und der Frist, und die Themenliste. Eine anstehende Jury-Aufgabe wird über einen Hinweis in der Kopfzeile und eine Weiterleitung auf /jury erzwungen.
Der vollständige eigene Stand — Stimmen, eingebrachte Themen, Merkzettel, Meldungen, Jury-Zuteilungen — wird zusätzlich als profil.yaml ausgeliefert (Kapitel 5.3), verschlüsselt an den eigenen Ausweis-Schlüssel.

6.5 Sprache

Deutsch ist Standard; Englisch vollwertig verfügbar. Die Wahl wird in der Sitzung und — bei angemeldeten Nutzern — am Pseudonym gespeichert.

7. Meldung rechtswidriger Inhalte und Bürger-Jury

7.1 Grundsatz: Recht statt Richtung

Gemeldet werden können mutmaßlich rechtswidrige Inhalte — nicht politische Meinungen. Zur Einordnung, weil danach oft gefragt wird: Auch extreme politische Auffassungen sind in Deutschland nicht als solche strafbar; die Meinungsfreiheit (Art. 5 GG) schützt auch scharfe und radikale Positionen. Strafbar sind konkrete Delikte — und nur an diesen wird gemessen.

Eine Meldung besteht deshalb aus genau einem Grund: dem Verstoß gegen ein Gesetz. Es gibt keinen Auffangtatbestand und keinen Freitext — es wird ausschließlich am zitierten Gesetz bewertet. Beim Melden führt ein Suchfeld (Schlagwort oder Paragraphennummer) zum eingebauten Register; der gewählte Paragraph wird wortgleich (1:1) zitiert und der Jury unverändert vorgelegt.

Das Register umfasst im Prototyp neun Tatbestände des Strafgesetzbuchs:

Norm	Tatbestand
§ 130 Abs. 1 StGB	Volksverhetzung
§ 86a Abs. 1 StGB	Verwenden von Kennzeichen verfassungswidriger und terroristischer Organisationen
§ 111 Abs. 1 StGB	Öffentliche Aufforderung zu Straftaten
§ 185 StGB	Beleidigung
§ 186 StGB	Üble Nachrede
§ 187 StGB	Verleumdung
§ 240 Abs. 1 StGB	Nötigung
§ 241 Abs. 1 StGB	Bedrohung
§ 126a Abs. 1 StGB	Gefährdendes Verbreiten personenbezogener Daten

Das Register ist erweiterbar; die hinterlegten Volltexte sind vor einem Echtbetrieb wortgleich gegen gesetze-im-internet.de abzugleichen.

7.2 Bürger-Jury statt Redaktionsmoderation

Über die Meldung entscheidet keine Redaktion, sondern eine zufällig geloste Jury aus der Nutzerschaft — das Losverfahren (wie beim Schöffenamt) macht gezielte Beeinflussung praktisch unmöglich.

Auswahl:

1 % aller bereits auf der Plattform verwendeten Ausweis-Pseudonyme wird per kryptographisch sicherem Zufall (CSPRNG) gezogen. Die Mindestgröße (Standard: 5) ist ein Zielwert, keine Untergrenze: Sind weniger geeignete Personen verfügbar, besteht die Jury eben aus weniger — notfalls aus zweien. Ebenso kann das Quorum unter den Standardwert 3 fallen, weil es auf die tatsächliche Jurygröße gedeckelt wird. Bei kleiner Nutzerschaft entscheiden also sehr wenige; das ist eine bewusste Abwägung zugunsten der Funktionsfähigkeit und vor einem Echtbetrieb zu überdenken.
Ausgeschlossen sind: Pseudonyme, die bereits einer laufenden Meldung als Jury zugeteilt sind; die meldende Person; die Autorin/der Autor des gemeldeten Themas; sowie Pseudonyme in der Karenzzeit — wer eine abgeschlossene Jury-Runde hinter sich hat, ist erst nach 3 Tagen wieder losbar.

Ablauf und Fristen (alle Zeiten Europe/Berlin):

Meldung wird erstellt → Jury wird sofort gelost, die Abstimmung startet zur nächsten Mitternacht (00:00).
Ab Start läuft die reguläre Abstimmungsfrist von 24 Stunden.
Nach Ablauf der 24 Stunden wird entschieden, sofern mindestens 0,5 % (bezogen auf die Nutzerschaft, d. h. die Hälfte der Jury; Mindestquorum konfigurierbar) ihre Stimme abgegeben haben.
Ist das Quorum nicht erreicht, läuft die Meldung weiter, bis es erreicht ist; dann wird unmittelbar entschieden.

Stimmoptionen der Jury: bestätigen (Inhalt verstößt), ablehnen (kein Verstoß), Enthaltung (zählt für das Quorum, nicht für die Mehrheit). Entscheidung: einfache Mehrheit bestätigen > ablehnen → Inhalt wird entfernt (Platzhalterseite „nach Gemeinschaftsprüfung entfernt“); sonst bleibt er stehen. Bei Gleichstand bleibt der Inhalt stehen (im Zweifel für die Meinungsfreiheit).

Mitwirkungspflicht: Wer ausgelost wurde und noch nicht abgestimmt hat, wird beim nächsten Anhalten des Ausweises (Sitzungsbeginn) zuerst zur Jury-Entscheidung geführt und kann die übrigen Funktionen erst danach nutzen — oder wartet, bis die Meldung abgeschlossen ist. Enthaltung ist ausdrücklich zulässig; niemand wird zu einem inhaltlichen Urteil gezwungen.

Schutz vor Melde-Missbrauch: je Pseudonym maximal 3 Meldungen pro Tag; je Thema höchstens eine offene Meldung (weitere Meldungen desselben Themas werden auf die laufende Prüfung verwiesen); dasselbe Pseudonym kann dasselbe Thema nur einmal melden. Alle Grenzwerte sind serverseitig durchgesetzt.

7.3 Grenzen des Verfahrens

Die Bürger-Jury ist eine Plattform-Moderation, kein Strafverfahren. Offenkundig strafbare Inhalte können unabhängig vom Juryergebnis zusätzlich den Strafverfolgungsbehörden gemeldet werden; gesetzliche Melde- und Löschpflichten (insb. Digital Services Act, ggf. NetzDG-Nachfolgeregeln) gelten neben dem Juryverfahren und erfordern im Echtbetrieb einen benannten Zustellungsbevollmächtigten und Meldewege für Behörden. Das ist im Betriebskonzept der Ausbaustufe zu verankern.

8. Sicherheitsarchitektur

Bürgerabstimmung wäre im Echtbetrieb ein hochwertiges Angriffsziel (politische Stimmungsbilder, staatsnahe Wahrnehmung). Der Prototyp ist deshalb von Grund auf konservativ gebaut: wenig Code, wenig Abhängigkeiten, restriktive Standardwerte.

8.1 Prinzipien

Datenminimierung als Verteidigung: Was nicht gespeichert ist, kann nicht gestohlen werden. Keine Namen, keine E-Mail-Adressen, keine Passwörter, keine Klar-IP-Adressen in der Datenbank.
Keine fremden Laufzeit-Abhängigkeiten: Der Prototyp nutzt ausschließlich PHP-Bordmittel (kein Framework, kein Composer-Paket, kein CDN, keine externen Fonts/Skripte). Das eliminiert Lieferketten-Risiken und macht den gesamten Code in einem Durchgang auditierbar.
Sichere Standardwerte: Testbanner an, Mock-eID nur explizit, restriktivste HTTP-Header, alle Grenzwerte serverseitig.
Tiefenstaffelung: Kernregeln (1 Thema/Tag, eine Stimme pro Thema, eine offene Meldung pro Thema, ein Juror nur einmal je Meldung) sind zusätzlich zur Anwendungslogik als Datenbank-Constraints erzwungen.

8.2 Maßnahmen im Code (Prototyp)

Bereich	Maßnahme
SQL	Ausschließlich PDO-Prepared Statements, kein String-SQL mit Nutzerdaten
XSS	Konsequentes Output-Escaping (`htmlspecialchars`, ENT_QUOTES) in allen Templates; CSS und JavaScript werden als eigene Routen ausgeliefert. Ausnahmen ohne CSP-Bezug: das Icon-SVG trägt einen eigenen `<style>`-Block, die beiden Notfallseiten vor dem Start nutzen Inline-Styles
CSP	`default-src 'none'` + explizite Freigaben nur für eigene Skripte/Styles/Bilder; `frame-ancestors 'none'`, `base-uri 'none'`, `form-action 'self'`
Clickjacking	`X-Frame-Options: DENY` + CSP frame-ancestors
Weitere Header	`X-Content-Type-Options: nosniff`, `Referrer-Policy: no-referrer`, restriktive `Permissions-Policy`, COOP/CORP; HSTS im HTTPS-Betrieb
CSRF/Replay	Einmal-Token auf jedem POST-Formular: beim Einlösen verbraucht — jede Aktion ist genau einmal gültig
Sessions	HttpOnly, SameSite, Secure (bei HTTPS), ID-Rotation bei An-/Abmeldung, Inaktivitäts- (30 min) und absolutes Timeout (8 h) — wichtig für öffentliche Terminals
Identität	Der öffentliche Ausweis-Schlüssel selbst ist die Kennung — kein abgeleitetes Pseudonym. Das Server-Geheimnis (`data/secret.key`, 0600) wird beim ersten Start erzeugt und nur für die Stimmen-Marker und die Ratenbegrenzung verwendet
Zufall	Jury-Losverfahren mit CSPRNG (`random_int`, Fisher-Yates), nicht mit SQL-`RANDOM()`
Rate-Limits	Serverseitig je Pseudonym bzw. gehashter IP: Anmeldeversuche, Stimmen, Meldungen, Formular-POSTs
Eingaben	Whitelist-Validierung (Enums, Längen, UTF-8-Prüfung, Kontrollzeichen-Filter); keine Datei-Uploads
Fehlerbilder	Keine Stacktraces oder Pfade nach außen; generische Fehlerseiten; Sicherheitsereignisse werden ohne personenbezogene Daten protokolliert
Struktur	Eine Datei im Webroot; Datenbank, Geheimnisse und Logs liegen in `data/` innerhalb des Webroots und sind über eine eigene `.htaccess` sowie eine 404-Regel in der Anwendung gesperrt. Ein Verzeichnis außerhalb des Webroots wäre stärker und ist für den Echtbetrieb zu empfehlen
Betrieb	Selbsttest (`php index.php selftest`, 122 Prüfungen) deckt die Kernregeln automatisiert ab: Tagesgrenze, Abstimmungsende, Jury-Ausschlüsse, Quorum, Fristen, Karenz, Freigabeliste, Dauerhaftigkeit abgestimmter Themen, Archivierung, Ähnlichkeitssuche, Einrichtung des Echtbetriebs, Sprachtabellen

8.3 Bedrohungsmodell (Auszug)

Bedrohung	Antwort
Bot-/Sockenpuppen-Armeen	eID: eine physische Karte = ein Konto; ohne Karte keine Stimme
Stimmenkauf/-zwang im großen Stil	Physische Karte + PIN nötig; skaliert schlecht; rechtlich sanktioniert
Manipulation der Jury-Auswahl	CSPRNG-Losung serverseitig; Ausschlusslisten; keine Selbstmeldung zur Jury möglich
Melde-Spam zur Zensur	Tageslimit, eine offene Meldung je Thema, Quorum + Mehrheit nötig, Gleichstand erhält Inhalt
SQL-Injection / XSS / CSRF	Siehe 8.2 — durchgängig parametrisiert, escaped, tokenisiert
Session-Diebstahl am Terminal	Kurze Timeouts, Abmelde-Knopf, HttpOnly-Cookies. Im Browser liegt außer dem Sitzungs-Cookie nur die `profil.yaml` im `sessionStorage`; „Abmelden“ löscht sie
Datenbank-Diebstahl	Enthält öffentliche Ausweis-Schlüssel, Themen und Stimmen — keine Klaridentitäten. Die Stimmen sind ohne das Server-Geheimnis nicht zuordenbar; wer Datenbank und `secret.key` erbeutet, kann die Zuordnung berechnen
Lieferkette (Pakete/CDN)	Keine externen Abhängigkeiten im Prototyp
DDoS / Lastspitzen	Ausbaustufe: CDN/Anycast vor statischen Assets, horizontale Skalierung, siehe 10.3

8.4 Echtbetrieb zusätzlich (Pflichtprogramm)

TLS ausschließlich (HSTS + Preload), getrennte Umgebungen, Härtung nach BSI-IT-Grundschutz, externe Penetrationstests vor Start, laufendes Schwachstellen-Management + Bug-Bounty, signierte Deployments, Backups mit Wiederanlaufübungen, 24/7-Monitoring, DDoS-Schutz, und ein unabhängiges Sicherheits-Audit des Jury-Losverfahrens (nachvollziehbare, aber nicht vorhersagbare Ziehung — z. B. via veröffentlichtem Ziehungs-Commitment).

9. Datenschutz (DSGVO)

Datenminimierung: gespeichert werden nur: der öffentliche Ausweis-Schlüssel als Kennung, Zeitstempel, eigene Themen, Merkzettel, Meldungen und Jury-Zuteilungen. Stimmen liegen ohne Bezug zum Ausweis (HMAC-Marker). Die gewählte Sprache wird nicht gespeichert — sie gilt nur für die laufende Sitzung; die Spalte in der Kontozeile trägt lediglich den Standardwert aus der Anlage. Keine Klaridentität, keine IP-Adressen im Klartext (nur kurzlebige Hashes für Rate-Limits), keine Tracker, keine Cookies außer dem Sitzungs-Cookie.
Rechtsgrundlage (Echtbetrieb): Art. 6 Abs. 1 lit. a/e DSGVO je nach Trägerschaft; eID-Nutzung nach eIDAS/PAuswG mit Berechtigungszertifikat.
Betroffenenrechte — Stand im Prototyp, ehrlich: Die Auskunft ist umgesetzt: die profil.yaml enthält den vollständigen eigenen Stand, an den eigenen Ausweis-Schlüssel verschlüsselt. Sie wird allerdings nur per JavaScript abgerufen — ohne JavaScript gibt es keine Selbstauskunft. Die Löschung ist als Routine vorhanden und automatisiert geprüft (account_delete löscht die Kontozeile, wodurch Merkzettel, Meldungen und Jury-Sitze per Fremdschlüssel mit entfernt werden, und hängt eingebrachte Themen an ein System-Konto um; abgegebene Stimmen bleiben erhalten, weil sie keinen Bezug zum Ausweis tragen und nach dem Löschen niemandem mehr zuzuordnen sind). Sie hat in dieser Fassung keine Schaltfläche in der Oberfläche — der Löschbereich wurde entfernt. Vor einem Echtbetrieb ist dafür zwingend ein Weg in der Oberfläche zu ergänzen, sonst ist Art. 17 DSGVO nicht erfüllt.
Speicherbegrenzung: Rate-Limit-Einträge verfallen automatisch; Sicherheitslogs ohne Personenbezug.
Für den Echtbetrieb: Datenschutz-Folgenabschätzung (Art. 35 DSGVO) zwingend, benannte(r) DSB, Verzeichnis von Verarbeitungstätigkeiten.

10. Technik

10.1 Prototyp-Stack

PHP ≥ 8.0 (strict types, harte Versionssperre beim Start), keine externen Pakete.
SQLite (WAL-Modus) als Prototyp-Datenbank — eine Datei, einfach zu prüfen; die Datenzugriffsschicht ist so geschrieben, dass PostgreSQL in der Ausbaustufe ein Austausch der Verbindung ist.
Server-gerendertes HTML, genau eine CSS- und eine JS-Datei, dazu das Icon — alles aus derselben Datei ausgeliefert. Hell/Dunkel ist reines CSS, dafür gibt es kein Skript.
Betrieb hinter Apache/nginx mit gesperrtem data/ oder für Demos mit dem eingebauten PHP-Server.

10.2 Hintergrundläufe

Zustandswechsel (Meldung „wartet“ → „läuft“ um 00:00, Entscheidung nach 24 h + Quorum, Karenzzeiten) verarbeitet ein idempotenter Maintenance-Tick: er läuft per Cron (php index.php cron) und zusätzlich beiläufig bei Seitenaufrufen (auf 30 Sekunden gedrosselt), sodass der Prototyp auch ohne Cron korrekt bleibt.

10.3 Skalierungspfad

PostgreSQL + Read-Replicas → zustandslose PHP-Knoten hinter Load-Balancer → CDN für Assets → Warteschlange für Jury-Benachrichtigungen → mandantenfähige Gebietsdaten (amtliche Gemeindeschlüssel AGS/ARS statt Freitext-Gebieten).

11. Parameter (konfigurierbar)

Parameter	Standard	Bedeutung
`show_test_banner`	true	Testbetrieb-Banner auf jeder Seite
`eid_mode`	`demo`	`demo` (ausgegebene Test-Ausweise) oder `eid` (nur Ausweis-Apps)
`eid_client_url`	`http://127.0.0.1:24727/eID-Client`	Aktivierungsadresse des eID-Clients (TR-03124)
`eid_server_url`	leer	SOAP-Endpunkt des eigenen eID-Servers (TR-03130); leer = fail-closed
`data/config.yaml`	fehlt	von der Einrichtungsseite geschriebene Überlagerung der Vorgaben
`default_lang`	`de`	Standardsprache
`jury_share`	1 %	Anteil der Nutzerschaft je Jury
`jury_min`	5	Mindest-Jurygröße
`quorum_share`	0,5 %	Quorum als Anteil der Nutzerschaft
`quorum_min`	3	Mindest-Quorum
`report_vote_hours`	24	Reguläre Jury-Abstimmungsdauer
`jury_cooldown_days`	3	Karenz nach abgeschlossener Jury-Runde
`reports_per_day`	3	Meldungen je Pseudonym und Tag
`timezone`	Europe/Berlin	Bezugszeitzone aller Tagesgrenzen

12. Roadmap

Prototyp (dieses Repository): vollständige Fachlogik mit Mock-eID, Zwei-Sprachen-UI, Jury-Verfahren, Selbsttests.
Pilot: Anbindung echter eID-Server (Berechtigungszertifikat, AusweisApp-Flow), externes Sicherheits-Audit + Pentest, DSFA, Barrierefreiheit nach BITV, PostgreSQL.
Kommunal-Pilotgemeinden: Terminals in Bürgerbüros, amtliche Gebietsschlüssel, Auswertungs-Exporte für Räte und Verwaltungen.
Ausbau: Delegations-/Sachverständigen-Funktionen, strukturierte Ergebnisberichte an Parlamente, offene Schnittstellen (Open Data) mit Differential-Privacy-Schutz kleiner Gebiete.

13. Offene Punkte

Marken-/Domainrecherche „Bürgerabstimmung“ und finale Namensentscheidung.
Trägerschaft und Finanzierung (Verein/Stiftung empfohlen: neutralitätssichernd).
Rechtsgutachten: eID-Berechtigungsumfang, DSA-Pflichtenkatalog, Jugendliche (Ausweispflicht ab 16 — Teilnahmealter ist Konfigurationsfrage).
Verifizierbare Jury-Ziehung (öffentliches Commitment-Verfahren) — Konzept in 8.4 skizziert, Umsetzung in der Pilotphase.

Anhang: Installation und Betrieb

Der technische Prototyp ist eine einzige Datei. Es genügt ein Webserver mit PHP — kein Framework, kein Paketmanager, keine externen Dienste.

index.php in das Webverzeichnis legen (Hauptverzeichnis oder Unterordner; der Basispfad wird erkannt).
PHP 8.0 oder neuer mit pdo_sqlite, mbstring und sodium — alle drei gehören zur Standardausstattung.
Seite aufrufen. Beim ersten Aufruf legt die Datei selbst an: data/ (SQLite-Datenbank, Server-Geheimnis, Protokolle, Zugriffssperre), .htaccess (saubere Adressen und Schutz interner Dateien) und robots.txt.

Meldet die Seite „Fast geschafft“, fehlen dem Verzeichnis Schreibrechte (755/775 setzen, neu laden). Ohne .htaccess-Unterstützung — etwa unter nginx — arbeitet die Anwendung über automatisch erzeugte /index.php/…-Adressen weiter; eine gleichwertige try_files-Regel stellt die sauberen Adressen her. Dort ist zusätzlich /data/ zu sperren — die Anwendung selbst beantwortet jede Anfrage auf diesen Pfad mit 404, ausgeliefert würde sie sonst am PHP-Prozess vorbei.

Der Auslieferungszustand ist der Testmodus (Kapitel 5.3b): ein Knopf meldet ohne Ausweis an, damit sich die Plattform vorführen lässt. Über den Chip „Testmodus“ führt die Seite „Echtbetrieb einrichten“ (Kapitel 5.3c) durch Prüfung, Zugangswahl und Umschaltung; sie schreibt die Einstellungen nach data/config.yaml, löscht alle Testdaten und aktiviert dauerhaft die strenge Ausweisprüfung. Der dafür nötige Einrichtungsschlüssel steht in data/setup.token.

Wartung und Prüfung laufen über dieselbe Datei auf der Kommandozeile:

Aufruf	Zweck
`php index.php selftest`	122 automatisierte Prüfungen der Fachregeln
`php index.php cron`	Wartungslauf (sonst beiläufig bei Seitenaufrufen)
`php index.php seed 400`	Demo-Stimmen, anonym wie im Echtbetrieb
`php index.php jurysim`	Demo-Jury stimmt in laufenden Prüfungen ab
`php index.php issue-card 3`	autorisierte Demo-Ausweise samt Abhol-Verweis
`php index.php sync-keys`	Freigabeliste aus der konfigurierten Trust-Liste
`php index.php setup-token`	Einrichtungsschlüssel für die Umschaltung anzeigen
`php index.php config`	wirksame Einstellungen aus `data/config.yaml` anzeigen
`php -S 127.0.0.1:8080 index.php`	lokale Vorführung ohne Webserver

45 KiB Raw Permalink Blame History Unescape Escape